{"id":100307,"date":"2021-05-28T16:22:45","date_gmt":"2021-05-28T14:22:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/mozilla-obobshhila-plany-po-podderzhke-v-firefox-tretej-versii-manifesta-chrome"},"modified":"2021-05-28T16:22:45","modified_gmt":"2021-05-28T14:22:45","slug":"mozilla-obobshhila-plany-po-podderzhke-v-firefox-tretej-versii-manifesta-chrome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/mozilla-obobshhila-plany-po-podderzhke-v-firefox-tretej-versii-manifesta-chrome","title":{"rendered":"Mozilla hat die Pl\u00e4ne zur Unterst\u00fctzung der dritten Version des Chrome-Manifests in Firefox zusammengefasst.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Mozilla hat einen Plan zur Umsetzung der dritten Version des Chrome-Manifests in Firefox ver\u00f6ffentlicht, welches die M\u00f6glichkeiten und Ressourcen f\u00fcr Add-ons definiert. Die dritte Version des Manifests wurde kritisiert, da sie die Funktionalit\u00e4t vieler Add-ons zur Blockierung unerw\u00fcnschter Inhalte sowie zur Gew\u00e4hrleistung von Sicherheit beeintr\u00e4chtigt. <\/p>\n
In Firefox beabsichtigt man, nahezu alle Funktionen und Einschr\u00e4nkungen des neuen Manifests zu implementieren, einschlie\u00dflich der deklarativen API zur Inhaltsfilterung (declarativeNetRequest). Im Gegensatz zu Chrome wird jedoch in Firefox die Unterst\u00fctzung des alten blockierenden Modus der API webRequest nicht eingestellt \u2013 zumindest so lange, bis die neue API vollst\u00e4ndig den Bed\u00fcrfnissen der Entwickler von Add-ons entspricht, die die API webRequest nutzen. Dieser Ansatz garantiert die Kompatibilit\u00e4t mit Chrome-Add-ons, ohne dabei die Kompatibilit\u00e4t mit Add-ons zu beeintr\u00e4chtigen, die auf die API webRequest angewiesen sind. <\/p>\n
Wir erinnern daran, dass die Hauptbeschwerde \u00fcber das neue Manifest mit der Umstellung des API webRequest auf den Nur-Lese-Modus zusammenh\u00e4ngt. Dieses API erlaubte die Anbindung eigener Handler, die vollst\u00e4ndigen Zugriff auf Netzwerkrequests hatten und den Verkehr in Echtzeit modifizieren konnten. Das besagte API wird in uBlock Origin und vielen anderen Erweiterungen verwendet, um unerw\u00fcnschte Inhalte zu blockieren und Sicherheit zu gew\u00e4hrleisten. Statt des API webRequest wurde ein eingeschr\u00e4nkteres API namens declarativeNetRequest vorgeschlagen, das Zugang zu einer integrierten Engine f\u00fcr die Filterung bietet, die die Blockierungsregeln eigenst\u00e4ndig verarbeitet. Es erlaubt nicht, eigene Filteralgorithmen zu verwenden und verbietet die Festlegung komplexer, voneinander abh\u00e4ngiger Regeln. <\/p>\n
F\u00fcr Firefox wird die Unterst\u00fctzung der dritten Version des Chrome-Manifests f\u00fcr Tests Ende 2021 bereitgestellt, w\u00e4hrend die Einf\u00fchrung des neuen Manifests f\u00fcr Anfang 2022 geplant ist. Zu den Besonderheiten der Implementierung des neuen Manifests in Firefox geh\u00f6rt: <\/p>\n
\n
Die Bereitstellung des API declarativeNetRequest mit der M\u00f6glichkeit, weiterhin das alte API webRequest zu verwenden.\n
\u00c4nderung der Verarbeitung von Cross-Origin-Anfragen \u2014 gem\u00e4\u00df dem neuen Manifest gelten f\u00fcr die Skripte zur Verarbeitung von Inhalten die gleichen Einschr\u00e4nkungen wie f\u00fcr die Hauptseite, in die diese Skripte eingebettet werden (z. B. wenn die Seite keinen Zugriff auf die Standort-API hat, erh\u00e4lt auch das Erg\u00e4nzungsskript keinen Zugriff). Teile der mit den Einschr\u00e4nkungen von Cross-Origin-Anfragen verbundenen \u00c4nderungen sind bereits in den Nachtschnappungen von Firefox zur Testung verf\u00fcgbar (wird als Teil des Fission-Projekts entwickelt, das unter about:preferences#experimental aktiviert werden kann) und soll im dritten Quartal 2021 fl\u00e4chendeckend eingef\u00fchrt werden.\n
Hintergrundseiten werden durch Service Worker ersetzt, die als Hintergrundprozesse arbeiten. Diese \u00c4nderung ist derzeit noch nicht bereit f\u00fcr Tests.\n
Promise-basierte APIs. Firefox unterst\u00fctzt diesen Typ von API bereits im Namensraum \u201ebrowser.*\u201c und wird ihn f\u00fcr die dritte Version des Manifests in den Namensraum \u201echrome.*\u201c \u00fcbertragen.\n
Das neue granulierte Berechtigungsanfragemodell \u2014 das Add-on kann nicht sofort auf allen Seiten aktiviert werden (die Berechtigung \u201eall_urls\u201c wurde entfernt) und wird nur im Kontext des aktiven Tabs funktionieren, d.h. der Benutzer muss die Funktionalit\u00e4t des Add-ons f\u00fcr jede Website best\u00e4tigen. Mozilla arbeitet daran, die Zugriffssteuerung zu verbessern, m\u00f6chte den Benutzern jedoch die M\u00f6glichkeit geben, selbst zu entscheiden, ob sie den Add-ons erlauben, mit verschiedenen Tabs zu interagieren.\n