Lorsque Google a introduit Manifest V3 en 2019, les développeurs d’extensions Web ont été alarmés par la quantité de fonctionnalités qui seraient supprimées pour les fonctionnalités qu’ils fournissent aux utilisateurs. En particulier des fonctionnalités telles que le blocage des trackers et la fourniture de connexions sécurisées. Cette nouvelle itération de l’interface des extensions Web de Google Chrome présente encore des défauts qui pourraient être corrigés grâce à un consensus réfléchi de la communauté des développeurs d’extensions Web. Cependant, deux ans et le décompte des discussions et des conflits autour de Manifest V3 ont finalement révélé le pouvoir problématique de Google sur la façon dont des millions de personnes vivent le Web. Avec le plus annonce récente de la transition officielle vers Manifest V3 et de la dépréciation de Manifest V2 en 2023, de nombreuses extensions Web basées sur la confidentialité seront atténuées dans la manière dont elles sont capables de protéger les utilisateurs.

Les allégations de sécurité et de confidentialité de Google concernant les extensions Web peut être ou non adressé avec Manifest V3. Mais il n’en reste pas moins que les extensions sur lesquelles les utilisateurs se sont appuyés pour la confidentialité seront fortement ralenties si la proposition actuelle va de l’avant. Une décision qui a été présentée comme axée sur l’utilisateur, enlève en fait à l’utilisateur le pouvoir de bloquer le suivi indésirable pour ses besoins de sécurité et de confidentialité.

Grande influence, petit défi

Tout d’abord, une petite leçon d’histoire. En 2015, Mozilla a annoncé son intention d’adopter l’API webRequest, déjà utilisée par Chrome, dans le but de synchroniser le paysage pour les développeurs d’extensions Web. Avance rapide jusqu’à l’annonce de Manifest V3 en 2019, Google a mis Mozilla dans la position de choisir de diviser ou de synchroniser avec son navigateur Firefox. Le fractionnement signifierait prendre fermement position contre Manifest V3 en tant qu’alternative et soutenir l’innovation des développeurs d’extensions Web dans les contrôles de confidentialité des utilisateurs. La synchronisation signifierait suivre le plan de Google dans le but de ne plus diviser le développement d’extensions Web.

Mozilla a a décidé de soutenir API webRequest de blocage de Manifest V2 et MV3 déclarativeNetRequest API pour le moment. Un mouvement qui est en grande partie façonné par la volonté de Google de faire de MV3 la norme, la prise en charge des deux API n’est que la moitié de la bataille. MV3 dicte un changement d’écosystème qui limite les extensions MV2 et forcerait probablement les extensions basées sur MV2 à se conformer à MV3 dans un proche avenir. La reconnaissance de Mozilla que MV3 ne répond pas aux besoins des développeurs d’extensions Web montre que MV3 n’est pas encore prêt pour les heures de grande écoute. Pourtant, il y a une pression pour obtenir des extensions stables et fiables afin d’allouer des ressources pour porter leurs extensions vers des versions plus limitées d’elles-mêmes avec une API moins stable.

Problèmes techniques concernant le manifeste V3

Même si des progrès ont été réalisés en matière de sécurité et de confidentialité des navigateurs, des extensions Web telles que Blaireau de confidentialité, NoScript, et Origine de l’uBlock ont comblé le vide en fournissant le contrôle granulaire souhaité par les utilisateurs. L’un des changements les plus importants décrits dans Manifest V3 est la suppression du blocage API webRequest et la flexibilité qu’il a donné aux développeurs de gérer par programme les demandes de réseau au nom de l’utilisateur. Mis en file d’attente pour remplacer le blocage de l’API webRequest, le déclarativeNetRequest API comprend des casquettes basses sur combien de sites ces extensions pourraient couvrir. Un autre mandat consiste à passer des pages d’arrière-plan, un contexte qui permet aux développeurs d’extensions Web d’évaluer et de déboguer correctement, à un contexte alternatif moins puissant appelé Background Service Workers. Ce contexte n’a pas été construit à l’origine avec le développement d’extensions Web à l’esprit, ce qui a conduit à sa propre conversation dans de nombreux forums.

En bref, les Service Workers étaient destinés à un cycle veille/veille de livraison d’actifs Web à l’utilisateur, par exemple, la mise en cache d’images et d’informations cohérentes afin que l’utilisateur n’ait pas besoin d’utiliser beaucoup de ressources lorsqu’il se reconnecte à ce site Web avec une connexion limitée. Les extensions Web ont besoin d’une communication persistante entre l’extension et le navigateur, souvent basée sur l’interaction de l’utilisateur, comme la capacité de détecter et de bloquer les trackers publicitaires lorsqu’ils se chargent sur la page Web en temps réel. Cela a abouti à une liste importante de problèmes qui devront être résolus pour couvrir de nombreux cas d’utilisation valides. Ces discussions, cependant, ont lieu alors que les développeurs d’extensions Web sont invités à effectuer un portage sur MV3 l’année prochaine sans un flux de travail stable disponible avec des problèmes en suspens tels qu’aucun contexte de service worker défini pour les extensions Web, en attente Support WebAssembly, et manque de cohérence et de direct l’assistance de l’équipe des extensions Chrome elle-même.

Confidentialité SandStorm

