Le 21 novembre, le catalogue AMO (addons.mozilla.org) commencera à accepter et à signer numériquement les extensions utilisant la troisième version du manifeste Chrome. Ces extensions pourront être testées dans les versions nocturnes de Firefox. Dans les versions stables, le support de la troisième version du manifeste sera intégré dans Firefox 109, prévu pour le 17 janvier 2023. Le support de la deuxième version du manifeste sera maintenu dans un avenir proche, mais à la fin de l'année 2023, après évaluation de la dynamique de migration des extensions vers la troisième version, la possibilité de rétrogradage du support de la deuxième version vers une catégorie obsolète sera envisagée.
Le manifeste Chrome définit les fonctionnalités et les ressources accessibles aux extensions écrites en utilisant l'API WebExtensions. À partir de la version 57, Firefox a complètement migré vers l'utilisation de l'API WebExtensions pour le développement d'extensions et a arrêté de soutenir la technologie XUL. Le passage aux WebExtensions a permis d'uniformiser le développement des extensions avec celles des plateformes Chrome, Opera, Safari et Edge, simplifiant le portage des extensions entre différents navigateurs web et permettant une utilisation complète du mode multiprocessus (les extensions WebExtensions peuvent s'exécuter dans des processus séparés, isolés des autres parties du navigateur). Pour uniformiser le développement des extensions avec les autres navigateurs, Firefox assure une compatibilité presque totale avec la deuxième version du manifeste Chrome.
Actuellement, Chrome travaille sur la migration vers la troisième version du manifeste, tandis que le support de la deuxième version sera arrêté en janvier 2024. L'objectif principal des modifications apportées dans cette nouvelle version est de simplifier la création d'extensions sécurisées et performantes, tout en compliquant la possibilité de créer des extensions non sécurisées et lentement réactives. Étant donné que la troisième version du manifeste a fait l'objet de critiques et entraînera des dysfonctionnements pour de nombreuses extensions de blocage de contenu indésirable et de sécurité, Mozilla a décidé de s'éloigner de l'objectif de compatibilité complète avec le manifeste dans Firefox et de mettre en œuvre certaines modifications d'une manière différente.
Le principal mécontentement concernant la troisième version du manifeste est lié au passage en mode lecture seule de l'API webRequest, qui permettait 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 pour bloquer le contenu indésirable et garantir la sécurité. Au lieu de l'API webRequest, la troisième version du manifeste propose une API declarativeNetRequest, limitée dans ses capacités, qui donne accès à un moteur intégré pour le filtrage, gérant lui-même les règles de blocage sans permettre l'utilisation d'algorithmes de filtrage personnalisés ni la définition de règles complexes se chevauchant en fonction des conditions.
Parmi les caractéristiques de la mise en œuvre du nouveau manifeste dans Firefox :
- Un nouvel API déclaratif de filtrage de contenu a été ajouté, mais contrairement à Chrome, le support de l'ancien mode de blocage de l'API webRequest n'a pas été supprimé.
- Le manifeste définit le remplacement des pages d'arrière-plan par une variante des Service Workers, fonctionnant comme des processus d'arrière-plan (Background Service Workers). Pour garantir la compatibilité future, Firefox mettra en œuvre le support des Service Workers, mais pour l'instant, un nouveau mécanisme appelé Event Pages est proposé, qui est plus familier pour les développeurs web, ne nécessitant pas une refonte complète des extensions et éliminant les limitations liées à l'utilisation des Service Workers. Les Event Pages permettront d'adapter les extensions existantes avec des pages d'arrière-plan aux exigences de la troisième version du manifeste tout en conservant l'accès à toutes les fonctionnalités nécessaires pour travailler avec le DOM.
- Le nouveau modèle granulaire de demande d'autorisation — l'extension ne pourra pas s'activer immédiatement pour toutes les pages (l'autorisation « all_urls » a été supprimée) et fonctionnera uniquement dans le contexte de l'onglet actif, c'est-à-dire que l'utilisateur devra confirmer le fonctionnement de l'extension pour chaque site. Dans Firefox, toutes les demandes d'accès aux données du site seront considérées comme facultatives, et la décision finale concernant l'octroi d'accès sera prise par l'utilisateur, qui pourra décider de manière sélective à quelle extension accorder l'accès à ses données sur tel ou tel site.
Pour gérer les autorisations, une nouvelle icône « Unified Extensions » a été ajoutée à l'interface, que l'on peut déjà tester dans les versions nocturnes de Firefox. Cette icône fournit des outils pour gérer directement l'accès de chaque extension à différents sites — l'utilisateur peut accorder et révoquer l'accès d'une extension à n'importe quel site. La gestion des autorisations s'applique uniquement aux extensions basées sur la troisième version du manifeste, et pour celles basées sur la deuxième version, aucune gestion granulaire de l'accès aux sites n'est effectuée.
- Modification du traitement des requêtes Cross-origin — conformément au nouveau manifeste, les scripts de traitement de contenu seront soumis aux mêmes restrictions d'autorisation que 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 le script de l'extension n'aura également pas cet accès). Ce changement est entièrement mis en œuvre dans Firefox.
- API basé sur Promise. Firefox prend en charge cette API et la transférera dans l'espace de noms « chrome.* » pour la troisième version du manifeste.
- Interdiction d'exécuter du code chargé depuis l'extérieur serveurs (en parlant des situations où une extension charge et exécute du code externe). Firefox applique un blocage du code externe, et les développeurs de Mozilla ont ajouté des techniques supplémentaires pour suivre le chargement du code, proposées dans la troisième version du manifeste. Pour les scripts de traitement de contenu, une politique distincte de sécurité des contenus (CSP, Content Security Policy) a été mise en place.
Source : opennet.ru
