Mozilla hat einen Plan zur Umsetzung der dritten Version des Chrome-Manifests in Firefox veröffentlicht, welches die Möglichkeiten und Ressourcen für Add-ons definiert. Die dritte Version des Manifests wurde kritisiert, da sie die Funktionalität vieler Add-ons zur Blockierung unerwünschter Inhalte sowie zur Gewährleistung von Sicherheit beeinträchtigt.
In Firefox beabsichtigt man, nahezu alle Funktionen und Einschränkungen des neuen Manifests zu implementieren, einschließlich der deklarativen API zur Inhaltsfilterung (declarativeNetRequest). Im Gegensatz zu Chrome wird jedoch in Firefox die Unterstützung des alten blockierenden Modus der API webRequest nicht eingestellt – zumindest so lange, bis die neue API vollständig den Bedürfnissen der Entwickler von Add-ons entspricht, die die API webRequest nutzen. Dieser Ansatz garantiert die Kompatibilität mit Chrome-Add-ons, ohne dabei die Kompatibilität mit Add-ons zu beeinträchtigen, die auf die API webRequest angewiesen sind.
Wir erinnern daran, dass die Hauptbeschwerde über das neue Manifest mit der Umstellung des API webRequest auf den Nur-Lese-Modus zusammenhängt. Dieses API erlaubte die Anbindung eigener Handler, die vollständigen Zugriff auf Netzwerkrequests hatten und den Verkehr in Echtzeit modifizieren konnten. Das besagte API wird in uBlock Origin und vielen anderen Erweiterungen verwendet, um unerwünschte Inhalte zu blockieren und Sicherheit zu gewährleisten. Statt des API webRequest wurde ein eingeschränkteres API namens declarativeNetRequest vorgeschlagen, das Zugang zu einer integrierten Engine für die Filterung bietet, die die Blockierungsregeln eigenständig verarbeitet. Es erlaubt nicht, eigene Filteralgorithmen zu verwenden und verbietet die Festlegung komplexer, voneinander abhängiger Regeln.
Für Firefox wird die Unterstützung der dritten Version des Chrome-Manifests für Tests Ende 2021 bereitgestellt, während die Einführung des neuen Manifests für Anfang 2022 geplant ist. Zu den Besonderheiten der Implementierung des neuen Manifests in Firefox gehört:
- Die Bereitstellung des API declarativeNetRequest mit der Möglichkeit, weiterhin das alte API webRequest zu verwenden.
- Änderung der Verarbeitung von Cross-Origin-Anfragen — gemäß dem neuen Manifest unterliegen Skripte zur Verarbeitung von Inhalten denselben Berechtigungsbeschränkungen wie die Hauptseite, in die diese Skripte eingebettet sind (zum Beispiel, wenn die Seite keinen Zugriff auf die API zur Standortbestimmung hat, erhält auch das Zusatzskript keinen Zugriff). Einige der mit den Einschränkungen von Cross-Origin-Anfragen verbundenen Änderungen sind bereits in den Nachts builds von Firefox für Tests verfügbar (entwickelt im Rahmen des Fission-Projekts, das unter about:preferences#experimental aktiviert werden kann) und ist für eine umfassende Einführung im dritten Quartal 2021 geplant.
- Hintergrundseiten werden durch Service Worker ersetzt, die als Hintergrundprozesse arbeiten. Diese Änderung ist derzeit noch nicht bereit für Tests.
- API basierend auf Promises. Firefox unterstützt diesen API-Typ bereits im Namensraum „browser.*“ und wird ihn für die dritte Version des Manifests in den Namensraum „chrome.*“ übertragen.
- Das neue granulare Berechtigungsanfrage-Modell funktioniert so, dass eine Erweiterung nicht sofort für alle Seiten aktiviert werden kann (die Berechtigung „all_urls“ wurde entfernt) und nur im Kontext des aktiven Tabs arbeitet. Das bedeutet, dass der Benutzer die Verwendung der Erweiterung für jede Webseite bestätigen muss. Mozilla arbeitet daran, den Zugriff zu kontrollieren, möchte den Nutzern aber die Entscheidung überlassen, ob sie den Erweiterungen die Arbeit mit unterschiedlichen Tabs erlauben.
- Verbot der Ausführung von Code, der von externen Quellen geladen wird Server (es geht um Situationen, in denen eine Erweiterung externen Code lädt und ausführt). In Firefox wird bereits externen Code blockiert, und die Mozilla-Entwickler sind bereit, zusätzliche Techniken zum Nachverfolgen von Code-Ladevorgängen zu den in der dritten Version des Manifests vorgeschlagenen hinzuzufügen. Für die Verarbeitungsskripte wird eine separate Richtlinie zur Zugriffsbeschränkung auf Inhalte (CSP, Content Security Policy) eingeführt, während die bestehenden APIs userScripts und contentScripts überarbeitet werden, um Erweiterungen auf Basis von Service Workern zu unterstützen.
Quelle: opennet.ru
