No ano passado, estivemos envolvidos ativamente em discussões com os fornecedores por trás 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 das quais ocorreram no WebExtensions Community Group (WECG) em colaboração com outros navegadores, conseguimos oferecer melhorias significativas.
Mais conjuntos de regras estáticos
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údos específicos de um local que apenas alguns usuários querem bloquear. Até pouco tempo atrás, permitimos que cada extensão oferecesse aos usuários 50 listas (ou "conjuntos de 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 número era muito baixo para determinados casos de uso. Depois de analisar o desempenho da API no Chrome com essas discussões em mente, vamos permitir a ativação de até 50 simultaneamente. Isso é significativamente maior do que o limite de 20 solicitado no WECG. Também permitimos 100 conjuntos de regras no total. Isso está sendo lançado no Chrome 120, e o aumento dos limites é compatível com o Firefox e o Safari, que forneceram informações iniciais sobre a proposta.
Mais regras dinâmicas
A maioria das regras é "estática" e é enviada com cada atualização de uma extensão. No entanto, para possibilitar 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 upload de uma nova versão da extensão na Chrome Web Store.
Quando uma extensão pode modificar solicitações dinamicamente de formas que não foram verificadas durante a análise da Chrome Web Store, isso expõe os usuários 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.
Como consequência, 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 que incluem o AdGuard e o Adblock Plus realizaram as próprias análises e dados compartilhados. Um limite maior permitiria regras mais atualizadas e para que usuários com um número maior de listas personalizadas migrassem para o Manifesto V3. O AdGuard relatou que mais de 2.600 alterações são feitas nas listas em alta toda semana, e dos 5% dos usuários que usam listas de filtros personalizadas, um em cada quatro deles tem um total combinado de mais de 5.000 regras dinâmicas entre elas (fonte). O AdGuard observou isso como 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 as que têm uma ação de block ou allow, são muito mais seguras e têm menor probabilidade de abuso. Elas também compõem a grande maioria das regras de filtro de bloqueio de anúncios. Com base nisso, elaborei e compartilhei uma proposta no grupo da comunidade de extensões da Web para definir um conjunto de regras que consideramos de menor risco e permitimos até 30.000 delas. Ainda mantemos um limite máximo para evitar regressões de desempenho.
Nós implementamos essa proposta, porque ela tinha suporte do grupo da comunidade de extensões da Web. A partir do Chrome 121, o limite maior de 30.000 regras se aplica às regras de DNR seguras, que estamos definindo como regras com uma ação block, allow, allowAllRequests ou upgradeScheme.
Com base nos dados compartilhados pelo AdGuard, entre 98 e 99% das regras devem se beneficiar desse limite maior. As demais regras ainda serão aceitas e poderão ser adicionadas dentro do limite atual.
Essa opção 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 líquida 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 diferencia maiúsculas de minúsculas. Além disso, aprendemos que a maioria dos desenvolvedores tinha um padrão diferente na extensão. Consequentemente, o valor teve que ser definido muitas vezes. Com essa mudança, os desenvolvedores conseguem reduções significativas de tamanho nos conjuntos de regras.
E agora?
Temos o compromisso de continuar investindo na API declarativeNetRequest para que possamos oferecer suporte ao maior número possível de casos de uso, e esperamos continuar trabalhando com a comunidade. Particularmente, gostaríamos de agradecer aos membros das WECG pelo engajamento, incluindo o AdGuard por compartilhar uma quantidade significativa dos dados que conduziram este trabalho e a todos os fornecedores de navegadores que participaram de uma parte importante no desenvolvimento dessa API.
Continuaremos analisando os limites que estabelecemos para fazer ajustes quando necessário. Para isso, planejamos compartilhar em breve alguns dos dados que coletamos como parte deste trabalho. Além disso, estamos trabalhando para adicionar outros recursos, como a correspondência com cabeçalhos de resposta, que é uma solicitação comum de extensões de visualizadores de PDF. De qualquer forma, continuaremos a comunicar nosso trabalho e usaremos o grupo da comunidade de extensões da Web regularmente como um lugar para discutir ideias e nos alinhar aos próximos tópicos.