Le 21 novembre, le répertoire AMO (addons.mozilla.org) commencera à accepter et à signer numériquement les modules complémentaires à l'aide de la version 109 du manifeste Chrome. Ces modules complémentaires peuvent être testés dans les versions nocturnes de Firefox. Dans les versions stables, la prise en charge de la version 17 du manifeste sera activée dans Firefox 2023, prévue pour le 2023 janvier XNUMX. Le support de la deuxième version du manifeste sera maintenu dans un avenir prévisible, mais fin XNUMX, après avoir évalué la dynamique de transfert des ajouts à la troisième version du manifeste, la possibilité de déprécier le support de la deuxième version du manifeste seront considérées.
Le manifeste Chrome définit les capacités et les ressources disponibles pour les extensions écrites à l'aide de l'API WebExtensions. À partir de la version 57, Firefox a complètement basculé vers l'utilisation de l'API WebExtensions pour développer des modules complémentaires et a cessé de prendre en charge la technologie XUL. Le passage aux WebExtensions a permis d'unifier le développement des modules complémentaires avec les plateformes Chrome, Opera, Safari et Edge, a simplifié le portage des modules complémentaires entre différents navigateurs web et a permis d'utiliser pleinement le mode multi-processus de opération (les modules complémentaires WebExtensions peuvent être exécutés dans des processus distincts, isolés du reste du navigateur). Pour unifier le développement de modules complémentaires avec d'autres navigateurs, Firefox offre une compatibilité presque totale avec la deuxième version du manifeste Chrome.
Chrome travaille actuellement à passer à la version 2024 du manifeste, et la prise en charge de la version XNUMX sera interrompue en janvier XNUMX. L'objectif principal des modifications apportées à la nouvelle version est de faciliter la création de modules complémentaires sécurisés et performants, et de rendre plus difficile la création de modules complémentaires dangereux et lents. Étant donné que la troisième version du manifeste a été critiquée et qu'elle brisera de nombreux modules complémentaires de blocage de contenu et de sécurité, Mozilla a décidé de ne plus être entièrement compatible avec le manifeste dans Firefox et d'implémenter certaines modifications différemment.
Le principal mécontentement de la troisième version du manifeste est lié à la traduction en mode lecture seule de l'API webRequest, qui permettait de connecter ses propres gestionnaires ayant un accès complet aux requêtes réseau et pouvant modifier le trafic à la volée. Cette API est utilisée dans uBlock Origin et de nombreux autres modules complémentaires pour bloquer le contenu inapproprié et assurer la sécurité. Au lieu de l'API webRequest, la troisième version du manifeste propose une API déclarativeNetRequest à capacité limitée, qui donne accès à un moteur de filtrage intégré qui traite indépendamment les règles de blocage, ne permet pas l'utilisation de ses propres algorithmes de filtrage et ne permettre de définir des règles complexes qui se chevauchent en fonction des conditions.
Parmi les fonctionnalités d'implémentation du nouveau manifeste dans Firefox :
- Une nouvelle API de filtrage de contenu déclaratif a été ajoutée, mais contrairement à Chrome, la prise en charge de l'ancien mode de blocage de l'API webRequest n'a pas été interrompue.
- Le manifeste définit le remplacement des pages d'arrière-plan par l'option Service Workers, qui s'exécute en tant que processus en arrière-plan (Background Service Workers). Pour assurer la compatibilité à l'avenir, Firefox prendra en charge les Service Workers, mais ils sont actuellement remplacés par un nouveau mécanisme de pages d'événements, plus familier aux développeurs Web, ne nécessite pas une refonte complète des modules complémentaires et élimine les limitations associées à le recours à des travailleurs de service. Les pages d'événements permettront aux ajouts de pages d'arrière-plan existantes de se conformer 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 de demande d'autorisation granulaire - le module complémentaire ne pourra pas être activé pour toutes les pages à la fois (l'autorisation « all_urls » a été supprimée), mais ne fonctionnera que dans le contexte de l'onglet actif, c'est-à-dire l'utilisateur devra confirmer que le module complémentaire fonctionne 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 d'accorder l'accès sera prise par l'utilisateur, qui pourra décider de manière sélective quel module complémentaire accordera l'accès à ses données sur un site particulier.
Pour gérer les autorisations, un nouveau bouton « Extensions unifiées » a été ajouté à l'interface, qui peut déjà être testé dans les versions nocturnes de Firefox. Le bouton permet de contrôler directement les sites auxquels chaque module complémentaire a accès : l'utilisateur peut accorder et révoquer l'accès d'un module complémentaire à n'importe quel site. La gestion des autorisations s'applique uniquement aux modules complémentaires basés sur la troisième version du manifeste ; pour les modules complémentaires basés sur la deuxième version du manifeste, le contrôle d'accès granulaire aux sites n'est pas effectué.
- Changement dans la gestion 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 pour la page principale dans laquelle ces scripts sont intégrés (par exemple, si la page n'a pas accès au API de localisation, les modules complémentaires de script ne recevront pas non plus cet accès). Ce changement est entièrement implémenté dans Firefox.
- API basée sur des promesses. Firefox prend en charge cette API et pour la troisième version du manifeste, il la déplacera vers l'espace de noms « chrome.* ».
- Interdire l'exécution de code téléchargé à partir de serveurs externes (nous parlons de situations dans lesquelles le module complémentaire charge et exécute du code externe). Firefox utilise le blocage de code externe et les développeurs de Mozilla ont ajouté des techniques supplémentaires de suivi des téléchargements de code proposées dans la troisième version du manifeste. Pour les scripts de traitement de contenu, une politique distincte de restriction d'accès au contenu (CSP, Content Security Policy) est fournie.
Source: opennet.ru