Alguns meses atrás, compartilhamos aqui as notícias sobre as intenções do Google de eliminar os bloqueadores de publicidade do seu navegador, porque as alterações introduzidas no terceira versão do manisfesto afetam principalmente extensões destinadas a bloquear a publicidade dentro do navegador.
Agora, vários meses depois, o Google começou a testar a terceira versão de seu manifesto (Manifest V3), na qual o suporte ao novo manifesto define os recursos fornecidos pelos complementos, este Manifest V3 foi adicionado às compilações do Chrome Canary.
Detalhes da terceira versão do manisfesto da Google
O novo manifesto foi desenvolvido como parte de uma iniciativa para melhorar a segurança, a privacidade e o desempenho dos complementos (o objetivo principal é simplificar a criação de complementos seguros e de alto desempenho e complicar a possibilidade de criar complementos lentos e inseguros).
ePorém, o manifesto ainda está no estágio inicial de teste alfa, não é final e foi adicionado para dar aos desenvolvedores a oportunidade de começar a experimentar e adaptar seus complementos. A ativação do novo manifesto está prevista para o próximo ano.
Embora a conclusão do suporte para a segunda edição do manifesto ainda não tenha sido determinada. Para simplificar a migração de complementos para o novo manifesto, foi preparada uma lista de verificação que inclui as alterações que devem ser tratadas pelos desenvolvedores de complementos.
E como fica o desenvolvimento de complementos?
Então, aqui é importante lembrar que a principal insatisfação com o novo manifesto está relacionada ao fim do suporte ao modo de bloqueio da API webRequest, que será limitado ao modo somente leitura.
Somente uma exceção será feita para a edição do Chrome for Enterprise, na qual o suporte à API webRequest será mantido. A Mozilla decidiu não seguir o novo manifesto e manter o Firefox completamente usando a API webRequest.
Raymond Hill, desenvolvedor líder do uBlock Origin, condena esta decisão do Google. De acordo com o último, a alteração na API declarativeNetRequest provavelmente significaria a morte dessas extensões usadas por pelo menos 10 milhões de usuários da Internet.
Se essa API declarativeNetRequest (bastante limitada) acabar sendo a única maneira de os bloqueadores de conteúdo fazerem a lição de casa, significa basicamente que dois bloqueadores de conteúdo que eu mantenho há anos, o uBlock Origin e o uMatrix não podem mais existir, diz Hill.
Se a API webRequest permitiu conectar seus próprios controladores com acesso total às solicitações de rede e modificar o tráfego instantaneamente, a nova API declarativeNetRequest fornece acesso a um mecanismo de filtragem integrado universal pronto que processa independentemente as regras de bloqueio, não permite o uso de seus próprios algoritmos de filtragem e não permite regras complexas sobrepostas umas às outras de acordo com as condições.
O novo manifesto também apresenta outras alterações que afetam a compatibilidade com complementos
Entre eles estão:
- A transição para a execução de trabalhadores de serviço na forma de processos em segundo plano, o que exigirá que os desenvolvedores alterem o código de algumas adições;
- Novo modelo de solicitação de permissão granular: o suplemento não pode ser ativado imediatamente para todas as páginas (a permissão “all_urls” é removida), mas funcionará apenas no contexto da guia ativa, ou seja, o usuário deve confirmar o trabalho do complemento para cada site;
- Alteração no processamento de solicitações de origem cruzada : de acordo com o novo manifesto, as mesmas restrições de autoridade serão aplicadas aos scripts de processamento de conteúdo da página principal em que esses scripts são inseridos (por exemplo, se a página não tem acesso à API do local; portanto, o script de complementos também não obtém esse acesso);
- Proibição da execução de código baixado de servidores externos (estamos falando de situações em que um suplemento carrega e executa código externo).
Via: Ubunlog
