L'an dernier, nous avons pris part activement à des discussions avec les fournisseurs de plusieurs extensions de blocage de contenu afin de déterminer comment améliorer la plate-forme des extensions MV3. Grâce à ces discussions, dont beaucoup ont eu lieu au sein du WECG (WebExtensions Community Group) en collaboration avec d'autres navigateurs, nous avons pu apporter des améliorations significatives.
Plus d'ensembles de règles statiques
Les ensembles de règles de filtrage sont généralement regroupés en listes. Par exemple, une liste plus générique peut contenir des règles applicables à l'ensemble des utilisateurs, tandis qu'une liste plus spécifique peut masquer le contenu spécifique à une zone géographique que seuls certains utilisateurs souhaitent bloquer. Récemment encore, nous permettions à chaque extension de proposer aux utilisateurs un choix de 50 listes (ou "ensembles de règles statiques"), et 10 listes pouvaient être activées simultanément. Lors de discussions avec la communauté, les développeurs d'extensions ont fourni des preuves convaincantes indiquant que cette valeur était trop faible pour certains cas d'utilisation. Après avoir étudié les performances de l'API dans Chrome en tenant compte de ces discussions, nous autorisons désormais l'activation simultanée de jusqu'à 50 API. (et notamment bien plus que la limite de 20 règles imposée par le WECG). Nous autorisons également 100 ensembles de règles au total. Cette fonctionnalité est disponible dans Chrome 120, et l'augmentation des limites est prise en charge par Firefox et Safari, qui ont tous deux donné leur avis en amont sur cette proposition.
Plus de règles dynamiques
La plupart des règles sont "statiques" et sont envoyées à une extension à chaque mise à jour. Toutefois, pour des mises à jour plus fréquentes et des règles définies par l'utilisateur, les extensions peuvent également ajouter des règles de façon dynamique, sans que les développeurs n'aient à importer une nouvelle version de l'extension sur le Chrome Web Store.
Lorsqu'une extension peut modifier dynamiquement les requêtes d'une manière qui n'a pas été vérifiée lors de l'examen du Chrome Web Store, les utilisateurs sont exposés à des risques d'hameçonnage ou de vol de données. Par exemple, une règle de redirection peut être utilisée de manière abusive pour injecter des liens d'affiliation sans le consentement de l'utilisateur.
Par conséquent, nous n'avons autorisé les extensions à ajouter que 5 000 règles au maximum. Cela nous a permis d'utiliser cette fonctionnalité avec parcimonie et de détecter plus facilement les abus.
Toutefois, les développeurs des extensions comme AdGuard et Adblock Plus ont effectué leur propre analyse et partagé des données qu'une limite plus élevée permettrait d'appliquer des règles plus à jour et aux utilisateurs disposant d'un plus grand nombre de listes personnalisées de migrer vers Manifest V3. En effet, AdGuard a indiqué que plus de 2 600 modifications étaient apportées aux listes populaires chaque semaine. Sur les 5 % d'utilisateurs qui utilisent des listes de filtres personnalisés, un sur quatre dispose au total de plus de 5 000 règles dynamiques (source). AdGuard a identifié cela comme un défi important pour la migration de son extension vers Manifest V3, et nous avons reçu des commentaires similaires de la part d'autres bloqueurs de contenu.
Nous avons déterminé que certaines règles de filtrage, comme celles qui comportent une action block ou allow, étaient beaucoup plus sûres et étaient moins susceptibles d'être utilisées de manière abusive. Ils constituent également la grande majorité des règles de filtrage des bloqueurs d'annonces. Sur cette base, j'ai rédigé et partagé une proposition au sein du groupe "Communauté des extensions Web" afin de définir un ensemble de règles que nous considérons comme présentant moins de risques et qui autorisent jusqu'à 30 000 règles. Nous conservons toujours une limite supérieure pour éviter les régressions de performances.
Cette proposition était prise en charge par le groupe "Web Extensions Community Group". Nous l'avons donc implémentée. À partir de Chrome 121, la limite plus élevée de 30 000 règles s'applique aux règles sûres de DNR, que nous définissons comme des règles avec une action block, allow, allowAllRequests ou upgradeScheme.
En fonction des données partagées par AdGuard, entre 98 et 99 % de leurs règles devraient bénéficier de cette limite plus élevée. Toutes les règles restantes sont toujours acceptées et peuvent être ajoutées dans la limite existante.
Cette valeur est disponible dans Chrome sous la forme d'une constante MAX_NUMBER_OF_DYNAMIC_RULES. La limite reste de 5 000 pour toutes les autres règles de requête de réseau dynamique.
Réduction de la taille de l'ensemble de règles
Dans Chrome 118, nous avons remplacé la valeur par défaut du champ isUrlFilterCaseSensitive par false en fonction des commentaires de la communauté. Ce champ permet de déterminer si une règle de filtrage par URL est sensible à la casse. Nous avons découvert que la plupart des développeurs utilisaient une valeur par défaut différente dans leur extension. La valeur a donc dû être définie à maintes reprises. Cette modification permet aux développeurs de réduire considérablement la taille de leurs ensembles de règles.
Étapes suivantes
Nous nous engageons à continuer d'investir dans l'API declarativeNetRequest afin de prendre en charge autant de cas d'utilisation que possible. Nous sommes impatients de poursuivre notre collaboration avec la communauté. Nous aimerions notamment remercier les membres du WECG pour leur engagement, y compris AdGuard pour avoir partagé une quantité importante des données à l'origine de ce travail, ainsi que tous les fournisseurs de navigateurs qui ont tous joué un rôle majeur dans la conception de cette API.
Nous continuerons de vérifier les limites que nous avons mises en place afin d'apporter des ajustements si nécessaire. Pour ce faire, nous prévoyons de partager prochainement certaines des données collectées dans le cadre de ce travail. Par ailleurs, nous travaillons à l'ajout de fonctionnalités supplémentaires, comme la possibilité d'établir une correspondance avec les en-têtes de réponse, ce que nous avons fréquemment demandé dans les extensions de lecteur de PDF. Dans tous les cas, nous continuerons à faire connaître notre travail et nous utiliserons régulièrement le groupe de la communauté des extensions Web pour discuter de nos idées et définir les points que nous aimerions aborder.