Chrome 88 utilisera un nouveau manifeste incompatible avec uBlock Origin

Les développeurs Google qui sont en charge du navigateur Web "Google Chrome" ont annoncé l'inclusion dans Chrome 88 (lancement prévu le 19 janvier 2021) de la troisième édition du manifeste, ce qui a causé beaucoup de conflits parmi les développeurs d'extensions de navigateur, en raison de la violation du travail de nombreux ajouts pour bloquer le contenu et la sécurité inappropriés.

Notez que compatibilité avec les plugins utilisant la deuxième version du manifeste restera quelque temps. La fin du support pour Manifest V2 n'a pas encore été déterminée, mais la période de migration vers le nouveau manifeste durera au moins un an.

Côme recordatorio, Le manifeste Chrome définit les capacités et les ressources fournies par les plugins.

Le nouveau manifeste fait partie d'une initiative visant à améliorer la sécurité, la confidentialité et les performances des plug-ins. L'objectif principal des modifications est de faciliter la création de plug-ins performants et sûrs et de rendre plus difficile la création de plug-ins lents et dangereux.

Avec l'introduction de Manifest V3, nous n'autoriserons pas le code hébergé à distance. Ce mécanisme est utilisé comme vecteur d'attaque par les mauvais acteurs pour contourner les outils de détection de malware de Google et représente un risque important pour la confidentialité et la sécurité des utilisateurs.

Le principal mécontentement avec le nouveau manifeste est lié à la fin de la prise en charge du mode de verrouillage des opérations de l'API webRequest, qui sera limité au mode lecture seule.

Une exception ne sera faite que pour l'édition Chrome for Enterprise, qui continuera à être pris en charge par l'API webRequest. Mozilla a décidé de ne pas suivre le nouveau manifeste et gardera Firefox pleinement en utilisant l'API webRequest. Au lieu de cela, l'API webRequest pour filtrer le contenu dans le nouveau manifeste a proposé une API déclarative déclarativeNetRequest.

La nouvelle API déclarativeNetRequest donne accès à un moteur de filtrage intégré universel prêt à l'emploi qui traite indépendamment les règles de blocage, ne permet pas l'utilisation d'algorithmes de filtrage personnalisés et ne permet pas de définir des règles complexes et qui se chevauchent en fonction des conditions.

Comme raison de la transition vers l'API déclarativeNetRequest, Les préoccupations en matière de confidentialité sont notées: Avec la nouvelle API, les plugins perdront un accès illimité à tous les flux de données, qui peuvent inclure des informations utilisateur sensibles.

Google a tenté d'atténuer certains des problèmes exprimés Lors de la discussion avec les développeurs de plugins, qui seront affectés par l'API déclarativeNetRequest (par exemple uBlock Origin, dont l'auteur considère que la fonctionnalité déclarativeNetRequest est insuffisante pour que le plugin fonctionne correctement), il cessera de fonctionner.

Conformément aux souhaits des développeurs de plugins, se a ajouté la prise en charge de l'utilisation de declarativeNetRequest pour divers ensembles de règles statiques, filtrez par expressions régulières, modifiez les en-têtes HTTP, modifiez et ajoutez dynamiquement des règles, supprimez et remplacez les paramètres de requête.

Le nouveau manifeste introduit également les modifications suivantes qui affectent la compatibilité des plugins:

  • La transition vers l'exécution des services workers sous la forme de processus d'arrière-plan, ce qui obligera les développeurs à modifier le code de certains ajouts.
  • Nouveau modèle granulaire de demande d'autorisations: le plugin ne pourra pas être activé pour toutes les pages en même temps (l'autorisation "all_urls" a été supprimée), mais il ne fonctionnera que dans le contexte de l'onglet actif, c'est-à-dire l'utilisateur devra confirmer le travail du plugin pour chaque site.
  • Modifications du traitement des requêtes cross-origin: selon le nouveau manifeste, les scripts de traitement de contenu seront soumis aux mêmes restrictions d'autorisation que pour la page principale dans laquelle ces scripts sont intégrés (par exemple, si la page n'a pas accès à l'API de localisation , alors les plugins de script n'auront pas non plus cet accès)
  • Empêche l'exécution de code téléchargé à partir de serveurs externes (lorsque le plug-in charge et exécute du code externe).

Enfin si vous voulez en savoir plus de la note, vous pouvez vous référer au message d'origine dans le lien suivant.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.