Le prochain Manifest V3 pour les extensions Google Chrome changera le fonctionnement des bloqueurs de publicités sur Chrome. Est-ce la bonne voie à suivre pour les bloqueurs de publicités et Google ?
Google Chrome est le navigateur Web multiplateforme le plus populaire actuellement disponible sur le marché, revendiquant 62,7 % de la part mondiale d’utilisation des navigateurs jusqu'en mai 2019, Safari d'Apple arrivant en deuxième position avec 15,89 % et Firefox de Mozilla revendiquant 5,07 %. En raison de sa part du lion, le moindre changement que Google Chrome entreprend pour sa plate-forme finit par affecter des millions d'utilisateurs à travers le monde. Ainsi, lorsque Google a annoncé la prochaine version du manifeste des extensions sous la forme de Manifest V3 pour les extensions Google Chrome, nous savions que nous nous allions subir de grands changements, en particulier lorsqu'il est apparu que Google intégrait une API de blocage de contenu dans Chrome lui-même.
Qu’est-ce que le Manifeste V3?
Si vous êtes un utilisateur actif de Chrome, vous utilisez sans aucun doute quelques extensions. Les extensions sont de petits logiciels qui personnalisent l'expérience de navigation à l'aide du API fournies par le navigateur, permettant aux utilisateurs d'adapter les fonctionnalités et le comportement à leurs besoins et préférences individuels. Ces extensions sont distribuées principalement à travers le Chrome Web Store, qui héberge plus de 180 000 extensions.
Depuis à la fin de l'année dernière, Google a travaillé sur "Manifest V3", un ensemble de modifications proposées à la plate-forme d'extensions Chrome qui peuvent être classées comme "modifications de rupture". Comme le document de discussion publique pour Manifest V3 États, la version du manifeste d’extension est un mécanisme permettant de restreindre certaines fonctionnalités à une certaine classe d’extensions. Ces restrictions peuvent prendre la forme soit d'une version minimale, soit d'une version maximale. La limitation à une version minimale permet aux API ou fonctionnalités les plus récentes d'être disponibles uniquement pour les extensions les plus récentes. tout en se limitant à une version maximale du manifeste, les anciennes API ou fonctionnalités peuvent être progressivement obsolète.
En termes plus simples, une nouvelle version du manifeste permet à Chrome de restreindre les API et les fonctionnalités à cette nouvelle version du manifeste, en afin de forcer les développeurs d'extensions à abandonner certaines anciennes API en raison de leur impact négatif sur l'utilisateur expérience. L'implémentation d'une extension dans Manifest V3 devrait théoriquement offrir des garanties plus fortes du point de vue de la sécurité, de la confidentialité et des performances.
Bien qu'un large éventail de changements soient décrits dans Manifest V3, le changement le plus controversé concerne la décision de Google de limiter les capacités de blocage présentes dans le système existant. chrome.webRequest API (et concentrer l'API sur l'observation au lieu du blocage), puis présenter ces capacités de blocage à travers un nouveau chrome.declarativeNetRequest API. Ce changement particulier a enflammé la communauté puisqu'il finit par cibler le mécanisme de blocage des publicités de la célèbre extension de blocage des publicités, Origine du bloc uBlock, et affecte directement ses plus de 10 millions d’utilisateurs.
Avant d'aborder ce problème, voyons comment le demande web L'API se compare à déclarativeNetRequest API.
API de requête Web et API de requête nette déclarative
Le présent
La description officielle de Web Request décrit l'API comme suit :
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Avec Web Request, Chrome envoie tous les données dans une requête réseau à l’extension qui les écoute. L'extension a alors la possibilité d'évaluer la demande et d'indiquer à Chrome quoi faire avec la demande: l'autoriser, la bloquer ou l'envoyer avec quelques modifications.
Suivez la séquence d'événements pour comprendre ce qui se passe lorsque les extensions utilisent l'API Web Request. Lorsqu'un utilisateur avec une extension Web Request installée clique sur un lien, Chrome informe l'extension qu'une demande de données a été effectuée avant que la demande n'atteigne le serveur. L'extension peut choisir de modifier la demande à ce stade. Le serveur répond alors, mais la réponse passe à nouveau par l'extension, et l'extension peut dicter si la réponse doit être modifiée. Chrome affiche ensuite enfin la page et l'utilisateur peut voir le résultat de son action de clic.
Alors que Chrome passe le relais toutes les données dans une requête réseau, les extensions qui utilisent l'API Web Request ont accès pour lire et modifier tout ce qu'un utilisateur fait sur le Web. Ainsi, alors que les bloqueurs de contenu comme uBlock Origin utilisent judicieusement le potentiel de cette API, Google affirme que d'autres extensions avec des intentions malveillantes en ont abusé pour accéder aux informations personnelles des utilisateurs. information. Selon Google, 42 % des extensions malveillantes utilisent l’API Web Request depuis janvier 2018. Google affirme également qu'il existe des « coûts de performances importants » liés à l'API en tant que version bloquante. cela nécessite un processus persistant et souvent de longue durée qui est fondamentalement incompatible avec une approche « paresseuse » processus.
Avec Manifest V3, Google propose de limiter cette API dans sa forme bloquante. Comme alternative, Google propose l’API Declarative Net Request.
L'avenir
La description officielle de Declarative Net Request décrit l'API comme suit :
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Avec Declarative Net Request, Chrome n'a pas besoin d'envoyer toutes les informations sur une requête à l'extension d'écoute. Au lieu de cela, l'extension enregistre des règles auprès de Chrome qui indiquent au préalable au navigateur quoi faire si certains types de requêtes sont détectés.
L'extension précise ses règles au préalable. La demande des utilisateurs est ensuite comparée à cette règle par le navigateur (et non par l'extension), et l'action est également entreprise par le navigateur, et la page est ensuite rendue. Google mentionne que cela leur permet d'assurer l'efficacité puisqu'ils peuvent exercer un contrôle sur l'algorithme déterminant le résultat et peuvent empêcher ou désactiver des règles inefficaces. Il présente également de meilleures garanties de confidentialité pour l'utilisateur final, car les détails de la demande réseau ne sont pas exposés à l'extension. Puisque les processus persistants et de longue durée ne sont plus nécessaires (puisque les règles sont enregistrées au préalable), Google affirme que cette approche apporte également des améliorations de performances qui rendront les extensions beaucoup plus viables sur des ressources limitées. plates-formes.
Declarative Net Request sera disponible à la fois pour Manifest V2 (actuel) et Manifest V3, mais ce sera le principal moyen par lequel Google autorisera la modification des requêtes réseau dans Manifest V3.
La controverse
Les changements apportés par Google semblent logiques jusqu'à ce que vous entendiez l'autre côté de l'histoire, principalement celui des bloqueurs de publicités. Cette migration d'API particulière est considérée comme le moyen utilisé par Google pour éliminer les bloqueurs de publicités, car elle modifie fondamentalement le fonctionnement de l'un des bloqueurs de publicités les plus populaires. Cela rejoint la « théorie » selon laquelle Google est davantage motivé par ce changement du point de vue commercial que du point de vue de la sécurité des utilisateurs. Après tout, Google dépend fortement de la publicité pour ses revenus, et les bloqueurs de publicités sont perçus comme une menace directe pour les clients de Google sur ce front, comme l'a révélé le rapport. Dépôt du formulaire SEC 10-K 2018 d'Alphabet (via Le registre):
Les technologies nouvelles et existantes pourraient affecter notre capacité à personnaliser les publicités et/ou bloquer les publicités en ligne, ce qui nuirait à notre activité.
Des technologies ont été développées pour rendre les publicités personnalisables plus difficiles ou pour bloquer complètement l'affichage des publicités et certains fournisseurs des services en ligne intègrent des technologies susceptibles de nuire aux fonctionnalités de base des services numériques tiers. publicité. La plupart de nos revenus Google proviennent des frais qui nous sont payés dans le cadre de l'affichage d'annonces en ligne. Par conséquent, ces technologies et outils pourraient avoir une incidence défavorable sur nos résultats d’exploitation.
Google a dû publier une déclaration pour résoudre ce problème, réitérant sa position selon laquelle le changement est dans l'intérêt de la vie privée des utilisateurs et non comme une attaque directe contre les bloqueurs de publicités :
Nous n’empêchons pas le développement de bloqueurs de publicités ni n’empêchons les utilisateurs de bloquer les publicités. Au lieu de cela, nous souhaitons aider les développeurs, y compris les bloqueurs de contenu, à rédiger des extensions de manière à protéger la confidentialité des utilisateurs.
Il faut faire référence à deux des bloqueurs de publicités les plus populaires disponibles sur Google Chrome: Origine du bloc uBlock et Adblock Plus, qui adoptent tous deux des approches différentes pour obtenir le même résultat de blocage de contenu. uBlock Origin s'appuie fortement sur l'API Web Request, et la communauté a privilégié cette extension au fil des années. Adblock Plus et d'autres extensions de blocage de contenu s'appuient également sur la partie blocage de Web Request, de sorte que les modifications apportées à cette API finiront par affecter la plupart des bloqueurs de contenu, au moins dans une certaine mesure.
La volonté de Google de déprécier Web Request tuera essentiellement uBlock Origin dans son format actuel, ce qui affectera en effet de nombreux utilisateurs. Alors que les utilisateurs peu fidèles (et n'ayant pas l'intention de se soucier de la manière dont le blocage des publicités est réalisé) trouveront des solutions alternatives qui comportent leurs propres inconvénients, cela deviendra impossible. pour les loyalistes et les passionnés de proposer de nouvelles conceptions de moteurs de filtrage pour contourner les différentes techniques que les sites Web finiront par proposer pour lutter contre les bloqueurs de publicités sur cette API spécifique.
Declarative Net Request a également été proposé comme moteur de filtrage plutôt limité, car il était initialement prévu avoir une limite de 30 000 règles de filtre statique par extension (règles déclarées lors de l'installation); et limite de 5 000 règles sur les règles de filtrage dynamique par extension (règles qui peuvent être ajoutées après l'installation). Toutes les règles excédentaires seront ignorées, ce qui pose un problème car EasyList pour Adblock Plus contient lui-même 70 000 règles, tandis que uBlock Origin peut être configuré pour fonctionner avec plus de 100 000 règles. Après la première réaction de la communauté, Google a répondu en promettant de modifier la limite des règles statiques de 30 000 règles par extension à un maximum global de 150 000 règles. Cela a alors pour effet secondaire d’empêcher les utilisateurs d’utiliser d’autres scripts riches en règles en conjonction avec un bloqueur de publicités, de sorte que les utilisateurs devront jongler avec leurs préférences.
Outre la limite de filtrage limitée, Declarative Net Request ne peut rediriger que vers des URL statiques, il n'y a donc aucune prise en charge incluse pour la correspondance de modèles. uBlock Origin s'appuie fortement sur la correspondance de modèles et sur le développeur de l'extension a déclaré qu'il n'était pas possible de moderniser l'algorithme de correspondance de son extension pour répondre aux exigences des API. L'API nécessiterait également une mise à jour complète de l'extension pour simplement mettre à jour la liste des filtres, ce qui serait une activité beaucoup trop fréquente compte tenu du fréquence à laquelle ces listes de filtres sont mises à jour. Bien entendu, ces mises à jour dépendraient également des critères et des processus d'examen des extensions de Google.
D'un autre côté, Google a toujours maintenu sa position selon laquelle son intention de s'éloigner des requêtes Web provenait d'une point de vue sécurité, car l'API Web Request est trop puissante dans sa forme actuelle et laisse une très large marge de manœuvre pour abus. Cet abus n'est pas que théorique, puisque Google a mentionné que 42 % des extensions malveillantes ont abusé de cette API. Apple Safari API du bloqueur de contenu a été conçu comme Declarative Net Request pour des raisons similaires, car il y a moins de place à exploiter pour un développeur malveillant. Sur la requête Web nerfée, les requêtes réseau seraient toujours observables, mais elles nécessiteraient des autorisations sur les hôtes concernés. Avec Manifest V3, les autorisations d'hôte changent également de manière significative et elles ne peuvent plus être accordées de manière globale au moment de l'installation.
Google a également utilisé les frais généraux de performance comme motivation pour le changement. L'évaluation des requêtes réseau a lieu dans le thread JavaScript de l'extension, ce qui peut être coûteux en performances. En guise de réfutation, le développeur d'uBlock Origin mentionne que son extension n'entraîne aucune pénalité de performance significative même en ayant jusqu'à 140 000 filtres statiques à appliquer. Les coûts encourus seraient facilement récupérés par les ressources qui ne peuvent pas être téléchargées à partir de serveurs distants et ne sont donc pas traitées par le navigateur.
Même si Google n'utilise pas ce raisonnement, un argument contre Web Request peut également être avancé en termes d'efficacité du blocage des publicités. Avec Web Request, si une extension ne répond pas à temps (en raison d'un décalage ou d'un crash), la demande de traitement du réseau est clairement autorisée, ce qui permet aux publicités de passer à travers le bloqueur de publicités. Declarative Net Request, en revanche, ne souffrirait pas de cet inconvénient. Au lieu de cela, les publicités seront diffusées si elles ne sont pas respectées par les règles statiques, et cela se produira le plus souvent.
Conclusion
D'après les explications ci-dessus, il est clair que Declarative Net Request n'est pas un clone de fonctionnalité 1:1 pour le blocage. capacités de l'API Web Request, et les développeurs d'extensions seront forcément vexés lorsque leur travail acharné sera handicapé par de tels changements. Mais le raisonnement de Google a également du poids: Web Request est trop puissant et ses pouvoirs doivent être améliorés. réduit dans l'intérêt plus large de la communauté des utilisateurs (qui comprend des utilisateurs moyens ainsi que passionnés).
L'évolution vers Declarative Net Request aurait également pu être une mesure de relations publiques positive: après tout, Google ajoute une API de blocage de contenu intégrée à Chrome! Mais comme la nouvelle API s’accompagne de lourdes restrictions, la communauté considère à juste titre cela comme une coupure d’ailes. Dans un monde idéal, Google aurait dû explorer le fonctionnement des bloqueurs de publicités comme uBlock Origin avant de proposer la nouvelle API. Dans l’état actuel des choses, la nouvelle API pourrait assouplir davantage ses limites de règles pour s’adapter aux scénarios dans lesquels les utilisateurs souhaiteraient utiliser deux extensions lourdes en filtres.
Selon Le registre, les premières versions avec les modifications de Manifest V3 seront disponibles à partir de juillet 2019. Nous espérons que Google tiendra compte des commentaires reçus de la communauté des développeurs d'extensions avec ces versions.
Un merci spécial au rédacteur en chef de XDA, Mishaal Rahman, pour sa contribution et son aide !
Edit: L'article assimilait à tort le fonctionnement d'Adblock Plus à celui de l'API Declarative Net Request. L'article a été modifié en conséquence. Adblock Plus sera également affecté par la suppression des capacités de blocage de l'API Web Request.