La société Mozilla a annoncé le début des tests de la mise en œuvre de la troisième version du manifeste Chrome dans Firefox, définissant les capacités et ressources disponibles pour les extensions écrites avec l'API WebExtensions. Pour tester la troisième version du manifeste dans la version bêta de Firefox 101, il faut définir le paramètre «extensions.manifestV3.enabled» sur true dans la page about:config, et le paramètre «xpinstall.signatures.required» sur false. On peut utiliser l'interface about:debugging pour installer des extensions. L'activation par défaut de la troisième version du manifeste est prévue pour la fin de l'année.
Depuis la version 57, Firefox utilise entièrement l'API WebExtensions pour le développement d'extensions et a cessé de soutenir la technologie XUL. Le passage à WebExtensions a permis d'uniformiser le développement d'extensions avec les plateformes Chrome, Opera, Safari et Edge, a simplifié le portage des extensions entre différents navigateurs web et a permis 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 d'extensions avec les autres navigateurs, Firefox assure une compatibilité presque totale avec la deuxième version du manifeste Chrome.
Actuellement, le travail est en cours sur Chrome pour passer à la troisième version du manifeste, et la prise en charge de la deuxième version sera interrompue en janvier 2023. Comme la troisième version du manifeste a été critiquée et entraînera des dysfonctionnements pour de nombreuses extensions de blocage de contenu indésirable et de sécurité, la société Mozilla a décidé de s'éloigner de la pratique de garantir la compatibilité totale avec le manifeste dans Firefox et de mettre en œuvre certaines modifications différemment.
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.
Dans l'implémentation de la troisième version du manifeste proposée dans Firefox, un nouvel API déclaratif de filtrage de contenu a été ajouté, mais contrairement à Chrome, le support de l'ancien mode de travail bloquant de l'API webRequest n'a pas été abandonné. Parmi les autres caractéristiques de l'implémentation du nouveau manifeste dans Firefox :
- Le manifeste définit le remplacement des pages en arrière-plan par une variante de Service Workers, fonctionnant comme des processus en arrière-plan (Background Service Workers). Pour assurer la compatibilité, Firefox mettra en œuvre cette exigence, mais un nouveau mécanisme Event Pages a également été proposé, 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. Event Pages permettra d'adapter les extensions existantes avec des pages en 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. Dans l'implémentation actuellement disponible pour test dans Firefox, seuls les Event Pages sont pris en charge, et la prise en charge d'une solution basée sur les Service Workers est promise pour plus tard. Cette proposition a été soutenue par Apple, qui a mis en œuvre les Event Pages dans la version 136 de Safari Technology Preview.
- 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.
- 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 déjà en charge cette API et pour la troisième version du manifeste, elle sera transférée dans l'espace de noms « chrome.* ».
- Interdiction d'exécuter du code chargé depuis l'extérieur serveurs (il s'agit de situations où l'extension charge et exécute du code externe). Dans Firefox, le blocage du code externe est déjà appliqué et les développeurs de Mozilla ont ajouté des techniques supplémentaires de suivi des 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) a été présentée.
Source : opennet.ru
