Simeon Vincent, responsável pela interação com desenvolvedores de extensões na equipe do Chrome (ocupa o cargo de defensor do desenvolvedor de extensões), A posição atual do Google em relação à terceira edição do manifesto do Chrome, muitos complementos para bloquear conteúdo impróprio e garantir a segurança. A empresa não pretende abandonar seu plano original de deixar de oferecer suporte ao modo de bloqueio da API webRequest, que permite alterar o conteúdo recebido em tempo real. Uma exceção será feita apenas para a edição empresarial do Chrome (), em que o suporte para a API webRequest será mantido como antes.
Para usuários regulares da API do Chrome será limitado ao modo somente leitura. Uma API declarativa foi proposta para substituir a API webRequest para filtragem de conteúdo , que cobre apenas uma parte limitada dos recursos usados nos bloqueadores de anúncios modernos. Essencialmente, em vez de manipuladores proprietários que têm acesso total às solicitações de rede, é oferecido um mecanismo de filtragem universal integrado e pronto para uso, que processa as regras de bloqueio por conta própria. Por exemplo, a API declarativeNetRequest não permite usar seus próprios algoritmos de filtragem e não permite criar regras complexas que se sobrepõem dependendo das condições.
Os desenvolvedores de complementos para bloqueio de anúncios prepararam em conjunto , que listou as deficiências da API declarativaNetRequest. O Google concordou com muitos dos comentários e adicionou à API declarativaNetRequest. Em particular, foi adicionado suporte para alteração e adição dinâmica de regras, e é possível excluir cabeçalhos HTTP, mas apenas aqueles na lista branca (Referer, Cookie, Set-Cookie). Planejamos implementar suporte para adição e substituição de cabeçalhos HTTP (por exemplo, para substituição de Set-Cookie e diretivas CSP) e a capacidade de excluir e substituir parâmetros de solicitação.
Uma versão preliminar da terceira versão do manifesto, que define a lista de capacidades e recursos fornecidos aos complementos do Chrome, está planejada para ser usada para testes em compilações experimentais do Chrome Canary nos próximos meses.
Ao mesmo tempo, a motivação para proibir alterações no conteúdo recebido através da API webRequest ainda não é totalmente clara. As alegações de que o modo de bloqueio da API webRequest tem um impacto negativo no desempenho porque o navegador espera que o manipulador do complemento conclua seu trabalho antes de renderizar a página não resistem às críticas. Conduzido anteriormente O desempenho dos complementos de bloqueio de anúncios mostrou que o atraso que eles introduzem é insignificante. Em média, o uso de um bloqueador retarda a execução de uma solicitação em apenas uma fração de milissegundos, o que é insignificante em comparação com o cenário geral.
O segundo argumento, relacionado ao desejo de proteger os usuários do acesso descontrolado de complementos ao conteúdo, também não parece convincente, pois em vez de remover funcionalidades há muito estabelecidas e difundidas em complementos legítimos, foi possível adicionar um novo tipo de autoridade e fornecer ao usuário a escolha final de instalar um complemento com acesso total às solicitações de rede ou não. Além disso, o Google deixou o suporte ao uso da API webRequest em modo somente leitura, permitindo monitoramento completo do tráfego sem intervenção de baixo nível.
Os complementos podem alterar o conteúdo das páginas da web carregadas por meio de outras APIs (por exemplo, complementos maliciosos ainda podem exibir seus anúncios, lançar mineradores e analisar o conteúdo dos formulários de entrada).
Raymond Hill, autor dos sistemas uBlock Origin e uMatrix para bloquear conteúdo indesejado, é bastante rígido resposta de um representante da Google e insinuou demagogia e jogos de bastidores em que a Google, sob o pretexto de uma boa oportunidade, tenta promover os seus interesses comerciais no domínio da publicidade na Internet, obter controlo dos seus mecanismos de filtragem e justificar estas acções aos olhos do público em geral.
Ele nunca recebeu argumentos convincentes sobre a necessidade de interromper a ampla e popular API entre os desenvolvedores de complementos. Segundo Raymond, a queda no desempenho não é argumento, já que as páginas carregam lentamente devido ao seu inchaço, e não devido ao uso do modo de bloqueio webRequest em complementos implementados corretamente. Se o Google realmente se importasse com o desempenho, eles teriam redesenhado o webRequest com base no mecanismo , por analogia com webRequest no Firefox.
De acordo com Raymond, a estratégia do Google é determinar o equilíbrio ideal entre a expansão da base de usuários do Chrome e os danos aos negócios causados pelo uso de bloqueadores de conteúdo. Na primeira fase da expansão do Chrome, o Google foi forçado a tolerar os bloqueadores de anúncios como um dos complementos mais populares entre os usuários. Mas depois que o Chrome ganhou domínio, a empresa tentou inclinar a balança a seu favor e obter controle sobre o bloqueio, promovendo para integrar funcionalidades inadequadas de bloqueio de anúncios no Chrome. A API webRequest anula esse propósito porque o controle sobre o bloqueio de conteúdo está atualmente nas mãos de desenvolvedores terceirizados de bloqueadores de anúncios.
Fonte: opennet.ru