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

Die Entwickler von Mozilla haben Informationen über die Pläne zur Unterstützung der zweiten und dritten Version des Chrome-Manifests in Firefox aktualisiert. Google plant, die Unterstützung für Add-ons, die die zweite Version des Manifests verwenden, im Juni dieses Jahres in den Testversionen von Chrome 127 (Dev, Canary und Beta) einzustellen. In der stabilen Version wird die Unterstützung der zweiten Version des Manifests nicht vor Juli eingestellt.

Im Gegenzug wird Mozilla in naher Zukunft die Unterstützung der zweiten Version des Manifests nicht einstellen und die Möglichkeit beibehalten, Add-ons auszuführen, die Funktionen verwenden, die in der dritten Version des Manifests nicht verfügbar sind. Die Entscheidung, die vollständige Kompatibilität mit der dritten Version des Chrome-Manifests in Firefox nicht zu gewährleisten, bleibt bestehen. Die vollständige API webRequest wird in Firefox beibehalten, während sie in Chrome in den Nur-Lese-Modus versetzt wird.

In Firefox wird auch durch den Mechanismus der Event Pages die Unterstützung für die Ausführung von Hintergrundskripten auf Basis des DOM beibehalten, während in der dritten Version des Manifests die Verwendung von Service Workers vorgeschrieben ist. Hintergrundskripte auf Basis von Service Workers werden in Firefox derzeit nicht unterstützt, aber Entwicklern wird die Möglichkeit geboten, im Add-on sowohl Event Pages als auch Service Workers als Handler zu definieren, was die Erstellung von Add-ons ermöglicht, die mit der dritten Version des Manifests kompatibel sind und in Chrome sowie Firefox funktionieren.

Das Chrome-Manifest definiert die Funktionen und Ressourcen, die für Add-ons verfügbar sind, die die API WebExtensions verwenden. Seit Version 57 hat Firefox vollständig auf die Verwendung der API WebExtensions zur Entwicklung von Add-ons umgestellt und die Unterstützung für die XUL-Technologie eingestellt. Der Übergang zu WebExtensions hat die Entwicklung von Add-ons mit den Plattformen Chrome, Opera, Safari und Edge vereinheitlicht, das Portieren von Add-ons zwischen verschiedenen Webbrowsern vereinfacht und die vollständige Nutzung des Mehrprozessmodus ermöglicht (WebExtensions-Add-ons können in separaten Prozessen ausgeführt werden, isoliert von den anderen Teilen des Browsers). Um die Entwicklung von Add-ons mit anderen Browsern zu vereinheitlichen, wird in Firefox nahezu vollständige Kompatibilität mit der zweiten Version des Chrome-Manifests gewährleistet.

Im Rahmen der Initiative zur Vereinfachung der Erstellung sicherer und leistungsfähiger Erweiterungen sowie zur Erschwerung der Möglichkeit, unsichere und langsame Erweiterungen zu erstellen, hat Google die dritte Version des Manifests entwickelt. Die Hauptkritik an der dritten Version des Manifests resultiert aus der Umstellung des webRequest-API in einen Nur-Lese-Modus, der es ermöglichte, eigene Handler zu verbinden, die vollen Zugriff auf Netzwerkrequests hatten und den Verkehr in Echtzeit modifizieren konnten. Anstelle des webRequest-API wurde in der dritten Version des Manifests ein eingeschränktes API, das declarativeNetRequest, hinzugefügt, das den Zugriff auf die integrierte Filtermaschine ermöglicht, die die Blockierungsregeln selbstständig verarbeitet und die Verwendung eigener Filteralgorithmen nicht zulässt.

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

• Ein neuer deklarativer API zur Inhaltsfilterung wurde hinzugefügt, aber im Gegensatz zu Chrome wurde die Unterstützung für den alten blockierenden Modus des webRequest-API nicht eingestellt.
• Ein Mechanismus für Event Pages wurde implementiert, der für Webentwickler vertrauter ist, keine vollständige Überarbeitung von Erweiterungen erfordert und die Einschränkungen im Zusammenhang mit der Verwendung von Service Workern beseitigt. Event Pages ermöglichen es, bestehende Erweiterungen mit Hintergrundseiten an die Anforderungen der dritten Version des Manifests anzupassen, während der Zugang zu allen für die Arbeit mit dem DOM erforderlichen Funktionen erhalten bleibt.
• 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.

  Um die Berechtigungen zu verwalten, wurde im Interface die Schaltfläche „Unified Extensions“ hinzugefügt, um direkt zu steuern, auf welche Websites jede Erweiterung Zugriff hat — der Benutzer kann der Erweiterung den Zugang zu einer beliebigen Website gewähren oder entziehen. Die Verwaltung der Berechtigungen gilt nur für Erweiterungen auf Basis des dritten Manifestes, für Erweiterungen auf Basis des zweiten Manifestes erfolgt keine granulare Zugriffskontrolle auf Websites.

  
• Ä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.
• API basierend auf Promises. Firefox unterstützt dieses API auch für die dritte Version des Manifests.
• Verbot der Ausführung von Code, der von externen Quellen geladen wird Server (es handelt sich um Situationen, in denen eine Erweiterung externen Code lädt und ausführt). In Firefox wird externe Code blockiert und die Entwickler von Mozilla haben zusätzliche Techniken zur Verfolgung von Code-Downloads hinzugefügt. Für die Skripte zur Verarbeitung von Inhalten wurde eine separate Politik zur Einschränkung des Zugriffs auf Inhalte (CSP, Content Security Policy) eingeführt.

Quelle: opennet.ru