Die Mozilla Corporation hat mit dem Testen der dritten Version des Chrome-Manifests in Firefox begonnen, die die Möglichkeiten und Ressourcen definiert, die fĂŒr Erweiterungen zur VerfĂŒgung stehen, die mit der WebExtensions-API geschrieben wurden. Um die dritte Version des Manifests in der Beta-Version von Firefox 101 zu testen, sollte der Parameter âextensions.manifestV3.enabledâ auf true und der Parameter âxpinstall.signatures.requiredâ auf false in der Seite about:config eingestellt werden. Erweiterungen können ĂŒber die Schnittstelle about:debugging installiert werden. Die Standardaktivierung der dritten Version des Manifests ist fĂŒr Ende des Jahres geplant.
Seit Version 57 hat Firefox vollstĂ€ndig auf die WebExtensions-API zur Entwicklung von Erweiterungen umgestellt und die UnterstĂŒtzung der XUL-Technologie eingestellt. Der Ăbergang zu WebExtensions ermöglichte eine Vereinheitlichung der Entwicklung von Erweiterungen mit den Plattformen Chrome, Opera, Safari und Edge, vereinfachte das Portieren von Erweiterungen zwischen verschiedenen Webbrowsern und ermöglichte die umfassende Nutzung des Multiprozessbetriebs (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, gewĂ€hrleistet Firefox nahezu vollstĂ€ndige KompatibilitĂ€t mit der zweiten Version des Chrome-Manifests.
Derzeit wird in Chrome an dem Ăbergang zur dritten Version des Manifests gearbeitet, und die UnterstĂŒtzung der zweiten Version wird im Januar 2023 eingestellt. Da die dritte Version des Manifests Kritik ausgelöst hat und die Funktionsweise vieler Erweiterungen zur Blockierung unerwĂŒnschter Inhalte und zur GewĂ€hrleistung der Sicherheit beeintrĂ€chtigen wird, hat die Mozilla Corporation beschlossen, von der Praxis der vollstĂ€ndigen KompatibilitĂ€t mit dem Manifest in Firefox abzugehen und einige Ănderungen anders umzusetzen.
Die Hauptkritik an der dritten Manifestversion bezieht sich auf die Umstellung der API webRequest in den Nur-Lese-Modus. Diese API erlaubte es, eigene Handler zu integrieren, die vollen Zugriff auf Netzwerkrequests hatten und den Datenverkehr in Echtzeit modifizieren konnten. Diese API wird in uBlock Origin und vielen anderen Erweiterungen zur Blockierung unerwĂŒnschter Inhalte und zur SicherheitsgewĂ€hrleistung verwendet. Statt der API webRequest wird in der dritten Manifestversion eine eingeschrĂ€nkte API namens declarativeNetRequest angeboten, die Zugriff auf eine integrierte Engine fĂŒr die Filterung bietet, die Regeln zur Blockierung selbst verarbeitet, aber keine eigenen Filteralgorithmen und keine komplexen, sich gegenseitig ĂŒberlappenden Regeln je nach Bedingungen zulĂ€sst.
In der in Firefox vorgeschlagenen Umsetzung der dritten Version des Manifests wurde eine neue deklarative API zur Filterung von Inhalten hinzugefĂŒgt, jedoch wurde im Gegensatz zu Chrome die UnterstĂŒtzung des alten Blockierungsmodus der API webRequest nicht eingestellt. Zu den weiteren Besonderheiten der Umsetzung des neuen Manifests in Firefox gehören:
- Im Manifest wird der Austausch von Hintergrundseiten durch die Option Service Workers definiert, die als Hintergrundprozesse (Background Service Workers) fungieren. Um die KompatibilitĂ€t mit Firefox sicherzustellen, wird dieses Erfordernis umgesetzt, und zusĂ€tzlich wird ein neuer Mechanismus namens Event Pages vorgeschlagen, der fĂŒr Webentwickler vertrauter ist, keine vollstĂ€ndige Ăberarbeitung von Erweiterungen erfordert und die EinschrĂ€nkungen im Zusammenhang mit der Verwendung von Service Workers beseitigt. Event Pages ermöglichen es, bestehende Erweiterungen mit Hintergrundseiten an die Anforderungen der dritten Version des Manifests anzupassen und gleichzeitig den Zugang zu allen notwendigen Funktionen fĂŒr die Arbeit mit dem DOM zu gewĂ€hrleisten. In der fĂŒr Tests in Firefox verfĂŒgbaren Umsetzung des Manifests werden derzeit nur Event Pages unterstĂŒtzt, wĂ€hrend die UnterstĂŒtzung einer Lösung basierend auf Service Workers spĂ€ter versprochen wurde. Dieses Angebot wurde von Apple unterstĂŒtzt, und Event Pages wurden in der Veröffentlichung Safari Technology Preview 136 implementiert.
- Ein neues granuliertes Berechtigungsanforderungsmodell â eine Erweiterung kann nicht mehr sofort fĂŒr alle Seiten aktiviert werden (die Berechtigung âall_urlsâ wurde entfernt), sondern arbeitet nur im Kontext des aktiven Tabs, d.h. der Benutzer muss die Nutzung der Erweiterung fĂŒr jede Website bestĂ€tigen. In Firefox werden alle Anfragen nach Zugang zu den Daten einer Website als optional betrachtet, und die endgĂŒltige Entscheidung ĂŒber den Zugriff liegt beim Benutzer, der auswĂ€hlen kann, welcher Erweiterung die Erlaubnis zu seinen Daten auf einer bestimmten Website gewĂ€hrt werden soll.
- Ănderung der Verarbeitung von Cross-Origin-Anfragen â gemÀà dem neuen Manifest unterliegen die Skripte zur Verarbeitung von Inhalten denselben BerechtigungsbeschrĂ€nkungen wie die Hauptseite, in die diese Skripte eingefĂŒgt werden (z.B. wenn die Seite keinen Zugriff auf die Standort-API hat, erhĂ€lt auch das Erweiterungsskript diesen Zugriff nicht). Diese Ănderung ist vollstĂ€ndig in Firefox implementiert.
- Promise-basiertes API. Firefox unterstĂŒtzt bereits dieses API und wird es fĂŒr die dritte Version des Manifests in den Namensraum âchrome.*â verschieben.
- Verbot der AusfĂŒhrung von Code, der von externen Quellen geladen wird Server (bezieht sich auf Situationen, in denen eine Erweiterung externen Code lĂ€dt und ausfĂŒhrt). In Firefox wird bereits die AusfĂŒhrung externen Codes blockiert, und die Entwickler von Mozilla haben zusĂ€tzliche Techniken zur Verfolgung von Code-Ladungen hinzugefĂŒgt, die in der dritten Version des Manifests vorgeschlagen werden. FĂŒr Content-Script wurden eine separate Richtlinie zur EinschrĂ€nkung des Zugangs zu Inhalten (CSP, Content Security Policy) eingefĂŒhrt.
Quelle: opennet.ru
