Mozilla hat mit dem Testen der Implementierung der dritten Version des Chrome-Manifests in Firefox begonnen, das die Funktionen und Ressourcen definiert, die fĂŒr mit der WebExtensions-API entwickelte Erweiterungen verfĂŒgbar sind. Um die dritte Version des Manifests in der Beta-Version von Firefox 101 zu testen, sollte die Einstellung «extensions.manifestV3.enabled» auf true und «xpinstall.signatures.required» auf false gesetzt werden. Zum Installieren von Erweiterungen kann das Interface about:debugging verwendet werden. Die Standardaktivierung der dritten Version des Manifests ist fĂŒr Ende des Jahres geplant.
Mit der Version 57 ist Firefox vollstĂ€ndig auf die Nutzung der WebExtensions-API fĂŒr die Entwicklung von Erweiterungen umgestiegen und hat die UnterstĂŒtzung fĂŒr die XUL-Technologie eingestellt. Der Wechsel zu WebExtensions hat die Entwicklung von Erweiterungen mit den Plattformen Chrome, Opera, Safari und Edge vereinheitlicht, das Portieren von Erweiterungen zwischen verschiedenen Webbrowsern vereinfacht und die Möglichkeit geschaffen, den Mehrprozessbetrieb vollstĂ€ndig zu nutzen (WebExtensions-Erweiterungen können in separaten Prozessen ausgefĂŒhrt werden, isoliert von anderen Teilen des Browsers). Um die Entwicklung von Erweiterungen mit anderen Browsern zu vereinheitlichen, bietet Firefox nahezu vollstĂ€ndige KompatibilitĂ€t mit der zweiten Version des Chrome-Manifests.
Derzeit arbeitet Chrome an der Umstellung auf die dritte Version des Manifests, wĂ€hrend die UnterstĂŒtzung der zweiten Version im Januar 2023 eingestellt wird. Da die dritte Version des Manifests in der Kritik steht und die FunktionalitĂ€t vieler Erweiterungen zum Blockieren unerwĂŒnschter Inhalte und zur GewĂ€hrleistung der Sicherheit beeintrĂ€chtigen könnte, hat Mozilla beschlossen, von der Praxis der vollstĂ€ndigen KompatibilitĂ€t mit dem Manifest in Firefox abzurĂŒcken und einige Ănderungen anders umzusetzen.
Die Hauptbeschwerde ĂŒber die dritte Version des Manifests betrifft die Umstellung des API webRequest auf den Nur-Lese-Modus, der es ermöglichte, eigene Handler zu integrieren, die vollen Zugriff auf Netzwerk-Anfragen hatten und den Datenverkehr in Echtzeit modifizieren konnten. Dieses API wird in uBlock Origin und vielen anderen Erweiterungen verwendet, um unerwĂŒnschte Inhalte zu blockieren und die Sicherheit zu gewĂ€hrleisten. Anstelle des API webRequest wurde in der dritten Version des Manifests ein eingeschrĂ€nktes API namens declarativeNetRequest vorgeschlagen, das Zugriff auf eine interne Filter-Engine gewĂ€hrt, die die Blockierungsregeln selbstĂ€ndig verarbeitet, keine eigenen Filteralgorithmen zulĂ€sst und keine komplexen Regeln unterstĂŒtzt, die sich je nach Bedingungen ĂŒberschneiden.
In der von Firefox implementierten dritten Version des Manifests wurde eine neue deklarative API zur Inhaltsfilterung hinzugefĂŒgt. Im Gegensatz zu Chrome wird jedoch die UnterstĂŒtzung des alten blockierenden Modus der API webRequest nicht eingestellt. Zu den weiteren Besonderheiten der neuen Manifest-Implementierung in Firefox gehören:
- Im Manifest wird die Ersetzung von Hintergrundseiten durch eine Variante der Service Workers definiert, die als Hintergrundprozesse (Background Service Workers) funktionieren. Um die KompatibilitĂ€t sicherzustellen, wird Firefox diese Anforderung umsetzen, zudem wird ein neuer Mechanismus fĂŒr Event Pages vorgeschlagen, der fĂŒr Web-Entwickler vertrauter ist, keine vollstĂ€ndige Ăberarbeitung der Erweiterungen erfordert und EinschrĂ€nkungen im Zusammenhang mit der Verwendung von Service Workers beseitigt. Event Pages ermöglicht es, bestehende Erweiterungen mit Hintergrundseiten an die Anforderungen der dritten Manifestversion anzupassen, wĂ€hrend der Zugang zu sĂ€mtlichen notwendigen Funktionen fĂŒr die Arbeit mit dem DOM erhalten bleibt. In der testbaren Implementierung des Manifests in Firefox werden derzeit nur Event Pages unterstĂŒtzt; die UnterstĂŒtzung einer Lösung auf Basis von Service Workers wird zu einem spĂ€teren Zeitpunkt versprochen. Dieses Angebot wurde von Apple unterstĂŒtzt und Event Pages wurden in der Safari Technology Preview 136 implementiert.
- Das neue granulare Berechtigungsanfragenmodell â Erweiterungen können nicht mehr sofort fĂŒr alle Seiten aktiviert werden (die Berechtigung âall_urlsâ wurde entfernt) und funktionieren nur im Kontext des aktiven Tabs. Das bedeutet, der Nutzer muss die Aktivierung der Erweiterung fĂŒr jede Website bestĂ€tigen. In Firefox werden alle Anfragen auf den Zugriff auf die Daten einer Website als optional betrachtet, und die endgĂŒltige Entscheidung ĂŒber den Zugriff trifft der Nutzer, der selektiv entscheiden kann, welcher Erweiterung er den Zugriff auf seine Daten auf dieser oder jener Website gewĂ€hren möchte.
- Ă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 integriert werden (zum Beispiel: Wenn die Seite keinen Zugriff auf die API zur Geolokalisierung hat, erhĂ€lt das Erweiterungsskript ebenfalls keinen Zugriff). Diese Ănderung ist vollstĂ€ndig in Firefox implementiert.
- API basierend auf Promises. Firefox unterstĂŒtzt bereits dieses API und wird es in der dritten Version des Manifests in den Namensraum âchrome.*â ĂŒberfĂŒhren.
- Verbot der AusfĂŒhrung von Code, der von externen Quellen geladen wird Server (bezogen auf Situationen, in denen ein Add-on externen Code lĂ€dt und ausfĂŒhrt). In Firefox ist bereits die Blockierung externen Codes aktiv, und die Entwickler von Mozilla haben zusĂ€tzliche Techniken zur Verfolgung von Code-LadevorgĂ€ngen, die in der dritten Version des Manifests vorgeschlagen werden, hinzugefĂŒgt. FĂŒr Content-Handling-Skripte gibt es eine spezielle Richtlinie fĂŒr den Zugriff auf Inhalte (CSP, Content Security Policy).
Quelle: opennet.ru
