No ano passado, participamos ativamente de discussões com os fornecedores de várias extensões de bloqueio de conteúdo sobre maneiras de melhorar a plataforma de extensões MV3. Com base nessas discussões, muitas delas realizadas no Grupo da comunidade de extensões da Web (WECG) em colaboração com outros navegadores, conseguimos fazer melhorias significativas.
Mais conjuntos de regras estáticas
Os conjuntos de regras de filtro geralmente são agrupados em listas. Por exemplo, uma lista mais genérica pode conter regras aplicáveis a todos os usuários, enquanto uma lista mais específica pode ocultar conteúdo específico de local que apenas alguns usuários querem bloquear. Até pouco tempo atrás, permitíamos que cada extensão oferecesse aos usuários a opção de 50 listas (ou "regras estáticas") e que 10 delas fossem ativadas simultaneamente. Em discussões com a comunidade, os desenvolvedores de extensões forneceram evidências convincentes mostrando que esse valor era muito baixo para determinados casos de uso. Depois de analisar o desempenho da API no Chrome, considerando essas discussões, agora permitimos que até 50 sejam ativadas simultaneamente. Esse número é significativamente maior do que o limite de 20 solicitado na WECG. Também permitimos 100 conjuntos de regras no total. Isso está sendo enviado no Chrome 120, e o aumento dos limites é compatível com o Firefox e o Safari, que forneceram informações iniciais sobre essa proposta.
Mais regras dinâmicas
A maioria das regras é "estática" e é enviada com cada atualização de uma extensão. No entanto, para oferecer suporte a atualizações mais frequentes e regras definidas pelo usuário, as extensões também podem adicionar regras dinamicamente, sem que os desenvolvedores precisem fazer o upload de uma nova versão da extensão para a Chrome Web Store.
Quando uma extensão pode modificar solicitações de forma dinâmica de maneiras que não foram verificadas durante a análise da Chrome Web Store, os usuários ficam expostos a riscos de phishing ou roubo de dados. Por exemplo, uma regra de redirecionamento pode ser usada indevidamente para injetar links de afiliados sem consentimento.
Por isso, só permitimos que as extensões adicionassem até 5.000 regras,o que incentivou o uso moderado dessa funcionalidade e facilitou a detecção de abusos.
No entanto, os desenvolvedores de extensões, incluindo o AdGuard e o Adblock Plus, realizaram análises e compartilharam dados que mostram que um limite maior permitiria regras mais atualizadas e que os usuários com um número maior de listas personalizadas migrassem para o Manifest V3. Na verdade, o AdGuard informou que mais de 2.600 mudanças são feitas nas listas populares a cada semana. Além disso, dos 5% dos usuários que usam listas de filtros personalizadas, um em cada quatro tem um total combinado de mais de 5.000 regras dinâmicas (fonte). O AdGuard observou que isso é um desafio significativo para migrar a extensão para o Manifest V3, e recebemos feedback semelhante de outros bloqueadores de conteúdo.
Determinamos que algumas regras de filtro, como aquelas com uma ação de block ou allow, são muito mais seguras e têm menos probabilidade de abuso. Elas também representam a grande maioria das regras de filtro de bloqueio de anúncios. Com base nisso, elaborei e compartilhei uma proposta no grupo da comunidade das extensões da Web para definir um conjunto de regras que consideramos de baixo risco e permitir até 30.000 delas. Ainda mantemos um limite máximo para evitar regressões de desempenho.
Essa proposta foi apoiada no grupo da comunidade de extensões da Web, então a implementamos. A partir do Chrome 121, o limite mais alto de 30.000 regras se aplica a regras de DNR seguras, que estamos definindo como regras com uma ação de block, allow, allowAllRequests ou upgradeScheme.
Com base nos dados compartilhados pelo AdGuard, entre 98 e 99% das regras vão se beneficiar desse limite mais alto. As regras restantes ainda são válidas e podem ser adicionadas dentro do limite atual.
Ela está disponível no Chrome como a constante MAX_NUMBER_OF_DYNAMIC_RULES. O limite de regras para todas as outras regras de solicitação de rede dinâmica permanece em 5.000.
Redução do tamanho do conjunto de regras
No Chrome 118, mudamos o valor padrão do campo isUrlFilterCaseSensitive para false com base no feedback da comunidade. Esse campo controla se uma regra que filtra por URL é sensível a letras maiúsculas/minúsculas. Descobrimos que a maioria dos desenvolvedores tinha um padrão diferente na extensão. Por isso, o valor precisava ser definido várias vezes. Com essa mudança, os desenvolvedores conseguem reduzir significativamente o tamanho das regras.
E agora?
Estamos comprometidos em continuar investindo na API declarativeNetRequest para oferecer suporte a tantos casos de uso quanto possível. Esperamos continuar trabalhando com a comunidade. Em particular, gostaríamos de agradecer aos membros do WECG pelo engajamento, incluindo o AdGuard por compartilhar uma quantidade significativa de dados que impulsionaram esse trabalho, e todos os fornecedores de navegadores que foram uma parte importante do design dessa API.
Vamos continuar analisando os limites atuais para fazer ajustes quando necessário. Para isso, planejamos compartilhar alguns dos dados coletados como parte desse trabalho em breve. Além disso, estamos trabalhando para adicionar outros recursos, como a capacidade de correspondência com cabeçalhos de resposta, que é uma solicitação comum das extensões de visualizador de PDF. Em todos os casos, vamos continuar a comunicar nosso trabalho e usar o grupo da comunidade de extensões da Web regularmente para discutir ideias e alinhar o que queremos analisar em seguida.