{"id":37772,"date":"2019-10-31T22:19:39","date_gmt":"2019-10-31T19:19:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/mozilla-ne-stanet-perenosit-vse-ogranicheniya-api-webextensions-iz-novogo-manifesta-chrome\/"},"modified":"2019-10-31T22:19:39","modified_gmt":"2019-10-31T19:19:39","slug":"mozilla-ne-stanet-perenosit-vse-ogranicheniya-api-webextensions-iz-novogo-manifesta-chrome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/mozilla-ne-stanet-perenosit-vse-ogranicheniya-api-webextensions-iz-novogo-manifesta-chrome","title":{"rendered":"Mozilla wird nicht alle API-WebExtensions-Beschr\u00e4nkungen aus dem neuen Manifest von Chrome \u00fcbernehmen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das Unternehmen Mozilla k\u00fcndigte an<\/a><\/noindex>, dass trotz der Verwendung des WebExtensions-API-Erweiterungssystems in Firefox die Entwickler nicht die Absicht haben, der zuk\u00fcnftigen dritten Auflage des Chrome-Erweiterungsmanifests vollst\u00e4ndig zu folgen. Insbesondere wird in Firefox die Unterst\u00fctzung des blockierenden Modus des APIs fortgef\u00fchrt webRequest<\/a><\/noindex>, der es erm\u00f6glicht, den empfangenen Inhalt in Echtzeit zu \u00e4ndern und bei Ad-Blockern und Content-Filter-Systemen gefragt ist. <\/p>\n

Die Hauptidee des Wechsels zu den API-WebExtensions war die Vereinheitlichung der Technologie zur Entwicklung von Erweiterungen f\u00fcr Firefox und Chrome, weshalb in der aktuellen Form in Firefox nahezu 100 % Kompatibilit\u00e4t mit der aktuellen zweiten Auflage des Chrome-Manifests gew\u00e4hrleistet ist. Das Manifest definiert die Liste der M\u00f6glichkeiten und Ressourcen, die den Erweiterungen zur Verf\u00fcgung stehen. Aufgrund der im dritten Manifestvorschlag vorgeschlagenen einschr\u00e4nkenden Ma\u00dfnahmen, die von den Entwicklern als negativ wahrgenommen werden, wird Mozilla von der Praxis abweichen, dem Manifest vollst\u00e4ndig zu folgen, und wird keine \u00c4nderungen in Firefox \u00fcbernehmen, die die Kompatibilit\u00e4t mit den Erweiterungen beeintr\u00e4chtigen.<\/p>\n

Wir erinnern daran, dass trotz<\/a><\/noindex> auf<\/a><\/noindex> Ressourcen) abgeschlossen ist, l\u00f6sen wir<\/a><\/noindex> Einwendungen<\/a><\/noindex>, plant Google die Unterst\u00fctzung des blockierenden Modus des APIs webRequest in Chrome einzustellen und es auf einen Nur-Lese-Modus zu beschr\u00e4nken und einen neuen deklarativen API zur Inhaltsfilterung anzubieten 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

Mozilla pr\u00fcft auch die Machbarkeit, einige andere \u00c4nderungen aus der dritten Version des Chrome-Manifests, die die Kompatibilit\u00e4t mit Erweiterungen beeintr\u00e4chtigen, nach Firefox zu \u00fcbertragen:<\/p>\n