Depuis l’annonce de Manifest V3, Google a annoncé plusieurs propositions controversées de « Privacy Sandbox » pour les mécanismes de confidentialité pour Chrome. Les discussions les plus importantes sur ces propositions se déroulent au sein du World Wide Web Consortium, ou W3C. Alors que techniquement « n’importe qui » peut écouter les réunions ouvertes, seuls les membres du W3C peuvent proposer une documentation formelle sur les spécifications et occuper des postes de direction. Être membre a le sien frais généraux et engagement de temps. C’est quelque chose qu’une grande multinationale peut facilement surmonter, mais cela peut constituer un obstacle pour les groupes axés sur les utilisateurs. À moins que ces dynamiques de pouvoir ne soient directement abordées, la voix d’un participant devient plus forte avec la part de marché.

Récemment cette année, après les nombreux Basé sur le forum Google discussions autour de Manifest V3, un Groupe communautaire WebExtensions a été formé dans le W3C. La participation à des groupes communautaires ne nécessite pas l’adhésion au W3C, mais ils ne produisent pas de normes. Présidé par des employés de Google et d’Apple, ce groupe déclare qu’en « spécifiant les API, les fonctionnalités et les autorisations de WebExtensions, nous pouvons permettre aux développeurs d’extensions d’améliorer encore plus facilement l’expérience de l’utilisateur final, tout en les déplaçant vers des API qui améliorent les performances et empêchent abuser de. »

Mais ce mouvement pour plus de démocratie aurait été plus puissant et efficace avant La poussée unilatérale de Google pour imposer Manifest V3. Cette histoire ressemble de manière décevante à ce qui s’est passé avec L’AMP de Google technologie : des discussions plus démocratiques et une gouvernance ouverte n’étaient proposées que après L’AMP était devenu omniprésent.

Avec l’abandon prévu des extensions Manifest V2, la décision a déjà été prise. Le reste de la communauté des extensions Web est obligé de se conformer, de s’écarter ou de quitter un grand écosystème d’extensions de navigateur qui n’inclut pas Chrome. Et c’est plus difficile qu’il n’y paraît : Chromium, le moteur de navigateur open source basé sur Chrome, est la base de Microsoft Edge, Opera, Vivaldi et Brave. Des déclarations ont été faites par Vivaldi, Brave et Opéra sur MV3 et leurs plans pour préserver les bloqueurs de publicités et les fonctionnalités de préservation de la confidentialité de MV2, mais les effets d’entraînement sont clairs lorsque Chrome apporte un changement majeur.

À quoi ressemble un meilleur MV3 ?

Certaines préoccupations et demandes très valables ont été soulevées auprès du groupe communautaire des extensions Web du W3C qui aideraient à propulser le domaine des extensions Web vers un meilleur endroit.

1. Rendez l’API déclarativeNetRequest facultative dans Chrome, comme c’est le cas actuellement. L’API fournit un chemin pour les extensions qui ont des fonctionnalités plus statiques et simplistes sans avoir besoin d’implémenter des API plus puissantes. Les extensions qui utilisent l’API de blocage webRequest, avec sa puissance supplémentaire, peuvent faire l’objet d’un examen plus approfondi lors de l’examen de la soumission.
2. Dans un effort pour apaiser les problèmes techniques autour des Background Service Workers, Mozilla a proposé dans le groupe W3C une alternative aux Service Workers pour les extensions Web, baptisée « Pages d’événements limitées ». Où cette approche restaure une grande partie des API de site Web standard et le support perdu avec les travailleurs de service en arrière-plan. Safari exprimé support, mais Chrome a exprimé manque de soutien avec des motifs en suspens mais non explicitement indiqués au moment de cet article.
3. Aucune autre introduction de régressions dans les fonctionnalités importantes de MV2. Par exemple, pouvoir injecter des scripts avant le chargement de la page. C’est rompu avec les amendements en attente dans MV3.

Même si l’on peut considérer les mouvements entre les modifications de l’API des extensions Web et les propositions de mécanisme de confidentialité comme deux efforts distincts, cela témoigne du pouvoir d’expansion de la manière dont une entreprise peut avoir un impact sur l’écosystème du Web ; à la fois quand ils font de grandes choses et quand ils prennent de mauvaises décisions. La question qui doit être posée est de savoir qui a la charge de faire respecter ce qui est juste : les organismes de normalisation qui s’engagent avec les propositions des grandes entreprises ou les entreprises elles-mêmes ? Deuxièmement, qui a le plus de pouvoir si une circonscription dit « non » et une autre dit « oui » ? Les partenaires communautaires, les défenseurs et les petites entreprises sont autorisés à dire non et à ne pas travailler avec des entreprises qui entrent fréquemment dans la salle avec des propositions inquiétantes, mais cette entreprise peut alors prétendre que le silence signifie un consensus lorsqu’ils décident d’aller de l’avant avec un plan. Une dynamique similaire s’est déjà produite lorsque le Le W3C aux prises avec Do Not Track (DNT) où les partisans de mécanismes de confidentialité plus faibles ont feint de se préoccuper de la confidentialité et du choix des utilisateurs. Ainsi, dans ce cas, les grandes entreprises comme Google peuvent prendre des décisions néfastes ou largement utiles sans trop d’incitation à se dire non. Dans le cas de MV3, ils ont donné de l’espace et du temps pour discuter des problèmes avec la communauté des extensions Web. C’est la norme minimale pour effectuer un changement aussi important, donc féliciter une entité puissante pour avoir fait de la place à de nombreuses autres voix ne ferait qu’ajouter au sentiment que cela devrait être la norme dans la politique Web ouverte.

Quelle que soit la signification d’une proposition, la réalité est que les expériences de millions de personnes sur Internet sont souvent laissées à l’éthique de quelques-uns dans les entreprises et les organisations de normalisation.