Extensions Chrome : Google pourrait renoncer aux modifications annoncées,

Une analyse révèle que des extensions sont conformes au Manifest V3

Google l’avait annoncé depuis la fin de l’année dernière qu’en début de cette année, une nouvelle version du manifeste des extensions Chrome sera disponible, le Manifest V3. La firme indiquait que le Manifest v3 entraînerait des changements supplémentaires sur la plateforme, visant à renforcer la sécurité, la confidentialité et les garanties de performance. « Nous voulons aider tous les développeurs à œuvrer pour le succès. Écrire une extension sécurisée et performante dans Manifest v3 devrait être facile, tandis que l'écriture d'une extension non sécurisée ou non performante devrait être difficile », avait-elle annoncé dans un billet de blogue en octobre 2018. Certains objectifs clés du Manifeste V3 incluaient :

• des API déclaratives de portée plus restreinte, pour réduire le besoin d'un accès trop large et permettre une implémentation plus performante du navigateur, tout en préservant des fonctionnalités importantes ;
• des mécanismes supplémentaires plus simples permettant aux utilisateurs de contrôler les autorisations accordées aux extensions ;
• un modernisme pour s'aligner sur les nouvelles capacités Web, par exemple en supportant Service Workers comme nouveau type de processus d'arrière-plan.

