Pläne zur Unterstützung der zweiten und dritten Version des Chrome-Manifests in Firefox

Die Entwickler von Mozilla haben ihre Pläne zur Unterstützung der zweiten und dritten Manifestversionen von Chrome in Firefox aktualisiert. Google hat angekündigt, die Unterstützung von Erweiterungen, die die zweite Manifestversion verwenden, in den Testversionen von Chrome 127 (Dev, Canary und Beta) im Juni dieses Jahres einzustellen. In der stabilen Version wird die Unterstützung der zweiten Manifestversion frühestens im Juli eingestellt.

Im Gegenzug wird Mozilla in naher Zukunft die Unterstützung der zweiten Manifestversion nicht einstellen und die Möglichkeit beibehalten, Erweiterungen zu nutzen, die Funktionen nutzen, die in der dritten Manifestversion nicht verfügbar sind. Es bleibt dabei, dass Firefox keine vollständige Kompatibilität mit der dritten Manifestversion von Chrome gewährleisten wird. In Firefox wird die vollständige API webRequest erhalten bleiben, die in Chrome in den Nur-Lese-Modus versetzt wird.

In Firefox wird auch mit Hilfe des Mechanismus der Event Pages die Unterstützung für Hintergrundskripte auf Basis des DOM erhalten bleiben. In der dritten Version des Manifests wird jedoch vorgeschrieben, Service Workers zu verwenden. Hintergrundskripte auf Basis von Service Workers werden in Firefox derzeit nicht unterstützt, aber Entwicklern wird die Möglichkeit gegeben, in der Erweiterung sowohl Event Pages als auch Service Workers als Handler zu definieren. Dies ermöglicht die Erstellung von Erweiterungen, die der dritten Manifestversion entsprechen und sowohl in Chrome als auch in Firefox funktionieren.

Das Chrome-Manifest definiert die Möglichkeiten und Ressourcen, die für Erweiterungen verfügbar sind, die unter Verwendung der WebExtensions-API entwickelt wurden. Seit Version 57 hat Firefox vollständig auf die Nutzung der WebExtensions-API für die Entwicklung von Erweiterungen umgestellt und die Unterstützung der XUL-Technologie eingestellt. Der Umstieg auf WebExtensions hat es ermöglicht, die Entwicklung von Erweiterungen mit den Plattformen Chrome, Opera, Safari und Edge zu vereinheitlichen, das Portieren von Erweiterungen zwischen verschiedenen Webbrowsern zu erleichtern und die vollständige Nutzung des Multiprozessmodus zu ermöglichen (WebExtensions-Erweiterungen können in separaten Prozessen ausgeführt werden, isoliert von den anderen Teilen des Browsers). Um die Entwicklung von Erweiterungen mit anderen Browsern zu vereinheitlichen, bietet Firefox eine nahezu vollständige Kompatibilität mit der zweiten Version des Chrome-Manifests.

Im Rahmen der Initiative zur Vereinfachung der Entwicklung sicherer und leistungsstarker Erweiterungen sowie zur Verkomplizierung der Erstellung unsicherer und langsamer Erweiterungen hat Google die dritte Version des Manifests entwickelt. Die Hauptkritik an der dritten Version des Manifests betrifft die Umstellung der API webRequest in den Nur-Lese-Modus, die die Verbindung eigener Handler ermöglicht hat, die vollen Zugriff auf Netzwerkrequests hatten und den Traffic in Echtzeit modifizieren konnten. Anstelle der API webRequest wurde in der dritten Version des Manifests eine eingeschränkte API namens declarativeNetRequest hinzugefügt, die Zugang zu einer integrierten Engine zur Filterung bietet, die die Blockierungsregeln selbst verarbeitet und keine eigenen Filteralgorithmen zulässt.

Zu den Besonderheiten der Implementierung der dritten Version des Manifests in Firefox gehören:

• Ein neues deklaratives API zur Filterung von Inhalten wurde hinzugefügt, jedoch wurde im Gegensatz zu Chrome die Unterstützung des alten blockierenden Modus des API webRequest nicht eingestellt.
• Ein Event Pages Mechanismus wurde implementiert, der für Webentwickler vertrauter ist, keine vollständige Überarbeitung der Erweiterungen erfordert und Einschränkungen im Zusammenhang mit der Verwendung von Service-Workern beseitigt. Mit Event Pages können vorhandene Erweiterungen mit Hintergrundseiten an die Anforderungen der dritten Version des Manifests angepasst werden, während gleichzeitig der Zugang zu allen notwendigen Funktionen für die Arbeit mit dem DOM erhalten bleibt.
• 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.

  Zur Verwaltung von Berechtigungen wurde im Interface die Schaltfläche „Unified Extensions“ hinzugefügt, mit der direkt verwaltet werden kann, auf welche Websites jede Erweiterung zugreifen kann – der Nutzer kann den Zugriff der Erweiterung auf jede Website gewähren oder widerrufen. Die Verwaltung der Berechtigungen gilt nur für Erweiterungen auf Basis der dritten Version des Manifests; für Erweiterungen auf der zweiten Version des Manifests wird eine granulare Zugriffskontrolle auf Websites nicht vorgenommen.

  
• Ä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 Promise. Firefox unterstützt diese API auch für die dritte Version des Manifests.
• 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 externe Codeblockierung angewendet, und die Entwickler von Mozilla haben zusätzliche Techniken zur Verfolgung von Code-Downloads hinzugefügt. Für die Verarbeitungsskripte gibt es eine separate Richtlinie zur Beschränkung des Zugriffs auf Inhalte (CSP, Content Security Policy).

Quelle: opennet.ru