{"id":105614,"date":"2022-11-18T03:36:41","date_gmt":"2022-11-18T01:36:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/mozilla-nachnyot-prinimat-dopolneniya-na-baze-tretej-versii-manifesta-chrome"},"modified":"2022-11-18T03:36:41","modified_gmt":"2022-11-18T01:36:42","slug":"mozilla-nachnyot-prinimat-dopolneniya-na-baze-tretej-versii-manifesta-chrome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/mozilla-nachnyot-prinimat-dopolneniya-na-baze-tretej-versii-manifesta-chrome","title":{"rendered":"Mozilla beginnt mit der Annahme von Erweiterungen auf Basis der dritten Version des Chrome-Manifests.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ab dem 21. November wird das AMO-Katalog (addons.mozilla.org) digitale Signaturen f\u00fcr Erweiterungen akzeptieren und verifizieren, die die dritte Version des Chrome-Manifests nutzen. Diese Erweiterungen k\u00f6nnen in den Nachtausgaben von Firefox getestet werden. Die Unterst\u00fctzung der dritten Manifestversion wird in der stabilen Version von Firefox 109, die f\u00fcr den 17. Januar 2023 geplant ist, aktiviert. Die Unterst\u00fctzung der zweiten Manifestversion wird in naher Zukunft erhalten bleiben, jedoch wird Ende 2023, nach einer Bewertung des Fortschritts bei der Migration der Erweiterungen zur dritten Manifestversion, eine Entscheidung zur m\u00f6glichen Abwertung der Unterst\u00fctzung der zweiten Manifestversion getroffen. <\/p>\n
Das Chrome-Manifest definiert die M\u00f6glichkeiten und Ressourcen, die f\u00fcr Erweiterungen verf\u00fcgbar sind, die unter Verwendung der WebExtensions-API entwickelt wurden. Seit Version 57 hat Firefox vollst\u00e4ndig auf die Nutzung der WebExtensions-API f\u00fcr die Entwicklung von Erweiterungen umgestellt und die Unterst\u00fctzung der XUL-Technologie eingestellt. Der Umstieg auf WebExtensions hat es erm\u00f6glicht, 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\u00e4ndige Nutzung des Multiprozessmodus zu erm\u00f6glichen (WebExtensions-Erweiterungen k\u00f6nnen in separaten Prozessen ausgef\u00fchrt werden, isoliert von den anderen Teilen des Browsers). Um die Entwicklung von Erweiterungen mit anderen Browsern zu vereinheitlichen, bietet Firefox eine nahezu vollst\u00e4ndige Kompatibilit\u00e4t mit der zweiten Version des Chrome-Manifests. <\/p>\n
Momentan arbeitet Chrome am \u00dcbergang zur dritten Version des Manifests, w\u00e4hrend die Unterst\u00fctzung der zweiten Version im Januar 2024 eingestellt wird. Das Hauptziel der \u00c4nderungen in der neuen Version ist es, die Erstellung von sicheren und leistungsstarken Erweiterungen zu erleichtern und die M\u00f6glichkeit zur Erstellung von unsicheren und langsamen Erweiterungen zu erschweren. Da die dritte Version des Manifests kritisiert wurde und zu Funktionsst\u00f6rungen vieler Erweiterungen zur Blockierung unerw\u00fcnschten Inhalts und zur Sicherheit f\u00fchren k\u00f6nnte, hat Mozilla entschieden, von der vollst\u00e4ndigen Kompatibilit\u00e4t mit dem Manifest in Firefox abzusehen und einige \u00c4nderungen anders umzusetzen. <\/p>\n
Die Hauptbeschwerde \u00fcber die dritte Version des Manifests betrifft die Umstellung des API webRequest auf den Nur-Lese-Modus, der es erm\u00f6glichte, 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\u00fcnschte Inhalte zu blockieren und die Sicherheit zu gew\u00e4hrleisten. Anstelle des API webRequest wurde in der dritten Version des Manifests ein eingeschr\u00e4nktes API namens declarativeNetRequest vorgeschlagen, das Zugriff auf eine interne Filter-Engine gew\u00e4hrt, die die Blockierungsregeln selbst\u00e4ndig verarbeitet, keine eigenen Filteralgorithmen zul\u00e4sst und keine komplexen Regeln unterst\u00fctzt, die sich je nach Bedingungen \u00fcberschneiden. <\/p>\n
Zu den besonderen Merkmalen der Implementierung des neuen Manifests in Firefox geh\u00f6ren: <\/p>\n
\n
Ein neues deklaratives API zur Filterung von Inhalten wurde hinzugef\u00fcgt, jedoch wurde im Gegensatz zu Chrome die Unterst\u00fctzung des alten blockierenden Modus des API webRequest nicht eingestellt.\n
Im Manifest wird der Ersatz von Hintergrundseiten durch eine Variante der Service Workers beschrieben, die als Hintergrundprozesse (Background Service Workers) arbeitet. Um zuk\u00fcnftige Kompatibilit\u00e4t zu gew\u00e4hrleisten, wird Firefox Unterst\u00fctzung f\u00fcr Service Workers umsetzen. Derzeit wurde jedoch ein neuer Mechanismus f\u00fcr Event Pages vorgeschlagen, der f\u00fcr Webentwickler vertrauter ist, keine umfassende \u00dcberarbeitung der Erweiterungen erfordert und die Einschr\u00e4nkungen des Einsatzes von Service Workers beseitigt. Event Pages erm\u00f6glichen es, bestehende Erweiterungen mit Hintergrundseiten an die Anforderungen der dritten Manifestversion anzupassen und gleichzeitig den Zugang zu allen notwendigen Funktionen f\u00fcr die Arbeit mit dem DOM zu erhalten. <\/li>\n
Das neue granulierte Berechtigungsanfragemodell \u2014 das Zusatzmodul kann nicht sofort f\u00fcr alle Seiten aktiviert werden (die Berechtigung \u201eall_urls\u201c wurde entfernt) und funktioniert nur im Kontext des aktiven Tabs. Das hei\u00dft, der Benutzer muss die Funktionsweise des Zusatzmoduls f\u00fcr jede Website best\u00e4tigen. In Firefox werden alle Anfragen nach Zugriff auf Website-Daten als optional betrachtet, und die endg\u00fcltige Entscheidung \u00fcber den Zugang wird vom Benutzer getroffen, der selektiv entscheiden kann, welchem Zusatzmodul er Zugriff auf seine Daten auf dieser oder jener Website gew\u00e4hrt.\n
Zur Verwaltung der Berechtigungen wurde im Interface ein neuer Button \u201eUnified Extensions\u201c hinzugef\u00fcgt, der bereits in den Nachbauen von Firefox getestet werden kann. Der Button bietet Werkzeuge zur direkten Verwaltung des Zugriffs jedes Zusatzmoduls auf Websites \u2014 der Benutzer kann den Zugriff eines Zusatzmoduls auf jede Website gew\u00e4hren oder widerrufen. Die Berechtigungsverwaltung gilt nur f\u00fcr Zusatzmodule, die auf der dritten Manifestversion basieren; f\u00fcr Zusatzmodule, die auf der zweiten Version basieren, wird keine granulierte Zugriffskontrolle auf Websites durchgef\u00fchrt.
<\/center> <\/li>\n
\u00c4nderung der Cross-Origin-Anfragenverarbeitung \u2014 entsprechend dem neuen Manifest gelten die gleichen Berechtigungsbeschr\u00e4nkungen wie f\u00fcr die Hauptseite, in die diese Skripte eingebettet sind (zum Beispiel, wenn die Seite keinen Zugriff auf die API zur Standortbestimmung hat, erh\u00e4lt auch das Erg\u00e4nzungsskript keinen Zugriff). Diese \u00c4nderung ist vollst\u00e4ndig in Firefox implementiert. <\/li>\n
Promise-basiertes API. Firefox unterst\u00fctzt dieses API und wird es f\u00fcr die dritte Manifestversion in den Namensraum \u201echrome.*\u201c verschieben. <\/li>\n
![\"Mozilla](\"\/wp-content\/uploads\/2022\/11\/62422c3bf8021866caee67b47e642d5c.jpg\")
<\/center> <\/li>\n