{"id":52212,"date":"2019-11-03T00:00:00","date_gmt":"2019-11-02T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/v-chrome-nachalos-testirovanie-tretej-redaktsii-manifesta-nesovmestimoj-s-ublock-origin"},"modified":"2020-02-18T13:59:53","modified_gmt":"2020-02-18T10:59:53","slug":"v-chrome-nachalos-testirovanie-tretej-redaktsii-manifesta-nesovmestimoj-s-ublock-origin","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/v-chrome-nachalos-testirovanie-tretej-redaktsii-manifesta-nesovmestimoj-s-ublock-origin","title":{"rendered":"In Chrome hat die Testphase der dritten Version des Manifests begonnen, die mit uBlock Origin nicht kompatibel ist","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das Unternehmen Google hat die Testphase begonnen<\/a><\/noindex> der dritten Version des Chrome-Manifests, die<\/a><\/noindex> die Funktionalit\u00e4t<\/a><\/noindex> zahlreiche Erweiterungen zur Blockierung unerw\u00fcnschter Inhalte und zur Gew\u00e4hrleistung der Sicherheit beeintr\u00e4chtigt. Die Unterst\u00fctzung des neuen Manifests, das die Funktionen und Ressourcen definiert, die Erweiterungen bereitgestellt werden, wurde in experimentelle Builds integriert Chrome Canary<\/a><\/noindex>.
\nDas neue Manifest wurde im Rahmen von Initiative<\/a><\/noindex> Ma\u00dfnahmen 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\u00f6glichkeit der Erstellung unsicherer und langsamer Erweiterungen zu erschweren).<\/p>\n

Das Manifest befindet sich derzeit in der fr\u00fchen Alpha-Testphase, ist nicht endg\u00fcltig und wurde hinzugef\u00fcgt, um Entwicklern die M\u00f6glichkeit zu geben, zu experimentieren und ihre Erweiterungen anzupassen.
\nDie Aktivierung des neuen Manifests wird f\u00fcr das n\u00e4chste Jahr erwartet. Der Zeitpunkt f\u00fcr das Ende der Unterst\u00fctzung der zweiten Version des Manifests ist derzeit nicht festgelegt.
\n Um die Migration von Erweiterungen auf das neue Manifest zu erleichtern, wurde ein \u00dcberpr\u00fcfungspunkt<\/a><\/noindex>, erstellt, der \u00c4nderungen umfasst, auf die Entwickler von Erweiterungen achten sollten.<\/p>\n

Wir erinnern daran, dass grundlegendes<\/a><\/noindex> Missfallen<\/a><\/noindex> einem neuen<\/a><\/noindex> \u00fcber das Manifest<\/a><\/noindex> h\u00e4ngt mit dem Wegfall des unterst\u00fctzenden Betriebsmodus der API webRequest zusammen, der auf einen schreibgesch\u00fctzten Modus beschr\u00e4nkt wird. Ausnahmen werden nur f\u00fcr die Chrome-Version f\u00fcr Unternehmen (Chrome for Enterprise) gemacht, in der die Unterst\u00fctzung 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.<\/p>\n

Anstelle der API webRequest wird im neuen Manifest eine deklarative API zur Inhaltsfilterung vorgeschlagen declarativeNetRequest<\/a><\/noindex>. W\u00e4hrend das API webRequest es erm\u00f6glichte, eigene Handler anzuschlie\u00dfen, die vollst\u00e4ndigen Zugriff auf Netzwerkanfragen hatten und den Datenverkehr in Echtzeit \u00e4ndern konnten, bietet das neue API declarativeNetRequest Zugang zu einer integrierten Universal-Engine zur Filterung, die die Blocking-Regeln eigenst\u00e4ndig verarbeitet, die Verwendung eigener Filteralgorithmen nicht zul\u00e4sst und keine komplexen, sich gegenseitig \u00fcberlappenden Regeln je nach Bedingungen erm\u00f6glicht. <\/p>\n

Im neuen Manifest gibt es auch weitere \u00c4nderungen, die die Kompatibilit\u00e4t mit Erweiterungen beeinflussen. Dazu geh\u00f6ren:<\/p>\n