O próximo Manifest V3 para extensões do Google Chrome mudará a forma como os bloqueadores de anúncios funcionam no Chrome. Este é o caminho certo para os bloqueadores de anúncios e o Google?
Google Chrome é o navegador multiplataforma mais popular disponível no mercado atualmente, reivindicando 62,7% da parcela global de uso do navegador até maio de 2019, com o Safari da Apple ficando em segundo lugar com 15,89% e o Firefox da Mozilla com 5,07%. Por causa de sua maior parte, as menores mudanças que o Google Chrome realiza em sua plataforma acabam afetando milhões de usuários em todo o mundo. Então, quando o Google anunciou a próxima versão do manifesto de extensões na forma de Manifest V3 para extensões do Google Chrome, sabíamos que passaríamos por grandes mudanças, especialmente quando se descobriu que o Google estava construindo uma API bloqueadora de conteúdo no Chrome em si.
O que é o Manifesto V3?
Se você é um usuário ativo do Chrome, sem dúvida usa algumas extensões. Extensões são pequenos programas de software que personalizam a experiência de navegação usando o
APIs que o navegador fornece, permitindo que os usuários adaptem a funcionalidade e o comportamento de acordo com suas necessidades e preferências individuais. Essas extensões são distribuídas principalmente através do Loja online do Chrome, que abriga mais de 180.000 extensões.Desde final do ano passado, o Google está trabalhando no "Manifest V3", um conjunto de alterações propostas para a plataforma de extensões do Chrome que podem ser classificadas como "mudanças importantes". Enquanto o documento de discussão pública para o Manifesto V3 afirma, a versão do manifesto da extensão é um mecanismo para restringir certos recursos a uma determinada classe de extensões. Essas restrições podem ser na forma de versão mínima ou versão máxima. Restringir a uma versão mínima permite que APIs ou recursos mais recentes estejam disponíveis apenas para extensões mais recentes enquanto a restrição a uma versão máxima do manifesto permite que APIs ou recursos mais antigos sejam gradualmente descontinuada.
Em termos mais simples, uma nova versão do manifesto permite ao Chrome restringir APIs e recursos a esta nova versão do manifesto, em para forçar os desenvolvedores de extensões a migrar de certas APIs mais antigas devido ao seu impacto negativo no usuário experiência. A implementação de uma extensão no Manifest V3 deveria, teoricamente, fornecer garantias mais fortes do ponto de vista de segurança, privacidade e desempenho.
Embora haja uma ampla gama de mudanças descritas no Manifesto V3, a mudança mais controversa está relacionada à decisão do Google de limitar as capacidades de bloqueio presentes no existente chrome.webRequest API (e focar a API na observação em vez do bloqueio) e, em seguida, apresentar essas habilidades de bloqueio por meio de um novo chrome.declarativeNetRequest API. Esta mudança específica inflamou a comunidade pois acaba tendo como alvo o mecanismo de bloqueio de anúncios da famosa extensão de bloqueio de anúncios, Origem do uBlock, e afeta diretamente seus mais de 10 milhões de usuários.
Antes de abordarmos esse assunto, vamos dar uma olhada em como o webRequest API se compara a declarativoNetRequest API.
API de solicitação da Web e API de solicitação de rede declarativa
O presente
A descrição oficial do Web Request descreve a API da seguinte forma:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Com a solicitação da Web, o Chrome envia todos os dados em uma solicitação de rede para o ramal que os escuta. A extensão então tem a chance de avaliar a solicitação e instruir o Chrome sobre o que fazer com a solicitação: permitir, bloquear ou enviar com algumas modificações.
Acompanhe a sequência de eventos para entender o que acontece quando as extensões usam a API Web Request. Quando um usuário com uma extensão Web Request instalada clica em um link, o Chrome informa à extensão que uma solicitação de dados foi feita antes que a solicitação chegue ao servidor. A extensão pode optar por modificar a solicitação nesta fase. O servidor então responde, mas a resposta passa novamente pela extensão, e a extensão pode determinar se a resposta precisa ser modificada. O Chrome finalmente renderiza a página e o usuário pode visualizar o resultado de sua ação de clique.
À medida que o Chrome é entregue todos os dados em uma solicitação de rede, extensões que usam a API Web Request têm acesso para ler e modificar tudo o que um usuário faz na web. Portanto, embora bloqueadores de conteúdo como o uBlock Origin utilizem sabiamente o potencial desta API, o Google afirma que outras extensões com intenções maliciosas abusaram das mesmas para obter acesso aos dados pessoais dos usuários Informação. Segundo o Google, 42% das extensões maliciosas usaram a API Web Request desde janeiro de 2018. O Google também afirma que há “custos de desempenho significativos” envolvidos com a API como versão de bloqueio disso requer um processo persistente e muitas vezes de longa duração que é fundamentalmente incompatível com o “preguiçoso” processos.
Com o Manifest V3, o Google propõe limitar esta API em sua forma de bloqueio. Como alternativa, o Google está fornecendo a API Declarative Net Request.
O futuro
A descrição oficial do Declarative Net Request descreve a API da seguinte forma:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Com a solicitação líquida declarativa, o Chrome não precisa enviar todas as informações sobre uma solicitação para a extensão de escuta. Em vez disso, a extensão registra regras no Chrome que informam antecipadamente ao navegador o que fazer se determinados tipos de solicitações forem vistos.
A extensão especifica suas regras antecipadamente. A solicitação dos usuários é então comparada com esta regra pelo navegador (e não pela extensão), e a ação também é realizada pelo navegador, e a página é posteriormente renderizada. O Google menciona que isso lhes permite garantir a eficiência, uma vez que podem exercer controle sobre o algoritmo que determina o resultado e podem prevenir ou desabilitar regras ineficientes. Também apresenta melhores garantias de privacidade para o usuário final, pois os detalhes da solicitação de rede não são expostos à extensão. Como processos persistentes e demorados não são mais necessários (uma vez que as regras são registradas previamente), o Google afirma que esta abordagem também traz melhorias de desempenho que tornarão as extensões significativamente mais viáveis em ambientes com recursos limitados. plataformas.
A solicitação de rede declarativa estará disponível para o Manifesto V2 (atual) e para o Manifesto V3, mas será a principal forma pela qual o Google permitirá que as solicitações de rede sejam modificadas no Manifesto V3.
A controvérsia
As mudanças do Google parecem fazer sentido até que você ouça o outro lado da história, principalmente o dos bloqueadores de anúncios. Essa migração de API específica está sendo vista como a maneira do Google de eliminar os bloqueadores de anúncios, pois muda fundamentalmente a forma como um dos bloqueadores de anúncios mais populares funciona. Isto está relacionado com a “teoria” de que o Google está motivado para esta mudança mais do ponto de vista empresarial do que do ponto de vista da segurança do utilizador. Afinal, o Google depende fortemente da publicidade para obter receitas, e os bloqueadores de anúncios são vistos como uma ameaça direta para os clientes do Google nesta frente, como foi revelado através de Arquivamento do Formulário 10-K da SEC 2018 da Alphabet (através da O registro):
Tecnologias novas e existentes podem afetar a nossa capacidade de personalizar anúncios e/ou bloquear anúncios online, o que prejudicaria o nosso negócio.
Tecnologias foram desenvolvidas para dificultar a publicidade personalizável ou para bloquear totalmente a exibição de anúncios e alguns provedores dos serviços on-line integraram tecnologias que podem prejudicar a funcionalidade principal de serviços digitais de terceiros. anúncio. A maior parte de nossas receitas do Google provém de taxas que nos são pagas pela exibição de anúncios on-line. Como resultado, tais tecnologias e ferramentas poderão afetar adversamente nossos resultados operacionais.
O Google teve que divulgar um comunicado para resolver isso, reiterando sua posição de que a mudança é do interesse da privacidade do usuário e não um ataque direto contra bloqueadores de anúncios:
Não estamos impedindo o desenvolvimento de bloqueadores de anúncios nem impedindo que os usuários bloqueiem anúncios. Em vez disso, queremos ajudar os desenvolvedores, incluindo bloqueadores de conteúdo, a escrever extensões de uma forma que proteja a privacidade dos usuários.
É necessário fazer referência a dois dos bloqueadores de anúncios mais populares disponíveis no Google Chrome: Origem do uBlock e Adblock Plus, sendo que ambos adotam abordagens diferentes para alcançar o mesmo resultado de bloqueio de conteúdo. O uBlock Origin depende muito da API Web Request, e a comunidade tem preferido essa extensão ao longo dos anos. Adblock Plus e outras extensões de bloqueio de conteúdo também dependem da parte de bloqueio do Web Request, portanto, as alterações nesta API acabarão afetando a maioria dos bloqueadores de conteúdo em pelo menos alguma capacidade.
A pressão do Google para descontinuar o Web Request essencialmente matará o uBlock Origin em seu formato atual, algo que de fato afetará muitos usuários. Embora usuários sem lealdade (e sem intenção de se preocupar com a forma como o bloco de anúncios é obtido) encontrem soluções alternativas que apresentam suas próprias desvantagens, isso se tornará impossível para que fiéis e entusiastas criem novos designs de mecanismo de filtragem para contornar as várias técnicas que os sites eventualmente criarão para combater bloqueadores de anúncios nesta API específica.
O Declarative Net Request também foi proposto como um mecanismo de filtragem bastante limitado, pois era inicialmente planejado ter um limite de 30.000 regras de filtro estático por extensão (regras que são declaradas durante a instalação); e limite de 5.000 regras em regras de filtro dinâmico por extensão (regras que podem ser adicionadas após a instalação). Quaisquer regras em excesso serão ignoradas, o que é um pouco problemático, já que o próprio EasyList para Adblock Plus tem 70.000 regras, enquanto o uBlock Origin pode ser configurado para funcionar com mais de 100.000 regras. Após a reação inicial da comunidade, Google respondeu prometendo alterar o limite de regras estáticas de 30.000 regras por extensão para um máximo global de 150.000 regras. Isso tem o efeito colateral de impedir que os usuários usem outros scripts com muitas regras em conjunto com um bloqueador de anúncios, de modo que os usuários terão que lidar com suas preferências.
Além do limite de filtragem limitado, Solicitação Líquida Declarativa só pode redirecionar para URLs estáticos, portanto, não há suporte incluído para correspondência de padrões. O uBlock Origin depende fortemente da correspondência de padrões e do desenvolvedor da extensão afirmou que não é possível reformar algoritmo de correspondência de sua extensão para atender aos requisitos de APIs. A API também exigiria uma atualização completa da extensão para simplesmente atualizar a lista de filtros, o que seria uma atividade muito frequente considerando o frequência com que essas listas de filtros são atualizadas. É claro que essas atualizações também dependeriam dos critérios e processos de revisão de extensões do Google.
Por outro lado, o Google sempre manteve a posição de que sua intenção de se afastar do Web Request é de um perspectiva de segurança, já que a API Web Request é muito poderosa em sua forma atual e deixa aberto um amplo espaço para Abuso. Este abuso não é apenas teórico, já que o Google mencionou que 42% das extensões maliciosas abusaram desta API. Safári da Apple API bloqueadora de conteúdo foi projetado como Declarative Net Request por razões semelhantes, pois há menos espaço para um desenvolvedor desonesto explorar. Na solicitação da Web nerfada, as solicitações de rede ainda seriam observáveis, mas precisariam de permissões nos hosts relevantes. Com o Manifest V3, as permissões de host também estão mudando significativamente e não podem mais ser concedidas de maneira geral no momento da instalação.
O Google também usou despesas gerais de desempenho como motivador para a mudança. A avaliação das solicitações de rede ocorre no thread JavaScript da extensão, o que pode prejudicar o desempenho. Como refutação, o desenvolvedor do uBlock Origin menciona que sua extensão não incorre em nenhuma penalidade significativa de desempenho mesmo quando há até 140.000 filtros estáticos para aplicar. Os custos incorridos são facilmente recuperados pelos recursos que são impedidos de serem baixados de servidores remotos e, portanto, não processados pelo navegador.
Mesmo que o Google não use esse raciocínio, um argumento contra o Web Request também pode ser apresentado em favor da eficiência com o bloqueio de anúncios. Com o Web Request, se uma extensão não responder a tempo (devido a um atraso ou travamento), a solicitação de manipulação da rede é claramente permitida, o que permite que os anúncios passem pelo bloqueador de anúncios. A Solicitação Líquida Declarativa, por outro lado, não sofreria essa desvantagem. Em vez disso, os anúncios serão transmitidos se não forem enquadrados nas regras estáticas, e isso acontecerá com mais frequência.
Conclusão
Pelas explicações acima, fica claro que a Solicitação de Rede Declarativa não é um clone de funcionalidade 1:1 para o bloqueio recursos da API de solicitação da Web, e os desenvolvedores de extensões ficarão irritados quando seu trabalho árduo for prejudicado por tais mudanças. Mas o raciocínio do Google também tem peso: o Web Request é muito poderoso e seus poderes precisam ser restringido no interesse maior da comunidade de usuários (que compreende usuários médios junto com entusiastas).
A mudança em direção à solicitação de rede declarativa também poderia ter sido uma jogada positiva de relações públicas - afinal, o Google está adicionando uma API bloqueadora de conteúdo integrada ao Chrome! Mas como a nova API vem com suas próprias restrições pesadas, a comunidade vê isso como um corte de asas. Em um mundo ideal, o Google deveria ter explorado o funcionamento de bloqueadores de anúncios como o uBlock Origin antes de lançar a nova API. Da forma como está agora, a nova API poderia usar mais flexibilizações em seus limites de regras para acomodar cenários em que os usuários desejariam usar duas extensões com muitos filtros.
De acordo com O registro, as primeiras compilações com alterações do Manifest V3 estarão disponíveis a partir de julho de 2019. Esperamos que o Google acomode o feedback recebido da comunidade de desenvolvedores de extensões com essas versões.
Agradecimentos especiais ao editor-chefe do XDA, Mishaal Rahman, por suas contribuições e assistência!
Editar: o artigo equiparou incorretamente o funcionamento do Adblock Plus ao da API Declarative Net Request. O artigo foi alterado em conformidade. O Adblock Plus também será afetado pela remoção dos recursos de bloqueio da API Web Request.