Google a dévoilé un calendrier pour la dépréciation de la version XNUMX du manifeste Chrome au profit de la version XNUMX, qui a été critiquée pour avoir brisé bon nombre de ses modules complémentaires de blocage de contenu et de sécurité. En particulier, le populaire bloqueur de publicités uBlock Origin est attaché à la deuxième version du manifeste, qui ne peut pas être transféré vers la troisième version du manifeste en raison de l'arrêt de la prise en charge du mode de fonctionnement bloquant de l'API webRequest.
À partir du 17 janvier 2022, le Chrome Web Store n'acceptera plus les modules complémentaires utilisant la deuxième version du manifeste, mais les développeurs de modules complémentaires précédemment ajoutés continueront de pouvoir publier des mises à jour. En janvier 2023, Chrome cessera de prendre en charge la deuxième version du manifeste et tous les modules complémentaires qui y sont liés cesseront de fonctionner. Dans le même temps, la publication de mises à jour pour ces modules complémentaires dans le Chrome Web Store sera interdite.
Rappelons que dans la troisième version du manifeste, qui définit les capacités et ressources fournies aux modules complémentaires, dans le cadre d'une initiative visant à renforcer la sécurité et la confidentialité, à la place de l'API webRequest, l'API déclarativeNetRequest, limitée dans ses capacités, est proposé. Alors que l'API webRequest vous permet de connecter vos propres gestionnaires qui ont un accès complet aux requêtes réseau et sont capables de modifier le trafic à la volée, l'API déclarativeNetRequest ne donne accès qu'à un moteur de filtrage prêt à l'emploi intégré au navigateur, qui traite indépendamment le blocage. règles et ne permet pas l'utilisation de ses propres algorithmes de filtrage et ne vous permet pas de définir des règles complexes qui se chevauchent en fonction des conditions.
Selon Google, il continue de travailler à l'implémentation dans declarativeNetRequest des capacités requises dans les modules complémentaires utilisant webRequest et a l'intention de donner à la nouvelle API une forme qui réponde pleinement aux besoins des développeurs de modules complémentaires existants. Par exemple, Google a déjà pris en compte les souhaits de la communauté et ajouté la prise en charge de l'API déclarativeNetRequest pour l'utilisation de plusieurs ensembles de règles statiques, le filtrage à l'aide d'expressions régulières, la modification des en-têtes HTTP, la modification et l'ajout dynamiques de règles, la suppression et le remplacement des paramètres de requête, le filtrage. avec liaison par onglets et création de sessions d'ensemble de règles spécifiques spécifiques. Dans les mois à venir, il est également prévu de mettre en œuvre la prise en charge de scripts de traitement de contenu personnalisables de manière dynamique et la possibilité de stocker des données dans la RAM.
Source: opennet.ru