Manifest V3, la nouvelle API d'extension de Chrome, n'est plus une menace illusoire. C'est désormais la nouvelle réalité dans laquelle des dizaines d'extensions de blocage des publicités, dont l'extension AdGuard Browser, vont (ou ne vont pas) fonctionner.

La vague du manifeste V3 s'est construite progressivement mais inexorablement. En 2018, lorsque Google a publié pour la première fois un document décrivant la nouvelle API, la communauté des développeurs a éclaté en critiques. Nous ne sommes pas restés à l'écart non plus et avons publié plusieurs articles décrivant les possibles conséquences négatives de la mise en œuvre de Manifest V3 et avons même exprimé l'espoir que "les choses ne tourneront pas si mal".

Malgré le scandale suscité, Manifest V3 est devenu disponible à la fin de 2020, en même temps que Chrome 88 Beta. Depuis janvier 2022, il est devenu impossible d'ajouter de nouvelles extensions basées sur Manifest V2 dans le Chrome Web Store. La dernière phase du lancement arrivera très bientôt : à partir de janvier 2023, toutes les extensions basées sur Manifest V2 cesseront de fonctionner, même celles qui ont été ajoutées au Chrome Web Store auparavant.

Si vous utilisez AdGuard pour Windows, Mac ou Android, vous ne devez pas vous soucier de MV3. Ces logiciels ne sont limités par aucun navigateur.

Heureusement, nous sommes prêts pour ça.

Extension expérimentale de navigateur AdGuard MV3

Au milieu de l'année 2021, nous avons commencé à travailler sur le prototype d'une nouvelle extension qui serait capable de bloquer les publicités même dans les limites strictes de Manifest V3. La tâche n'était pas facile : la nouvelle API était encore brute, certains aspects étaient en cours de finalisation et ne fonctionnaient pas comme prévu. Mais nous nous en sommes sortis, bien sûr, et avons prouvé que les bloqueurs de publicité survivront même après l'apocalypse qu'est Manifest V3.

Pendant le développement du prototype, nous avons été confrontés à de nombreux problèmes graves causés par les fonctionnalités de la nouvelle API : nous avons réussi à en surmonter certains, et nous avons dû nous réconcilier avec d'autres. Nous parlerons de chacun d'entre eux en détail.

En attendant, si vous voulez l'essayer, vous pouvez l'installer depuis Chrome WebStore.

Voici une courte vidéo qui montre comment cela fonctionne.

Les limites des règles

Si vous ne savez pas ce que sont les règles de filtrage et comment fonctionne le blocage des publicités en général, ou si vous souhaitez rafraîchir vos connaissances, visitez notre base de connaissances pour une brève explication.

Toutes les règles incluses dans les filtres des extensions ont été divisées par Manifest V3 en règles statiques (intégrées) et dynamiques et puis leur nombre a été drastiquement limité.

Pour les règles statiques, Chrome a fixé une limite minimale garantie de 30 000 règles par extension et une limite totale de 330 000 règles pour toutes les extensions installées par un seul utilisateur (ceci prend également en compte la limite de 1 000 règles regexp par extension). Le problème est qu'une seule extension peut obtenir la totalité de la quantité de règles autorisée, ou il peut y en avoir plusieurs, et alors peut-être que certaines des extensions ne respecteront pas la limite.

