{"id":114309,"date":"2024-03-14T12:25:45","date_gmt":"2024-03-14T10:25:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/plany-v-otnoshenii-podderzhki-v-firefox-vtoroj-i-tretej-versij-manifesta-chrome"},"modified":"2024-03-14T12:25:45","modified_gmt":"2024-03-14T10:25:46","slug":"plany-v-otnoshenii-podderzhki-v-firefox-vtoroj-i-tretej-versij-manifesta-chrome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/plany-v-otnoshenii-podderzhki-v-firefox-vtoroj-i-tretej-versij-manifesta-chrome","title":{"rendered":"Pl\u00e4ne zur Unterst\u00fctzung der zweiten und dritten Version des Chrome-Manifests in Firefox","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Entwickler von Mozilla haben Informationen \u00fcber die Pl\u00e4ne zur Unterst\u00fctzung der zweiten und dritten Version des Chrome-Manifests in Firefox aktualisiert. Google plant, die Unterst\u00fctzung f\u00fcr 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\u00fctzung der zweiten Version des Manifests nicht vor Juli eingestellt. <\/p>\n
Im Gegenzug wird Mozilla in naher Zukunft die Unterst\u00fctzung der zweiten Version des Manifests nicht einstellen und die M\u00f6glichkeit beibehalten, Add-ons auszuf\u00fchren, die Funktionen verwenden, die in der dritten Version des Manifests nicht verf\u00fcgbar sind. Die Entscheidung, die vollst\u00e4ndige Kompatibilit\u00e4t mit der dritten Version des Chrome-Manifests in Firefox nicht zu gew\u00e4hrleisten, bleibt bestehen. Die vollst\u00e4ndige API webRequest wird in Firefox beibehalten, w\u00e4hrend sie in Chrome in den Nur-Lese-Modus versetzt wird. <\/p>\n
In Firefox wird auch durch den Mechanismus der Event Pages die Unterst\u00fctzung f\u00fcr die Ausf\u00fchrung von Hintergrundskripten auf Basis des DOM beibehalten, w\u00e4hrend 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\u00fctzt, aber Entwicklern wird die M\u00f6glichkeit geboten, im Add-on sowohl Event Pages als auch Service Workers als Handler zu definieren, was die Erstellung von Add-ons erm\u00f6glicht, die mit der dritten Version des Manifests kompatibel sind und in Chrome sowie Firefox funktionieren. <\/p>\n
Das Chrome-Manifest definiert die Funktionen und Ressourcen, die f\u00fcr Add-ons verf\u00fcgbar sind, die die API WebExtensions verwenden. Seit Version 57 hat Firefox vollst\u00e4ndig auf die Verwendung der API WebExtensions zur Entwicklung von Add-ons umgestellt und die Unterst\u00fctzung f\u00fcr die XUL-Technologie eingestellt. Der \u00dcbergang 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\u00e4ndige Nutzung des Mehrprozessmodus erm\u00f6glicht (WebExtensions-Add-ons k\u00f6nnen in separaten Prozessen ausgef\u00fchrt werden, isoliert von den anderen Teilen des Browsers). Um die Entwicklung von Add-ons mit anderen Browsern zu vereinheitlichen, wird in Firefox nahezu vollst\u00e4ndige Kompatibilit\u00e4t mit der zweiten Version des Chrome-Manifests gew\u00e4hrleistet. <\/p>\n
Im Rahmen der Initiative zur Vereinfachung der Erstellung sicherer und leistungsf\u00e4higer Erweiterungen sowie zur Erschwerung der M\u00f6glichkeit, 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\u00f6glichte, 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\u00e4nktes API, das declarativeNetRequest, hinzugef\u00fcgt, das den Zugriff auf die integrierte Filtermaschine erm\u00f6glicht, die die Blockierungsregeln selbstst\u00e4ndig verarbeitet und die Verwendung eigener Filteralgorithmen nicht zul\u00e4sst. <\/p>\n
Zu den Besonderheiten der Implementierung der dritten Version des Manifests in Firefox geh\u00f6ren: <\/p>\n
\n
Ein neuer deklarativer API zur Inhaltsfilterung wurde hinzugef\u00fcgt, aber im Gegensatz zu Chrome wurde die Unterst\u00fctzung f\u00fcr den alten blockierenden Modus des webRequest-API nicht eingestellt. <\/li>\n
Ein Mechanismus f\u00fcr Event Pages wurde implementiert, der f\u00fcr Webentwickler vertrauter ist, keine vollst\u00e4ndige \u00dcberarbeitung von Erweiterungen erfordert und die Einschr\u00e4nkungen im Zusammenhang mit der Verwendung von Service Workern beseitigt. Event Pages erm\u00f6glichen es, bestehende Erweiterungen mit Hintergrundseiten an die Anforderungen der dritten Version des Manifests anzupassen, w\u00e4hrend der Zugang zu allen f\u00fcr die Arbeit mit dem DOM erforderlichen Funktionen erhalten bleibt.\n
Ein neues, granuliertes Berechtigungsanforderungsmodell \u2013 die Erweiterung kann nicht sofort f\u00fcr alle Seiten aktiviert werden (Berechtigung \u201eall_urls\u201c wurde entfernt) und funktioniert nur im Kontext des aktiven Tabs, d.h. der Benutzer muss die Erweiterung f\u00fcr jede Website best\u00e4tigen. In Firefox werden alle Zugriffsanforderungen auf die Website-Daten als optional betrachtet, und die endg\u00fcltige Entscheidung \u00fcber den Zugriff obliegt dem Benutzer, der selektiv entscheiden kann, welcher Erweiterung der Zugriff auf seine Daten auf dieser oder jener Website gew\u00e4hrt wird.\n
Im Interface wurde die Schaltfl\u00e4che \u201eUnified Extensions\u201c hinzugef\u00fcgt, um die Berechtigungen zu verwalten. Damit kann der Benutzer direkt steuern, auf welche Websites jedes Plugin zugreifen kann \u2014 der Benutzer kann den Zugriff eines Plugins auf jede Website gew\u00e4hren oder widerrufen. Die Berechtigungsverwaltung gilt nur f\u00fcr Plugins, die auf dem Manifest der dritten Version basieren; f\u00fcr Plugins der zweiten Version wird keine detaillierte Zugriffskontrolle auf Websites durchgef\u00fchrt. <\/p>\n
<\/center> <\/li>\n
\u00c4nderung der Verarbeitung von Cross-Origin-Anfragen \u2013 gem\u00e4\u00df dem neuen Manifest gelten dieselben Berechtigungsbeschr\u00e4nkungen f\u00fcr die Skripte zur Verarbeitung von Inhalten, die auch f\u00fcr die Hauptseite gelten, in die diese Skripte eingebettet werden (z.B. wenn die Seite keinen Zugriff auf die Geolocation-API hat, erh\u00e4lt auch das Erweiterungsskript keinen Zugriff). Diese \u00c4nderung ist vollst\u00e4ndig in Firefox implementiert. <\/li>\n
API basierend auf Promises. Firefox unterst\u00fctzt dieses API auch f\u00fcr die dritte Version des Manifests. <\/li>\n
![\"Pl\u00e4ne](\"\/wp-content\/uploads\/2024\/03\/fe76b83a5dc61990f0346c1d84f29114.png\")
<\/center> <\/li>\n