Non, Google ne veut pas interdire les bloqueurs de publicité dans Chrome

Alors que des changements dans la gestion des extensions dans Chromium sont en cours depuis la fin de l'année dernière, la modification du fonctionnement de certaines API pourrait limiter les possibilités d'analyse et de blocage des requêtes.

Google et les développeurs de Chromium préparent depuis un moment la migration des extensions vers la v3 de leur manifeste. La société était notamment revenu sur le sujet en octobre dernier, un document détaillant l'ensemble des modifications attendues ayant été de son côté publié, puis mis à jour en novembre.

L'idée est de revoir certains éléments afin de s'aligner avec des pratiques comme celles des service workers, d'améliorer la gestion des autorisations par les utilisateurs (ce qui ne sera pas difficile) et de renforcer la déclaration des API. Dans le lot, WebRequest ne devra plus être utilisée pour bloquer des éléments.

Cela ne signifie pour autant pas la mort des bloqueurs de publicités.

L'usage de WebRequest en question

Cette API permet, comme le fait Kimetrak (voir notre dossier), de suivre les requêtes traitées par le navigateur puis de les analyser et/ou de les bloquer, retarder, etc.

Un mode jugé trop impactant sur les performances. L'équipe précise bien que la version bloquante de WebRequest actuellement utilisée sera limitée et découragée, mais ne parle pas d'une suppression totale pour le moment. De plus, une alternative va être introduite : DeclarativeNetRequest.

Cette nouvelle API (voir sa documentation), qui s'inspire de la méthode introduite par Apple dans Safari il y a quelques années, est focalisée sur le blocage de contenu (et donc de publicités). Plutôt que de se placer dans le flux de la requête pour la contrôler, elle permet à une extension de communiquer avec le navigateur pour lui dire quoi en faire.

Ce mode de fonctionnement est jugé plus efficace par les développeurs de Chromium puisqu'il est géré directement par le navigateur et non dans le processus de l'extension via JavaScript, consomme moins de mémoire, est mieux géré par le DOM et nécessite moins de permissions de la part de l'utilisateur. 

Surtout, les informations détaillées sur la requête ne sont plus accessibles à l'extension, ce dont les utilisateurs n'ont pas forcément conscience lorsqu'ils utilisent ces outils. Enfin, le navigateur garde le contrôle et peut « désactiver les règles jugées inefficaces ». Bref, c'est une version allégée, mais plus efficace.

Google et les bloqueurs : une cohabitation improbable mais nécessaire

Il n'en fallait pas moins pour que le petit monde des bloqueurs de publicité s'agite et que l'on commence à lire ici ou là que Google débutait une guerre à leur encontre. De telles rumeurs reviennent régulièrement mais n'ont jamais vraiment été fondées. Elles trouvent leur existence dans le fait que Google vit principalement de la publicité et de la collecte de données, la société est donc forcément opposée à la pratique du blocage.

Mais celle-ci est massive, pour une bonne raison : les publicitaires et éditeurs abusent tellement, notamment en matière de pistage des internautes, parfois au mépris de la loi, que les utilisateurs n'ont que cette méthode pour se protéger de leurs pratiques. Google le sait, et c'est notamment pour cela qu'il ne s'attaque pas à ces extensions sur ses Store et dispose d'API leur permettant de fonctionner, tant sur ordinateur que sur mobile.

La société sait aussi que ses concurrents sont là et n'ont que faire du blocage ou non de la publicité. Certains en font même un argument. Firefox se renforce clairement sur ce terrain ces derniers mois et des navigateurs comme Brave ont intégré le blocage au cœur de leur fonctionnement pour le rendre plus efficace.

Certaines extensions touchées, mais pas toutes

Sur le fond, ce changement n'impactera pas la plupart des bloqueurs déjà en place. Mais comme le note Raymond Hill, développeur pour uBlock Origin et uMatrix, un passage forcé à l'API DeclarativeNetRequest impacterait directement ces deux outils qui peuvent analyser et modifier en profondeur les requêtes des utilisateurs.

Depuis, d'autres développeurs se sont joint à la discussion afin d'alerter les équipes de Chromium sur l'impact de ce changement pour leurs propres services. Cet échange et ses suites seront intéressants à suivre, afin de voir ce qui sera décidé au final. Car DeclarativeNetRequest est pour le moment en test, WebRequest toujours accessible.

Des changements peuvent donc encore largement intervenir, notamment sur la limitation à 30 000 règles par extension, jugée bien trop restrictive. Les développeurs de Chromium décideront-ils de continuer à proposer une version bloquante de WebRequest, sous réserve que l'utilisateur et les développeurs soient avertis de l'impact sur les performances ? La nouvelle API va-t-elle être renforcée pour combler certains des besoins exprimés ?

Affaire à suivre... mais il ne faut pas oublier une chose : Chrome se base sur le projet Chromium, open source. Si les choix mis en place ne plaisent pas, ils pourraient pousser la communauté à proposer de nouveaux dérivés (Brave, Vivaldi ou Opera en sont déjà), les bloqueurs de publicités concernés pouvant inciter leurs utilisateurs à changer de crèmerie.

Même si Chrome est actuellement le leader incontesté du marché, et que l'omniprésence des services de Google y est vu comme un avantage pour de nombreux utilisateurs, la société n'est pas spécialement bien vue ces dernières années. Notamment en raison de ses abus en matière de respect de la vie privée.

Et s'il y a bien une chose que ces 20 dernières années nous ont apprises en matière de géant du numérique et de position de leader, notamment dans le domaine des navigateurs... c'est que tout peut très vite basculer.