Depuis la mise jour de ce manifeste, les bruits ne cessent de courir. Beaucoup de développeurs d’extensions semblent être contre quelques points clés évoqués par Google dans son Manifest v3. Plusieurs parmi ces derniers soulignent le fait que les changements au sein des API notamment l’API WebRequest pourrait désactiver une panoplie extensions de la plateforme d’extensions de Chrome. « Si cette API declarativeNetRequest (assez limitée) finit par être le seul moyen pour les bloqueurs de contenu d'accomplir leur tâche, cela signifie essentiellement que, deux bloqueurs de contenu que j'ai maintenus pendant des années, uBlock Origin ("uBO" et uMatrix, ne peuvent plus exister », avait écrit Raymond Hill, développeur de l’extension uBlock Origin en début de ce mois.

Ses propos faisaient suite à la publication de Google qui précisait que « dans la version 3 du manifeste, nous allons nous forcer à limiter la version bloquante de l’API webRequest en procédant à une potentielle suppression des options de blocage de la plupart des événements. L’implémentation non bloquante de l’API qui permet aux extensions d’observer les requêtes, mais pas de les modifier, rediriger ou bloquer (et donc, n’empêche pas Chrome de poursuivre avec le traitement de la requête) ne sera pas modifiée. Comme alternative, nous prévoyons de fournir l’API declarativeNetRequest ». Beaucoup d’autres avis contre ce changement se sont fait entendre, la plupart des développeurs d’extensions.

À ce jour, les discussions entre développeurs, utilisateurs finaux et l’équipe de développement de Chromium battent le plein sur la liste de diffusion dans le contexte de l’annonce de la disponibilité (dès juillet 2019) pour tous les utilisateurs de Chrome du bloqueur de publicité fait maison de la firme de Mountain View. Andrew Meyer de l’équipe de développement de Chromium a réagi et sa sortie laisse penser que les futurs développements à ce sujet pourraient aller dans le sens de satisfaire les développeurs. « Ce changement n'est pas destiné à estropier les bloqueurs de publicité. Il est plutôt conçu pour les rendre plus rapides et plus sûrs même en dépit des limitations qui pourraient avoir un impact sur uBlock. La nouvelle API de blocage de contenu proposée n'est pas finale et peut (ou sera) modifiée », s’est justifié Andrew Meyer.

Ainsi, c'est pour faire la lumière sur ces différentes incompréhensions entre l’équipe de développement de Google Chrome et les développeurs d’extensions que la firme a procédé à ce qu’elle appelle une analyse de performance des extensions les plus populaires du Chrome Store avec la nouvelle version du manifeste. Elle dit alors avoir fait trois remarques importantes selon lesquelles les bloqueurs de contenu populaires sont très efficaces avec un temps de décision médian inférieur à une milliseconde par demande ; les allégations de performance manifeste v3 ne sont pas valables d’après certaines mesures et, pour finir, l’adblocker utilisé par Cliqz et Ghostery fonctionne toujours aussi bien, voire mieux que les autres bloqueurs de contenu populaires.


L’étude de Google, faisait une comparaison entre quelques bloqueurs de contenus populaires tels que l’Adblocker de Ghostery et Cliqz, le bloqueur de Brave, l’Adblocker de DuckDuckGo, uBlock Origin et Adblock Plus. La plupart de ces bloqueurs à l’exception de uBlock sont disponibles sous forme de bibliothèques JavaScript et peuvent être chargés dans Node.js, précise Google. Pour ce qui est du fait que l’étude n’a pas pris en compte les bloqueurs natifs de Safari et des projets Chromium, Google a expliqué que cela nécessiterait des efforts importants pour les conditionner de manière à pouvoir les comparer avec les autres bibliothèques. Il dit vouloir aborder ce point dans ses prochains travaux.

Les différentes analyses menées tournent autour de sept points essentiels qui sont : la compositions d’une demande (chaque demande de réseaux peut soit être bloquée ou soit autorisée par le bloqueur de contenu), le temps nécessaire pour répondre à toutes les demandes, le temps nécessaire pour apparier les demandes qui ne sont pas bloquées et celui nécessaire pour les demandes bloquées, la sérialisation et la désérialisation, la consommation de mémoire au démarrage et les listes d’analyse des bloqueurs. Les mesures sur le temps nécessaire pour apparier les demandes bloquées montrent que Ghostery surpasse les autres bibliothèques en matière de vitesse d'adaptation. Sans entrer dans trop de détails, voici quelques optimisations pouvant expliquer ces résultats :

• Ghostery utilise un index inversé associant des jetons à des filtres. « Contrairement aux autres bibliothèques, nous nous assurons de choisir le meilleur jeton pour chaque filtre au moment de la construction (il est préférable de définir le jeton le moins vu ). Cela entraîne des coûts supplémentaires non récurrents, mais optimise les capacités de répartition », ajoute Google ;
• les filtres sont stockés sous une forme très compacte, dans des tableaux typés, et ne sont chargés que dans la mémoire, quand ils risquent d'être bloqués (si nous rencontrons des jetons identiques dans les URL) ;
• les filtres chargés en mémoire sont optimisés à la volée et plusieurs filtres peuvent être combinés pour une efficacité accrue. Les optimisations ont été soigneusement élaborées en fonction des cas courants observés dans Easylist.

Google précise en conclusion s’être concentré dans son étude sur l’efficacité du moteur de filtrage réseau des bloqueurs, qui représente la tâche la plus intensive en ressources CPU. Il (Google) profite donc de l’occasion pour répondre à quelques controverses formuler dans la proposition du manifeste v3 comme celle-ci : “l’extension exécute un code JavaScript arbitraire (potentiellement très lent)”. Voici ce que répond Google à propos :

Source : Whotrackme

Et vous ?

Que pensez-vous de cette analyse de Google ?

Voir aussi

Extensions Chrome : Google annonce des changements à venir qui visent à améliorer la sécurité ainsi que l'expérience utilisateur

Navigateur Chromium : des changements annoncés dans l'API pourrait désactiver une panoplie d'autres extensions et pas seulement uBlock Origin

C'est officiel, Microsoft Edge sera désormais basé sur Chromium et enfin disponible sur Windows 7, Windows 8 et d'autres plateformes comme macOS

Mozilla n'est pas du tout content de l'adoption de Chromium par Microsoft, les navigateurs non basés sur la techno de Google sont-ils en danger ?

Comme Microsoft Edge, Brave adopte à son tour Chromium avec Brave 0.57 et assure que la nouvelle version de son navigateur est plus rapide de 22%