La société Mozilla a publié un plan de mise en œuvre dans Firefox de la troisième version du manifeste Chrome, définissant les capacités et ressources offertes aux extensions. La troisième version du manifeste a été critiquée pour avoir perturbé le fonctionnement de nombreuses extensions de blocage de contenu indésirable et de sécurité.
Dans Firefox, ils ont l'intention de mettre en œuvre presque toutes les capacités et restrictions du nouveau manifeste, y compris l'API déclarative pour le filtrage de contenu (declarativeNetRequest), mais contrairement à Chrome, le support du mode de blocage ancien de l'API webRequest ne sera pas abandonné, du moins jusqu'à ce que la nouvelle API réponde entièrement aux besoins des développeurs d'extensions utilisant l'API webRequest. Cette approche garantira la compatibilité avec les extensions Chrome sans compromettre la compatibilité avec les extensions dépendant de l'API webRequest.
Rappelons que le principal mécontentement vis-à-vis du nouveau manifeste est lié au passage en mode lecture seule de l'API webRequest, permettant de connecter des gestionnaires personnalisés ayant un accès complet aux requêtes réseau et capables de modifier le trafic à la volée. Cette API est utilisée dans uBlock Origin et de nombreuses autres extensions de blocage de contenu indésirable et de sécurité. L'API webRequest est remplacée par une API declarativeNetRequest limitée dans ses capacités, fournissant un accès à un moteur intégré pour le filtrage, analysant automatiquement les règles de blocage, interdisant l'utilisation d'algorithmes de filtrage personnalisés et ne permettant pas de définir des règles complexes se chevauchant en fonction des conditions.
Dans Firefox, le support de la troisième version du manifeste Chrome est prévu pour des tests à la fin de 2021, et l'implémentation du nouveau manifeste est prévue pour début 2022. Parmi les particularités de la mise en œuvre du nouveau manifeste dans Firefox, on note :
- La fourniture de l'API declarativeNetRequest, tout en conservant la possibilité d'utiliser l'ancienne API webRequest.
- Le changement dans le traitement des requêtes cross-origin — conformément au nouveau manifeste, les mêmes contraintes d'autorisation s'appliqueront aux scripts de traitement de contenu que celles de 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, le script complémentaire n'y aura pas accès non plus). Une partie des changements liés aux restrictions sur les requêtes cross-origin est déjà disponible pour test dans les versions nocturnes de Firefox (développée dans le cadre du projet Fission, qui peut être activé dans about:preferences#experimental) et devrait être déployée à grande échelle au troisième trimestre 2021.
- Les pages d'arrière-plan seront remplacées par des Service Workers fonctionnant sous forme de processus d'arrière-plan. Ce changement n'est pas encore prêt pour le début des tests.
- API basée sur Promise. Firefox prend déjà en charge ce type d'API dans l'espace de noms « browser.* » et pour la troisième version du manifeste, l'intégrera dans l'espace de noms « chrome.* ».
- Un nouveau modèle granulaire de demande d'autorisation — l'extension ne pourra pas être activée pour toutes les pages en même temps (l'autorisation « all_urls » a été supprimée), mais fonctionnera uniquement dans le contexte de l'onglet actif, ce qui signifie que l'utilisateur devra confirmer l'exécution de l'extension pour chaque site. Mozilla travaille à renforcer le contrôle d'accès, mais entend permettre aux utilisateurs de décider eux-mêmes si les extensions peuvent fonctionner avec différents onglets.
- Interdiction d'exécuter du code chargé depuis l'extérieur serveurs (il s'agit de situations où une extension charge et exécute du code externe). Firefox applique déjà le blocage de code externe et les développeurs de Mozilla sont prêts à ajouter des techniques supplémentaires pour suivre les chargements de code, comme proposé dans la troisième version du manifeste. Une politique distincte de restriction d'accès au contenu (CSP, Content Security Policy) sera présentée pour les scripts de traitement de contenu, et les API existantes userScripts et contentScripts seront repensées pour prendre en charge les extensions basées sur Service Worker.
Source : opennet.ru
