Contexte de la dépréciation de MV2

En 2022, Google a annoncé le remplacement du format Manifest V2 (MV2) par Manifest V3 (MV3) pour toutes les extensions Chrome. MV2 repose sur des pages d’arrière‑plan persistantes et un accès direct aux API réseau, ce qui permet aux bloqueurs de publicités d’intercepter chaque requête. MV3 impose un service worker à durée de vie limitée et une API declarativeNetRequest, conçue pour réduire la consommation de ressources mais qui restreint les capacités de filtrage dynamique.

Mécanisme de retrait du Chrome Web Store

Google a d’abord bloqué les nouvelles soumissions MV2 en janvier 2023, puis a commencé à retirer les extensions existantes à partir de juin 2023. La suppression finale a été appliquée en janvier 2024, date à laquelle le store n’affichait plus aucune extension MV2. Cette étape a été automatisée : le système a scanné le manifeste de chaque extension, a identifié la version ("manifest_version": 2) et a désactivé l’accès au store, tout en conservant les installations locales jusqu’à la prochaine mise à jour.

Impact sur uBlock Origin

uBlock Origin, le bloqueur de contenus le plus populaire sur Chrome, était encore distribué sous MV2 à l’époque du retrait. La suppression du store a immédiatement interrompu la possibilité pour les utilisateurs d’installer ou de mettre à jour l’extension via le Chrome Web Store. Les développeurs ont dû publier une version MV3, mais la nouvelle architecture ne supporte pas le webRequest API en mode bloquant, ce qui diminue l’efficacité du filtrage des scripts tiers. En conséquence, les performances de blocage ont chuté d’environ 15 % sur les pages à forte densité publicitaire, selon les benchmarks internes du projet.

Perspectives et contraintes techniques

Le passage à MV3 introduit une contrainte de règle déclarative limitée à 30 000 filtres, alors que les listes classiques de uBlock en contiennent plus de 200 000. Les développeurs peuvent contourner partiellement cette limite en combinant plusieurs règles ou en utilisant des dynamic rules, mais ces solutions augmentent le temps de compilation du service worker et consomment davantage de mémoire. De plus, le modèle d’exécution en arrière‑plan éphémère empêche le suivi d’état persistant, rendant plus difficile la mise en place de listes de suppression temporaires. Ces restrictions poussent les équipes à repenser l’architecture des bloqueurs, voire à explorer des alternatives hors‑store comme les extensions installées en mode développeur ou les solutions basées sur le DNS.