Mozilla a annoncé avoir commencé à tester l'implémentation par Firefox de la troisième version du manifeste Chrome, qui définit les capacités et les ressources disponibles pour les modules complémentaires écrits à l'aide de l'API WebExtensions. Pour tester la troisième version du manifeste dans Firefox 101 bêta, vous devez définir le paramètre « extensions.manifestV3.enabled » sur true et le paramètre « xpinstall.signatures.required » sur false dans la page about:config. Pour installer des modules complémentaires, vous pouvez utiliser l'interface about:debugging. La troisième version du manifeste devrait être activée par défaut d'ici la fin de l'année.
À 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 2023 du manifeste, et la prise en charge de la version XNUMX sera interrompue en janvier XNUMX. É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 s'éloigner de la pratique consistant à garantir une compatibilité totale 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.
Dans l'implémentation de la troisième version du manifeste proposée dans Firefox, une nouvelle API déclarative pour le filtrage de contenu a été ajoutée, mais contrairement à Chrome, ils n'ont pas cessé de prendre en charge l'ancien mode de fonctionnement de blocage de l'API webRequest. Les autres fonctionnalités de la nouvelle implémentation du manifeste dans Firefox incluent :
- 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é, Firefox implémentera cette exigence, mais proposera en plus 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 à l'utilisation des Service Workers. 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. Dans l'implémentation du manifeste disponible pour les tests dans Firefox, seules les pages d'événements sont actuellement prises en charge, et la prise en charge d'une solution basée sur Service Workers devrait être ajoutée ultérieurement. Apple a soutenu la proposition et implémenté les pages d'événements dans Safari Technology Preview 136.
- 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.
- 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 déjà en charge cette API et la déplacera vers l'espace de noms « chrome.* » pour la troisième version du manifeste.
- 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 déjà 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