Développeurs du navigateur Chrome arrêt de la prise en charge du mode de fonctionnement bloquant de l'API webRequest, qui vous permet de modifier le contenu reçu à la volée et est activement utilisé dans les modules complémentaires pour bloquer la publicité,
protection contre les logiciels malveillants, le phishing, l'espionnage de l'activité des utilisateurs, le contrôle parental et la confidentialité.
Les motivations de Google :
- Mode de blocage des API conduit à une forte consommation de ressources.
Lors de l'utilisation de cette API, le navigateur envoie d'abord au module complémentaire toutes les données contenues dans la requête réseau, le module complémentaire les analyse et renvoie une version modifiée pour un traitement ultérieur dans le navigateur ou émet des instructions de blocage. Dans ce cas, les principaux retards ne surviennent pas au stade du traitement du trafic par le module complémentaire, mais en raison des frais généraux liés à la coordination de l'exécution du module complémentaire. En particulier, de telles manipulations nécessitent le lancement d'un processus distinct pour compléter, ainsi que l'utilisation d'IPC pour interagir avec ce processus et des mécanismes de sérialisation des données ; - Le module complémentaire contrôle complètement tout le trafic à un faible niveau, ce qui ouvre de vastes possibilités d'abus et de violations de la vie privée. Selon les statistiques de Google, 42 % de tous les modules complémentaires malveillants détectés utilisaient l'API webRequest. On constate que chaque mois, des tentatives de placement en moyenne de 1800 XNUMX modules complémentaires malveillants sont bloquées dans le catalogue du Chrome Web Store. Malheureusement, l'examen ne nous permet pas d'identifier tous les modules complémentaires malveillants sans exception. Pour renforcer la protection, il a donc été décidé de limiter les modules complémentaires au niveau de l'API. L'idée principale est de fournir aux modules complémentaires un accès non pas à tout le trafic, mais uniquement aux données nécessaires à la mise en œuvre de la fonctionnalité prévue. En particulier, pour bloquer du contenu, il n'est pas nécessaire de donner au module complémentaire un accès complet à toutes les données confidentielles de l'utilisateur ;
- API déclarative de remplacement proposée prend en charge tout le travail de filtrage de contenu haute performance et ne nécessite que des modules complémentaires pour charger les règles de filtrage. Le module complémentaire ne peut pas interférer avec le trafic et les données privées de l’utilisateur restent inviolables ;
- Google a pris en compte de nombreux commentaires concernant le manque de fonctionnalité de l'API déclarativeNetRequest et a étendu la limite du nombre de règles de filtrage des 30 150 initialement proposés par extension à un maximum global de XNUMX XNUMX, et a également ajouté la possibilité de dynamiquement modifier et ajouter des règles, supprimer et remplacer les en-têtes HTTP ( Referer, Cookie, Set-Cookie) et les paramètres de demande ;
- Pour les entreprises, il est possible d'utiliser le mode de fonctionnement bloquant de l'API webRequest, puisque la politique d'utilisation des modules complémentaires est déterminée par un administrateur qui comprend les fonctionnalités de l'infrastructure et est conscient des risques. Par exemple, l'API spécifiée peut être utilisée dans les entreprises pour enregistrer les flux de trafic des employés et s'intégrer aux systèmes internes ;
- L'objectif de Google n'est pas de saper ou de supprimer les modules complémentaires de blocage des publicités, mais de permettre la création de bloqueurs de publicités plus sûrs et plus puissants ;
- La réticence à quitter le mode de fonctionnement bloquant de l'API webRequest avec le nouveau déclarativeNetRequest s'explique par la volonté de limiter l'accès des modules complémentaires aux données confidentielles. Si vous laissez l'API webRequest telle quelle, la plupart des modules complémentaires n'utiliseront pas le déclaratifNetRequest, plus sécurisé, car lorsqu'ils choisissent entre sécurité et fonctionnalité, la plupart des développeurs choisissent généralement la fonctionnalité.
:
- Réalisé par des développeurs de modules complémentaires montrent un impact global insignifiant sur les performances des modules complémentaires de blocage des publicités (lors des tests, les performances de différents modules complémentaires ont été comparées, mais sans prendre en compte la surcharge d'un processus supplémentaire qui coordonne l'exécution des gestionnaires en mode blocage de l'API webRequest) ;
- Il n’est pas pratique d’arrêter complètement la prise en charge d’une API activement utilisée dans les modules complémentaires. Au lieu de le supprimer, vous pouvez ajouter une autorisation distincte et contrôler strictement l'adéquation de son utilisation dans les modules complémentaires, ce qui éviterait aux auteurs de nombreux modules complémentaires populaires de retravailler complètement leurs produits et d'éviter de supprimer des fonctionnalités ;
- Pour réduire les frais généraux, vous ne pouvez pas supprimer l'API, mais la recréer sur la base du mécanisme Promise, similaire à l'implémentation de webRequest dans Firefox ;
- L'alternative proposée, declarativeNetRequest, ne couvre pas tous les besoins des développeurs de modules complémentaires en matière de blocage des publicités et de sécurité/confidentialité, car elle n'offre pas un contrôle total sur les requêtes réseau, ne permet pas l'utilisation d'algorithmes de filtrage personnalisés et ne permet pas l'utilisation de règles complexes qui se chevauchent selon les conditions ;
- Avec l'état actuel de l'API déclarativeNetRequest, il est impossible de recréer les fonctionnalités existantes des modules complémentaires uBlock Origin et uMatrix sans modification, et rend également inutile le développement ultérieur d'un port NoScript pour Chrome ;
- Les préoccupations concernant la confidentialité sont exagérées, puisque le mode lecture seule et non bloquant de l'API webRequest est laissé en place et permet toujours aux modules complémentaires malveillants de contrôler tout le trafic, mais ne permet pas d'interférer avec celui-ci sur le réseau. voler (modifier le contenu, placer vos publicités, exécuter des mineurs et analyser le contenu des formulaires de saisie peut être utilisé une fois le chargement de la page terminé) ;
- Développeurs de navigateurs , и , construits sur le moteur Chromium, ont l'intention de laisser la prise en charge du mode de blocage webRequest dans leurs produits.
Source: opennet.ru