Google responde às preocupações de bloqueio do Chromium Adblock

Em janeiro, escrevemos sobre um furor crescente devido à Planos do Google para descontinuar a API webRequest e substitua-o por uma nova API declarativaNetRequest que é muito menos poderosa e que limita o número de regras que os desenvolvedores podem usar para filtrar anúncios.

Na época, o desenvolvedor de um dos melhores aplicativos adbock, uBlock Origin, disse em bugs.chromium.org:

Se essa (bastante limitada) API declarativeNetRequest acabar sendo a única maneira de os bloqueadores de conteúdo cumprirem seu dever, isso significa essencialmente que dois bloqueadores de conteúdo que mantenho há anos, uBlock Origin (“uBO”) e uMatrix, não podem mais existir.

Agora um O engenheiro do Google que trabalha no Chromium respondeu às preocupações e concordou com algumas concessões, embora não esteja claro se elas vão longe o suficiente.

O Google continuou determinado a se livrar do webRequest AP, dizendo que é uma fonte de abuso crescente, mas concordou em melhorar a API declarativeNetRequest da seguinte maneira:

• Suporte a regras dinâmicas: Concordamos que isso é valioso na criação de extensões sofisticadas de bloqueio de conteúdo e adicionaremos suporte para regras declarativas que podem ser adicionadas ou removidas em tempo de execução à API declarativeNetRequest.
• Tamanho do conjunto de regras aumentado: Aumentaremos o limite da regra do valor de 30 mil do rascunho. No entanto, ainda é necessário um limite superior para garantir o desempenho dos usuários. As listas de bloqueio tendem a ser “somente push”, onde novas regras são adicionadas, mas regras obsoletas raramente são removidas (pesquisa externa mostrou que 90% das regras de bloqueio do EasyList não forneceram nenhum benefício em cenários comuns de bloqueio). Fazer com que essa lista continue crescendo sem limites é problemático.
• Ações e Condições Adicionais: Planejamos adicionar suporte para correspondência com base em mais condições, como tamanho do recurso, e forneceremos ações para modificar partes de uma solicitação em vez de apenas bloqueá-la, como remover cookies. Também estamos investigando outras condições e ações que podem fazer sentido para adicionar, como a correspondência com base no domínio de nível superior. (Uma observação adicional: enquanto estamos investigando a adição de suporte para modificações de CSP, a adição de um cabeçalho CSP para desabilitar o JavaScript foi frequentemente mencionada como um caso de uso; isso já é possível por meio do definições de conteudo API. Se isso for insuficiente, por favor, deixe-nos saber o porquê.)

O Google disse que continuaria trabalhando com desenvolvedores e não removeria a API webRequest antes que a substituição estivesse pronta e madura, dizendo:

Mais uma vez, estamos comprometidos em oferecer suporte a extensões no Chrome. Continuaremos a trabalhar com os desenvolvedores. Não lançaremos o Manifest V3 até que esteja pronto, e haverá um período de migração no qual poderemos continuar a tratar de comentários e problemas. Não removeremos o suporte ao Manifest V2 até que tenhamos confiança na plataforma.

Muitos permanecem céticos, mas o objetivo real do Google é controlar com mais rigor a experiência do usuário para permitir o rastreamento e a veiculação de anúncios de seus bilhões de usuários.

Nossos leitores acham que o Google usará seu controle cada vez maior dos mecanismos de renderização da Web do mundo via Chromium para impulsionar ainda mais seus negócios de anúncios ou há concorrência de navegadores suficiente para mantê-los honestos? Deixe-nos saber abaixo.

Através da O registro