Les développeurs de Mozilla ont mis à jour les informations concernant leur plan de support des versions deux et trois du manifeste Chrome dans Firefox. Google prévoit d'arrêter le support des extensions utilisant la deuxième version du manifeste dans les versions test de Chrome 127 (Dev, Canary et Beta) à partir de juin de cette année. Dans la branche stable, le support de la deuxième version du manifeste cessera au plus tôt en juillet.
Pour sa part, Mozilla n'interrompra pas le support de la deuxième version du manifeste dans un avenir proche et continuera de permettre l'exécution d'extensions utilisant des fonctionnalités non disponibles dans la troisième version du manifeste. La décision de ne pas garantir la compatibilité complète avec la troisième version du manifeste Chrome dans Firefox reste en vigueur. L'API webRequest sera conservée dans Firefox, alors qu'elle sera en mode lecture seule dans Chrome.
Dans Firefox, le mécanisme des Event Pages continuera de supporter l'exécution de scripts d'arrière-plan basés sur le DOM, alors que la troisième version du manifeste impose l'utilisation de Service Workers. Les scripts d'arrière-plan basés sur les Service Workers ne sont pas encore pris en charge dans Firefox, mais les développeurs auront la possibilité de définir dans l'extension des gestionnaires basés à la fois sur les Event Pages et sur les scripts Service Workers, permettant ainsi de créer des extensions conformes à la troisième version du manifeste et fonctionnant sur Chrome et Firefox.
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.
Dans le cadre de son initiative visant à simplifier la création d'extensions sécurisées et performantes, tout en rendant plus difficile la création d'extensions peu sûres et lentes, Google a développé la troisième version du manifeste. Le principal mécontentement à l'égard de cette version provient de la transformation de l'API webRequest en mode lecture seule, ce qui empêchait l'utilisation de gestionnaires personnalisés ayant un accès complet aux requêtes réseau et pouvant modifier le trafic à la volée. Au lieu de l'API webRequest, la troisième version du manifeste introduit une API declarativeNetRequest limitée dans ses capacités, offrant un accès à un moteur intégré de filtrage qui traite les règles de blocage, sans autoriser l'utilisation d'algorithmes de filtrage personnalisés.
Parmi les caractéristiques de la mise en œuvre de la troisième version du 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é.
- Un mécanisme de Pages d'Événements a été mis en place, qui est plus familier pour les développeurs web, ne nécessite pas de refonte complète des extensions et élimine les restrictions liées à l'utilisation des Service Workers. Les Pages d'Événements 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, un bouton « Unified Extensions » a été ajouté à l'interface pour un contrôle direct sur les sites auxquels chaque extension a accès — l'utilisateur peut accorder et révoquer l'accès de l'extension à n'importe quel site. La gestion des autorisations ne s'applique qu'aux extensions basées sur la troisième version du manifeste, pour les extensions de la deuxième version du manifeste, la gestion granulaire de l'accès aux sites n'est pas 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ée sur Promise. Firefox prend en charge cette API pour la troisième version du manifeste.
- Interdiction d'exécuter du code chargé depuis l'extérieur serveurs (concernant les situations où une extension charge et exécute du code externe). Firefox applique le blocage du code externe et les développeurs de Mozilla ont ajouté des techniques supplémentaires pour suivre les chargements de code. Pour les scripts de traitement de contenu, une politique distincte de restriction d'accès au contenu (CSP, Content Security Policy) a été introduite.
Source : opennet.ru