Si ceci se passe avec notre extension (et ça peut se produire à tout moment, par exemple après une mise à jour, un redémarrage par l'assistance technique, un changement de filtre défini dans nos bloqueurs ou ceux des tiers), elle affichera un message disant que le navigateur a modifié la liste des filtres actifs et n'a laissé que le filtre publicitaire de base d'AdGuard activé. Dans le pire des cas, même le filtre de base pourrait ne pas être activé, car il contient plus de 30 000 règles. L'utilisateur se retrouverait alors sans protection AdGuard.

Tous ces cas sont envisagés par nous et sont affichés sur un écran séparé avec une description de ce que le navigateur a désactivé et de ce qu'il a laissé activé.

Pour les règles dynamiques, auxquelles les utilisateurs peuvent ajouter leurs propres règles ou filtres, il existe une toute petite limite de 5 000, y compris la limite de 1 000 règles regexp. Si cette limite est dépassée, AdGuard MV3 ne pourra appliquer que les 5 000 premières règles et le reste restera inactif.

Les notifications quand la limite est dépassée se présenteront de manière suivante :

Les restrictions de Manifest V3 nuisent non seulement à la qualité du filtrage et à l'expérience des utilisateurs, mais aussi à la communauté des développeurs de filtres. Auparavant, n'importe qui pouvait créer un filtre pour lui-même, et avec le temps, un tel filtre pouvait devenir populaire et se retrouver sur la liste des bloqueurs recommandés. Aujourd'hui, il est beaucoup plus difficile d'y parvenir. Après tout, les bloqueurs doivent utiliser des filtres prédéfinis (pas plus de 50), et nous devons être très sélectifs quant aux filtres qui seront disponibles pour les utilisateurs. Bien sûr, vous pouvez toujours définir votre propre filtre manuellement. Mais n'oubliez pas la limite de 5000 règles sur tous les filtres personnalisés et les règles utilisateur.

La description plus détaillée des problèmes comprend de nombreux détails, essentiellement compréhensibles pour les développeurs. Si vous n'êtes pas un technicien, vous pouvez sauter cette partie.

Règles déclaratives

Avant l'introduction de Manifest V3, le moteur de filtrage était construit dynamiquement à partir de filtres téléchargés du serveur par l'extension. De plus, les règles qui composaient les filtres étaient appliquées aux étapes différentes du chargement de la page.

Par exemple, les règles pouvaient être déclenchées avant que le navigateur n'envoie la requête : dans l'événement onBeforeRequest, le navigateur demandait à l'extension ce qu'elle devait faire avec une requête particulière, et l'extension réagissait dynamiquement en la bloquant ou en la redirigeant. Les règles cosmétiques étaient appliquées un peu plus tard, lorsque la page était déjà chargée et que le DOM apparaissait.

Depuis l'entrée en vigueur de Manifest V3, la méthode onBeforeRequest ne peut plus être appliquée. À la place, Chrome suggère d'utiliser l'API declarativeNetRequest, avec laquelle le droit de modifier les requêtes est donné au navigateur. L'extension annonce uniquement un ensemble de règles déclaratives selon lesquelles le navigateur modifiera ou bloquera les requêtes réseau.

La syntaxe des règles déclaratives

La syntaxe des règles déclaratives est assez différente de la syntaxe couramment utilisée par les bloqueurs de publicité modernes. De nombreux membres de la communauté renonceront probablement à travailler dans Manifest V3 pour éviter de prendre le temps de créer des règles réservées à Chrome.

Chaque règle doit être constituée de champs :

• id – l'identifiant de la règle. Peut être utilisé pour associer une règle déclarative à une règle textuelle.
• priority – la priorité de la règle. Elle détermine comment la règle sera appliquée à la requête.
• action – l'action d'une règle.
  Il'y en a trois types:
  • block – actions qui bloquent les requêtes.
  • redirect ou upgradeScheme – actions qui redirigent les requêtes.
  • allow or allowAllRequests – actions qui permettent les requêtes.
• condition – condition sous laquelle une règle est appliquée.

Exemple de règle :

{
  "id": 1,
  "priority": 1,
  "action": { "type" : "block" },
  "condition": {
    "urlFilter": "abc",
    "domains": ["example.org"],
    "resourceTypes": ["script"]
  }
}

Cette règle bloquera toutes les requêtes vers des scripts dont l'adresse contient une sous-chaîne abc et qui proviennent du site avec le domaine
example.org.

La situation actuelle provoque une forte impression de déjà-vu : lors du développement de l'extension de blocage des publicités pour Safari, nous avons dû trouver un moyen de convertir la syntaxe de nos règles à celle imposée par les développeurs du navigateur. Cette fois, nous utilisons une solution similaire pour transformer notre syntaxe en règles déclaratives pour Chrome.

Pour convertir les règles statiques et dynamiques, nous avons ajouté un module à notre bibliothèque @adguard/tsurlfilter. La bibliothèque parcourt les règles de filtrage et les convertit en règles déclaratives, puis les combine en ensembles de règles et les stocke dans des fichiers .json. La bibliothèque construit une table de correspondance entre les règles textuelles et les règles JSON afin que la connexion entre elles ne soit pas perdue.

Voici quelques exemples du fonctionnement du convertisseur :

La règle ||example.com^$script est convertie en

{
    "id": 1,
    "action": {
        "type": "block"
    },
    "condition": {
        "urlFilter": "||example.com^",
        "resourceTypes": [
            "script"
        ],
        "isUrlFilterCaseSensitive": false
    }
}

La règle @@||example.com^$script$domain=example.org est convertie en

{
    "priority": 1,
    "id": 23,
    "action": {
        "type": "allow"
    },
    "condition": {
        "urlFilter": "||example.com^$script",
        "initiatorDomains": [
            "example.org"
        ],
        "isUrlFilterCaseSensitive": false
    }
}

La plupart des règles sont converties correctement, mais certaines fonctionnalités sont perdues à cause de nombreuses restrictions :

• $removeparam ne prend pas en charge les exclusions (~) et les expressions régulières (regexp)
• Pour les expressions régulières Chrome utilise sa propre implementation des expressions de ce type, de sorte qu'une partie de la fonctionnalité standard n'est pas prise en charge. Par exemple, il s'agit d'expressions régulières contenant des rétro-références, des anticipations négatives et des quantificateurs possessifs.
• negative lookahead est souvent utilisée dans les filtres. Une recherche rapide a montré qu'il y a actuellement 43 règles avec cette expression dans les filtres AdGuard. Au premier abord, ce n'est pas beaucoup, mais gardez à l'esprit que la plupart de ces règles sont censées fonctionner sur de nombreux domaines différents, donc je dirais que cette seule limitation paralyse le blocage des publicités sur plus de 1000 sites web.
• Les expressions régulières sont validées par Chrome en fonction de la quantité de mémoire consommée. Étant donné que nous ne savons pas exactement quel type d'implémentation est utilisé dans ce cas, il peut y avoir quelques problèmes avec certaines expressions régulières.
• Les règles des Cookie ne sont pas prises en charge.
• Il y a beaucoup d'autres problèmes que nous n'avons pas mentionnés ici pour ne pas encombrer le texte.

Le problème des règles déclaratives est assez évident : leur syntaxe limite considérablement ce que notre extension peut faire. Et, frustrant que ce soit, nous ne pouvons rien y faire, sauf espérer que les développeurs de Chrome l'amélioreront au fil du temps.

Ensembles de règles

Selon la nouvelle API, les règles déclaratives doivent être combinées dans des ensembles de règles.

Un exemple d'intégration d'un ensemble de règles dans Manifest V3 :

{
  "name": "AdGuard AdBlocker MV3",
  "version": "1",
  "declarative_net_request": {
     "rule_resources": [{
       "id": "ruleset_1",
       "enabled": true,
       "path": "rules.json"
     }]
   },
   …
}

Les ensembles de règles sont spécifiés dans le fichier manifest.json et ne sont chargés que lorsque l'extension est installée ou mise à jour. Et ceci est aussi un énorme problème. Parfois, une règle de filtrage casse la mise en page ou les performances d'un ou plusieurs sites web. Avec une telle quantité de règles, c'est presque impossible statistiquement d'éviter complètement des incidents de ce type. De plus, les sites web évoluent constamment et des règles qui ne posaient pas de problème auparavant peuvent en poser aujourd'hui. Mais ce n'est pas grave : nous avons une solution simple à ce problème.

Imaginez qu'une telle règle soit dans le filtre et que vous ayez besoin de la désactiver rapidement. Dans l'extension Manifest V2, le modificateur $badfilter était utilisé à cet effet. Les développeurs de filtres ajoutent une règle avec le modificateur spécifié, l'extension est mise à jour dynamiquement, la nouvelle règle désactive la règle en question et les choses s'améliorent. Comme vous l'avez compris, cette "astuce" ne fonctionnera pas avec Manifest V3.

Désormais, vous pouvez vous attendre à ce que les filtres ne soient pas mis à jour pendant plusieurs jours d'affilée : après avoir ajouté la nouvelle version au Chrome Store, vous devez attendre que la révision soit passée. Malheureusement, il n'y a pas d'autre moyen de fournir aux utilisateurs des filtres mis à jour. La discussion sur la possibilité d'activer et de désactiver des règles individuelles donne un peu d'espoir. Il y a une petite chance que les extensions soient dotées de la fonctionnalité de mise à jour rapide des filtres après tout.

Les statistiques et le journal de filtrage

L'extension de navigateur AdGuard, basée sur Manifest V2, dispose d'un journal de filtrage qui montre toutes les requêtes envoyées par votre navigateur et des informations détaillées à leur sujet. En particulier, vous pouvez voir quelle règle de filtrage a été utilisée pour bloquer telle ou telle règle.

Étant donné que Chrome lui-même bloque désormais les requêtes et partage les statistiques uniquement avec les extensions décompressées et installées en mode développeur, nous ne pouvons pas mettre en œuvre le journal de filtrage comme nous le faisions auparavant. Mais nous pouvons proposer une alternative particulière, ce que nous prévoyons de faire dans la version finale de l'extension.

Donc, quand vous ouvrez le journal de filtrage, un moteur qui fonctionne selon les règles de Manifest V2 sera lancé. Il ne fera rien avec les requêtes, mais montrera seulement quelles règles ont pu être appliquées. En comparant les statistiques de Chrome avec les résultats de l'ancien moteur, nous aurons une image approximative de la façon dont les demandes sont traitées.

La version actuelle du prototype n'implémente pas de journal de filtrage. Les développeurs de filtres devront utiliser le mécanisme recommandé par les développeurs de Chrome à sa place. Vous pouvez toujours obtenir des informations sur la règle déclenchée. Mais il y a un bémol : vous devez installer l'extension sous une forme "déballée". Autrement dit, vous devrez cloner notre dépôt, "construire" l'extension, faire passer le navigateur en mode développeur, et ce n'est que dans ce cas que vous pourrez utiliser les outils de débogage des filtres.

Service worker

Avec Manifest V3, la page d'arrière-plan a disparu. La page d'arrière-plan est un processus d'arrière-plan séparé où les extensions pouvaient maintenir leur état et travailler avec les API du navigateur (comme le onBeforeRequest mentionné précédemment). Dans Manifest V3, cette page est remplacée par un service worker, qui est souvent interrompu par le navigateur.

Lorsque le navigateur arrête le service, l'extension se met en mode veille : les règles déclaratives fonctionnent, mais pas les règles cosmétiques qui sont chargées dynamiquement. Pour que l'extension soit fonctionnelle, quelque chose doit réveiller le travailleur de service : il peut s'agir du chargement d'une page ou d'un message qui a été envoyé au travailleur de service.

Lorsque le service est réactivé, l'extension commence à lire les règles de filtrage dans le référentiel et à les traiter pour pouvoir ensuite les retrouver rapidement. Pendant ce temps, pendant 1,5 à 2 secondes, l'extension n'applique pas de filtrage cosmétique, mais les demandes de publicité sont bloquées par le navigateur lui-même. Ensuite, le moteur se lance et les publicités disparaissent. Nous prévoyons de réduire le temps de réveil du travailleur de service et de nous efforcer de déplacer la plupart des règles cosmétiques vers le script de contenu (qui travaille dans le contexte de la page Web et ne se fait pas tuer toutes les minutes), mais dans certains cas, nous aurons encore besoin du travailleur de service.

Conclusion

Malgré les limitations de Manifest V3, AdGuard MV3 vous protège toujours très bien contre les publicités et le suivi :

• Bloque les requêtes aux traqueurs de manière proactive.
• Masque les bannières, les widgets sociaux et autres éléments gênants.
• Bloque les publicités sur les plateformes de partage de vidéos, y compris YouTube.

Bien que l'extension expérimentale ne soit pas aussi efficace que son prédécesseur, la plupart des utilisateurs ne sentiront pas la différence. La seule chose que vous pourriez remarquer est le scintillement des publicités dû au décalage dans l'application des règles cosmétiques.

L'objectif de ce prototype est de tester la nouvelle approche et de recueillir vos commentaires. Alors, s'il vous plaît, essayez-le et faites-nous savoir ce qui peut être amélioré. Comme d'habitude, ce prototype est open source et publié sur Github. Si vous rencontrez un problème avec ce prototype ou si vous avez une suggestion, veuillez la poster sur Github et nous vous écouterons.

En publiant aujourd'hui une extension construite avec Manifest V3 - la première parmi les développeurs de bloqueurs de publicité - nous pouvons dire que nous avons relevé le défi que Google nous avait lancé. Il reste encore beaucoup de travail à faire, mais nous pouvons d'ores et déjà affirmer que même après l'abandon de Manifest V2, les utilisateurs de Google Chrome pourront se protéger des publicités et des traqueurs avec l'extension de navigateur AdGuard..