Google justifica a restrição da API webRequest usada por bloqueadores de anúncios

Desenvolvedores do navegador Chrome tentou justificar descontinuação do suporte para o modo de bloqueio da API webRequest, que permite alterar o conteúdo recebido em tempo real e é usado ativamente em complementos para bloqueio de publicidade,
proteção contra malware, phishing, espionagem da atividade do usuário, controle dos pais e privacidade.

Motivos do Google:

• Modo de bloqueio de API webRequest leva a um alto consumo de recursos.
  Ao usar esta API, o navegador primeiro envia ao add-on todos os dados contidos na solicitação de rede, o add-on os analisa e retorna uma versão modificada para processamento posterior no navegador ou emite instruções de bloqueio. Neste caso, os principais atrasos surgem não na fase de processamento do tráfego pelo add-on, mas devido aos custos indiretos de coordenação da execução do add-on. Em particular, tais manipulações requerem o lançamento de um processo separado para complementar, bem como o uso de IPC para interagir com este processo e mecanismos de serialização de dados;

• O complemento controla completamente todo o tráfego em um nível baixo, o que abre vastas oportunidades para abusos e violações de privacidade. De acordo com estatísticas do Google, 42% de todos os complementos maliciosos detectados usaram a API webRequest. Observa-se que, todos os meses, tentativas de colocar em média 1800 complementos maliciosos são bloqueadas no catálogo da Chrome Web Store. Infelizmente, a revisão não nos permite detectar todos os complementos maliciosos sem exceção, portanto, para aumentar a proteção, foi decidido limitar os complementos no nível da API. A ideia principal é fornecer aos add-ons acesso não a todo o tráfego, mas apenas aos dados necessários para implementar a funcionalidade pretendida. Em particular, para bloquear conteúdo, não é necessário conceder ao complemento acesso total a todos os dados confidenciais do usuário;
• API declarativa de substituição proposta declarativoNetRequest cuida de todo o trabalho de filtragem de conteúdo de alto desempenho e requer apenas complementos para carregar regras de filtragem. O add-on não pode interferir no tráfego e os dados privados do usuário permanecem invioláveis;
• O Google levou em consideração muitos dos comentários sobre a falta de funcionalidade da API declarativaNetRequest e expandiu o limite do número de regras de filtragem dos 30 mil inicialmente propostos por extensão para um máximo global de 150 mil, e também adicionou a capacidade de dinamicamente alterar e adicionar regras, remover e substituir cabeçalhos HTTP (Referer, Cookie, Set-Cookie) e solicitar parâmetros;
• Para empresas, é possível utilizar o modo de bloqueio de funcionamento da API webRequest, uma vez que a política de utilização de add-ons é determinada por um administrador que entende as funcionalidades da infraestrutura e está ciente dos riscos. Por exemplo, a API especificada pode ser usada em empresas para registrar fluxos de tráfego de funcionários e integrar-se a sistemas internos;
• O objetivo do Google não é minar ou suprimir complementos de bloqueio de anúncios, mas permitir a criação de bloqueadores de anúncios mais seguros e poderosos;
• A relutância em sair do modo de bloqueio da API webRequest junto com o novo declarativoNetRequest é explicada pelo desejo de limitar o acesso de add-ons a dados confidenciais. Se você deixar a API webRequest como está, a maioria dos complementos não usará o NetRequest declarativo mais seguro, pois ao escolher entre segurança e funcionalidade, a maioria dos desenvolvedores geralmente escolherá a funcionalidade.

Objeções desenvolvedores aditivos:

• Conduzido por desenvolvedores de complementos testes mostram um impacto geral insignificante no desempenho dos complementos de bloqueio de anúncios (durante o teste, o desempenho de vários complementos foi comparado, mas sem levar em conta a sobrecarga de um processo adicional que coordena a execução de manipuladores no modo de bloqueio de a API webRequest);
• Não é prático parar completamente de oferecer suporte a uma API usada ativamente em complementos. Em vez de removê-lo, você pode adicionar uma permissão separada e controlar estritamente a adequação de seu uso em complementos, o que evitaria que os autores de muitos complementos populares reformulassem completamente seus produtos e evitassem o corte de funcionalidade;
• Para reduzir custos indiretos, você não pode excluir a API, mas refazê-la com base no mecanismo Promise, semelhante à implementação do webRequest no Firefox;
• A alternativa proposta, declarativeNetRequest, não cobre todas as necessidades dos desenvolvedores de complementos em termos de bloqueio de anúncios e segurança/privacidade, uma vez que não fornece controle total sobre solicitações de rede, não permite o uso de algoritmos de filtragem personalizados e não permite o uso de regras complexas que se sobrepõem dependendo das condições;
• Com o estado atual da API declarativeNetRequest, é impossível recriar a funcionalidade existente dos complementos uBlock Origin e uMatrix inalterada e também torna inútil o desenvolvimento de uma porta NoScript para Chrome;
• As preocupações com a privacidade são absurdas, uma vez que o modo somente leitura e sem bloqueio da API webRequest é mantido e ainda permite que complementos maliciosos controlem todo o tráfego, mas não fornece a capacidade de interferir nele no voar (alterar conteúdo, colocar seus anúncios, executar mineradores e analisar o conteúdo dos formulários de entrada que podem ser usados ​​após o término do carregamento da página);
• Desenvolvedores de navegador Brave, Opera и Vivaldi, construído no motor Chromium, pretende deixar suporte para o modo de bloqueio webRequest em seus produtos.

Fonte: opennet.ru