Mozilla hat angekündigt, mit dem Testen der Firefox-Implementierung der dritten Version des Chrome-Manifests begonnen zu haben, das die Funktionen und Ressourcen definiert, die für Add-ons verfügbar sind, die mit der WebExtensions-API geschrieben wurden. Um die dritte Version des Manifests in Firefox 101 Beta zu testen, sollten Sie auf der Seite „about:config“ den Parameter „extensions.manifestV3.enabled“ auf „true“ und den Parameter „xpinstall.signatures.required“ auf „false“ setzen. Um Add-ons zu installieren, können Sie die Schnittstelle about:debugging verwenden. Die dritte Version des Manifests soll bis Ende des Jahres standardmäßig aktiviert werden.
Ab Version 57 hat Firefox vollständig auf die Verwendung der WebExtensions-API für die Entwicklung von Add-ons umgestellt und die Unterstützung der XUL-Technologie eingestellt. Der Übergang zu WebExtensions ermöglichte die Vereinheitlichung der Add-On-Entwicklung mit den Plattformen Chrome, Opera, Safari und Edge, vereinfachte die Portierung von Add-Ons zwischen verschiedenen Webbrowsern und ermöglichte die vollständige Nutzung des Multiprozessmodus von Betrieb (WebExtensions-Add-ons können in separaten Prozessen ausgeführt werden, isoliert vom Rest des Browsers). Um die Entwicklung von Add-ons mit anderen Browsern zu vereinheitlichen, bietet Firefox nahezu vollständige Kompatibilität mit der zweiten Version des Chrome-Manifests.
Chrome arbeitet derzeit an der Umstellung auf Version 2023 des Manifests und die Unterstützung für Version XNUMX wird im Januar XNUMX eingestellt. Da die dritte Version des Manifests in die Kritik geraten ist und viele Inhaltsblockierungs- und Sicherheits-Add-ons außer Kraft setzen wird, hat Mozilla beschlossen, von der Praxis, die volle Kompatibilität mit dem Manifest in Firefox sicherzustellen, Abstand zu nehmen und einige Änderungen anders umzusetzen.
Die größte Unzufriedenheit mit der dritten Version des Manifests hängt mit der Übersetzung der webRequest-API in den schreibgeschützten Modus zusammen, die es ermöglicht, eigene Handler anzuschließen, die vollen Zugriff auf Netzwerkanfragen haben und den Datenverkehr im laufenden Betrieb ändern können. Diese API wird in uBlock Origin und vielen anderen Add-ons verwendet, um unangemessene Inhalte zu blockieren und Sicherheit zu bieten. Anstelle der webRequest-API bietet die dritte Version des Manifests eine deklarative NetRequest-API mit eingeschränkten Funktionen, die Zugriff auf eine integrierte Filter-Engine bietet, die Blockierungsregeln unabhängig verarbeitet, die Verwendung eigener Filteralgorithmen nicht zulässt und dies nicht tut ermöglichen die Festlegung komplexer Regeln, die sich je nach Bedingungen überschneiden.
Bei der Implementierung der dritten Version des in Firefox vorgeschlagenen Manifests wurde eine neue deklarative API für die Inhaltsfilterung hinzugefügt, aber im Gegensatz zu Chrome wurde die Unterstützung des alten blockierenden Betriebsmodus der webRequest-API nicht eingestellt. Zu den weiteren Funktionen der neuen Manifest-Implementierung in Firefox gehören:
- Das Manifest definiert den Ersatz von Hintergrundseiten durch die Option Service Workers, die als Hintergrundprozesse (Background Service Workers) ausgeführt werden. Um die Kompatibilität zu gewährleisten, wird Firefox diese Anforderung umsetzen, aber zusätzlich einen neuen Event Pages-Mechanismus anbieten, der Webentwicklern besser vertraut ist, keine vollständige Überarbeitung von Add-ons erfordert und die mit der Verwendung von Service Workern verbundenen Einschränkungen beseitigt. Mit Event Pages können vorhandene Hintergrundseitenergänzungen den Anforderungen der dritten Version des Manifests entsprechen und gleichzeitig der Zugriff auf alle für die Arbeit mit dem DOM erforderlichen Funktionen aufrechterhalten werden. In der Manifest-Implementierung, die zum Testen in Firefox verfügbar ist, werden derzeit nur Ereignisseiten unterstützt, und es wird versprochen, dass die Unterstützung für eine auf Service Workern basierende Lösung später hinzugefügt wird. Apple unterstützte den Vorschlag und implementierte Event Pages in Safari Technology Preview 136.
- Das neue granulare Berechtigungsanforderungsmodell – das Add-on kann nicht für alle Seiten gleichzeitig aktiviert werden (die Berechtigung „all_urls“ wurde entfernt), sondern funktioniert nur im Kontext der aktiven Registerkarte, d. h. Der Benutzer muss bestätigen, dass das Add-on für jede Site funktioniert. In Firefox werden alle Anfragen zum Zugriff auf Website-Daten als optional betrachtet und die endgültige Entscheidung über die Gewährung des Zugriffs liegt beim Benutzer, der selektiv entscheiden kann, welchem Add-on er Zugriff auf seine Daten auf einer bestimmten Website gewährt.
- Änderung bei der Bearbeitung von Cross-Origin-Anfragen – gemäß dem neuen Manifest unterliegen Inhaltsverarbeitungsskripts denselben Berechtigungsbeschränkungen wie für die Hauptseite, in die diese Skripts eingebettet sind (z. B. wenn die Seite keinen Zugriff auf die hat). Standort-API, dann erhalten auch die Skript-Add-ons diesen Zugriff nicht). Diese Änderung ist in Firefox vollständig implementiert.
- Versprechenbasierte API. Firefox unterstützt diese API bereits und wird sie für die dritte Version des Manifests in den Namespace „chrome.*“ verschieben.
- Verbot der Ausführung von Code, der von externen Servern heruntergeladen wurde (wir sprechen von Situationen, in denen das Add-on externen Code lädt und ausführt). Firefox verwendet bereits die Blockierung von externem Code, und Mozilla-Entwickler haben zusätzliche Techniken zur Verfolgung von Code-Downloads hinzugefügt, die in der dritten Version des Manifests angeboten werden. Für Inhaltsverarbeitungsskripte wird eine separate Inhaltszugriffsbeschränkungsrichtlinie (CSP, Content Security Policy) bereitgestellt.
Source: opennet.ru