Dans le cadre d'une V3 de son manifeste (Manifest V3 ; une préversion pour les développeurs est en cours d'élaboration), Google envisage des changements pour le modèle des WebExtensions avec son navigateur Chrome.

Google souhaite introduire une API declarativeNetRequest ayant pour vocation de se substituer à l'API webRequest (qui ne va toutefois pas être complètement supprimée) pour le blocage de contenu dans les extensions. Il y aura alors une gestion directe par le navigateur.

Les raisons mises en avant sont un impact (supposé) sur les performances, ainsi que des soucis de sécurité et confidentialité. Or, des développeurs de bloqueurs de pub s'appuient sur la technologie webRequest.

S'ils ont tiqué, c'est notamment à cause d'une limite à 30 000 règles par extension pour l'API declarativeNetRequest qui est jugée insuffisante comme par exemple avec la liste de blocage EasyList. C'est une limite pendant l'installation, et avec une limite à 5 000 pendant l'exécution.

Google a déjà tenté d'étouffer la polémique en assurant que son objectif " n'est pas et n'a jamais été d'empêcher ou de casser le blocage de contenu " et que la prise en charge des bloqueurs se poursuivra. La limite du nombre de règles est en outre susceptible d'être revue à la hausse.

Toutefois, de nouvelles précisions ont ravivé les craintes. " Chrome déprécie (ndlr : rendre obsolète) les capacités de blocage de l'API webResquest dans Manifest V3, pas l'API webRequest en entier (bien que le blocage sera toujours disponible pour les déploiements d'entreprises). "

Pour 9to5Google qui a mis en lumière cette petite phrase, cela revient à dire que Chrome aura toujours la capacité de bloquer le contenu, mais que cela concernera seulement les utilisateurs d'entreprises de Chrome qui paient. Autrement dit et pour le commun des utilisateurs de Chrome, ce sera le passage à la nouvelle API declarativeNetRequest pour les bloqueurs de contenu avec ses limitations inhérentes.

Google tirant l'essentiel de ses revenus de ses activités dans la publicité, la situation est largement commentée. Rappelons toutefois qu'un bloqueur de pub natif a été intégré dans Google Chrome afin de bloquer les publicités intrusives au sens des normes définies par la Coalition For Better Ads.

Pour Raymond Hill, le développeur de uBlock Origin, Google Chrome adopte une nouvelle approche maintenant qu'il est le navigateur dominant et déprécie la capacité de blocage de l'API webRequest pour rependre le contrôle et favoriser son activité principale (la publicité). Il vante par contre l'approche de Firefox. À CNET, Mozilla déclare que " Firefox continue de permettre aux extensions de blocage de la publicité de fonctionner dans le navigateur. Nous n'avons pas de plans à ce stade pour changer cela. "

Parmi les réactions d'employés de Google, Chris Palmer (ingénierie de sécurité logicielle sur Chrome) réaffirme qu'il n'est pas question de casser les bloqueurs de contenu, mais de faire en sorte que les extensions fonctionnent de manière plus sûre et potentiellement plus rapide (pas de communication inter-processus et d'aller-retour de C++ à JavaScript).

À 9to5Google, un porte-parole de Google a en outre déclaré : " Chrome prend en charge l'utilisation et le développement de bloqueurs de pub. Nous travaillons activement avec la communauté des développeurs afin d'obtenir des commentaires et réfléchir à la conception d'un système de filtrage de contenu respectueux de la confidentialité qui limite le nombre de données sensibles du navigateur partagées avec des tiers. "