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
