Mozilla hat Pläne zur Unterstützung der dritten Version des Chrome-Manifests in Firefox zusammengefasst

Mozilla hat einen Plan zur Implementierung der dritten Version des Chrome-Manifests in Firefox veröffentlicht, das die Funktionen und Ressourcen definiert, die Add-Ons zur Verfügung gestellt werden. Die dritte Version des Manifests ist in die Kritik geraten, weil sie viele Inhaltsblocker und Sicherheits-Add-ons beschädigt.

Firefox beabsichtigt, fast alle Funktionen und Einschränkungen des neuen Manifests zu implementieren, einschließlich der deklarativen API zur Inhaltsfilterung (declarativeNetRequest). Im Gegensatz zu Chrome wird Firefox jedoch die Unterstützung für den alten Sperrmodus der webRequest-API nicht einstellen, zumindest nicht, bis die neue API die Anforderungen von Add-On-Entwicklern, die die webRequest-API verwenden, vollständig erfüllt. Dieser Ansatz stellt die Kompatibilität mit Chrome-Add-Ons sicher, ohne die Kompatibilität mit Add-Ons zu beeinträchtigen, die auf der WebRequest-API basieren.

Erinnern wir uns daran, dass die größte Unzufriedenheit mit dem neuen Manifest mit der Umstellung der webRequest-API auf den schreibgeschützten Modus zusammenhängt, der die Verbindung benutzerdefinierter Handler mit vollem Zugriff auf Netzwerkanforderungen und der Möglichkeit zur Änderung des Datenverkehrs im laufenden Betrieb ermöglichte. Diese API wird von uBlock Origin und vielen anderen Add-Ons verwendet, um unerwünschte Inhalte zu blockieren und die Sicherheit zu gewährleisten. Anstelle der webRequest-API wird die declarativeNetRequest-API vorgeschlagen, die in ihren Funktionen eingeschränkt ist und Zugriff auf eine integrierte Filter-Engine bietet, die Sperrregeln selbstständig verarbeitet, die Verwendung benutzerdefinierter Filteralgorithmen nicht zulässt und die Festlegung komplexer Regeln, die sich je nach Bedingungen überschneiden, nicht zulässt.

Firefox plant, die Unterstützung für Version 2021 des Chrome-Manifests Ende 2022 zu Testzwecken freizugeben. Das neue Manifest soll Anfang XNUMX eingeführt werden. Die folgenden Funktionen zeichnen sich durch die Implementierung des neuen Manifests in Firefox aus:

• Stellt die declarativeNetRequest-API bereit, ermöglicht aber weiterhin die Verwendung der alten webRequest-API.
• Änderungen an der Cross-Origin-Anforderungsverarbeitung – Gemäß dem neuen Manifest unterliegen Inhaltsverarbeitungsskripte denselben Berechtigungsbeschränkungen wie die Hauptseite, in die sie eingebettet sind (wenn die Seite beispielsweise keinen Zugriff auf die Standort-API hat, hat das Add-On-Skript diesen Zugriff auch nicht). Einige der Änderungsprotokolle zu Cross-Origin-Anfragen stehen bereits zum Testen in den Nightly Builds von Firefox zur Verfügung (entwickelt im Rahmen des Fission-Projekts, die in about:preferences#experimental aufgenommen werden können) und sollen im dritten Quartal 2021 allgemein bereitgestellt werden.
• Hintergrundseiten werden durch Service Worker ersetzt, die als Hintergrundprozesse ausgeführt werden. Die Änderung ist noch nicht testbereit.
• Promise-basierte API. Firefox unterstützt diesen API-Typ bereits im Namespace „browser.*“ und wird ihn für die dritte Version des Manifests in den Namespace „chrome.*“ verschieben.
• Neues granulares 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 den Vorgang des Add-ons für jede Site bestätigen. Mozilla arbeitet daran, die Zugriffskontrollen zu verschärfen, möchte den Benutzern jedoch die Möglichkeit geben, selbst zu entscheiden, ob sie die Arbeit von Add-Ons über mehrere Tabs hinweg zulassen möchten.
• Verhindern der Ausführung von Code, der von externen Quellen heruntergeladen wurde Server (Dies bezieht sich auf Situationen, in denen ein Add-on externen Code lädt und ausführt.) Firefox implementiert bereits eine Blockierung externen Codes, und die Mozilla-Entwickler sind bereit, die in der dritten Version des Manifests vorgeschlagenen zusätzlichen Techniken zur Nachverfolgung von Code-Downloads zu implementieren. Für Skripte zur Inhaltsverarbeitung wird eine separate Content Security Policy (CSP) eingeführt, und die bestehenden APIs userScripts und contentScripts werden überarbeitet, um Service-Worker-basierte Erweiterungen zu unterstützen.

Source: opennet.ru