In Chrome hat die Testphase der dritten Version des Manifests begonnen, die mit uBlock Origin nicht kompatibel ist

Das Unternehmen Google hat die Testphase begonnen der dritten Version des Chrome-Manifests, die die Funktionalität zahlreiche Erweiterungen zur Blockierung unerwünschter Inhalte und zur Gewährleistung der Sicherheit beeinträchtigt. Die Unterstützung des neuen Manifests, das die Funktionen und Ressourcen definiert, die Erweiterungen bereitgestellt werden, wurde in experimentelle Builds integriert Chrome Canary.
Das neue Manifest wurde im Rahmen von Initiative Maßnahmen zur Verbesserung der Sicherheit, des Datenschutzes und der Leistung von Erweiterungen (das Hauptziel besteht darin, die Erstellung sicherer und leistungsstarker Erweiterungen zu erleichtern und die Möglichkeit der Erstellung unsicherer und langsamer Erweiterungen zu erschweren).

Das Manifest befindet sich derzeit in der frühen Alpha-Testphase, ist nicht endgültig und wurde hinzugefügt, um Entwicklern die Möglichkeit zu geben, zu experimentieren und ihre Erweiterungen anzupassen.
Die Aktivierung des neuen Manifests wird für das nächste Jahr erwartet. Der Zeitpunkt für das Ende der Unterstützung der zweiten Version des Manifests ist derzeit nicht festgelegt.
Um die Migration von Erweiterungen auf das neue Manifest zu erleichtern, wurde ein Überprüfungspunkt, erstellt, der Änderungen umfasst, auf die Entwickler von Erweiterungen achten sollten.

Wir erinnern daran, dass grundlegendes Missfallen einem neuen über das Manifest hängt mit dem Wegfall des unterstützenden Betriebsmodus der API webRequest zusammen, der auf einen schreibgeschützten Modus beschränkt wird. Ausnahmen werden nur für die Chrome-Version für Unternehmen (Chrome for Enterprise) gemacht, in der die Unterstützung der API webRequest erhalten bleibt. Mozilla hat sich entschieden, dem neuen Manifest nicht zu folgen und in Firefox die volle Nutzung der API webRequest beizubehalten.

Anstelle der API webRequest wird im neuen Manifest eine deklarative API zur Inhaltsfilterung vorgeschlagen declarativeNetRequest. Während das API webRequest es ermöglichte, eigene Handler anzuschließen, die vollständigen Zugriff auf Netzwerkanfragen hatten und den Datenverkehr in Echtzeit ändern konnten, bietet das neue API declarativeNetRequest Zugang zu einer integrierten Universal-Engine zur Filterung, die die Blocking-Regeln eigenständig verarbeitet, die Verwendung eigener Filteralgorithmen nicht zulässt und keine komplexen, sich gegenseitig überlappenden Regeln je nach Bedingungen ermöglicht.

Im neuen Manifest gibt es auch weitere Änderungen, die die Kompatibilität mit Erweiterungen beeinflussen. Dazu gehören:

• Der Übergang zur Ausführung von Service-Workern in Form von Hintergrundprozessen, was von den Entwicklern Änderungen am Code einiger Erweiterungen erfordert.
• Ein neues, granuliertes Berechtigungsmodell – die Erweiterung kann nicht sofort für alle Seiten aktiviert werden (die Berechtigung „all_urls“ wurde entfernt), sondern funktioniert nur im Kontext des aktiven Tabs, d.h. der Benutzer muss die Nutzung der Erweiterung für jede Website bestätigen.
• Änderung der Verarbeitung von Cross-Origin-Anfragen – gemäß dem neuen Manifest werden dieselben Berechtigungsbeschränkungen auf Skripte zur Verarbeitung von Inhalten angewendet wie auf die Hauptseite, in die diese Skripte eingebettet sind (zum Beispiel, wenn die Seite keinen Zugriff auf die API zur Standortbestimmung hat, erhält auch das Erweiterungsskript keinen Zugriff).
• Verbot der Ausführung von Code, der von externen Servern geladen wurde (es geht um Situationen, in denen die Erweiterung externen Code lädt und ausführt).

Quelle: opennet.ru