Entwickler von Chrome-Browsern Einstellung der Unterstützung für den Blockierungsmodus der webRequest-API, der es Ihnen ermöglicht, den empfangenen Inhalt im Handumdrehen zu ändern und aktiv in Add-Ons zum Blockieren von Werbung verwendet wird,
Schutz vor Malware, Phishing, Ausspionieren von Benutzeraktivitäten, Kindersicherung und Datenschutz.
Beweggründe von Google:
- API-Blockierungsmodus führt zu einem hohen Ressourcenverbrauch.
Bei Verwendung dieser API sendet der Browser zunächst alle in der Netzwerkanfrage enthaltenen Daten an das Add-on, das Add-on analysiert diese und sendet eine modifizierte Version zur weiteren Verarbeitung im Browser zurück oder erteilt Blockierungsanweisungen. In diesem Fall entstehen die Hauptverzögerungen nicht in der Phase der Verarbeitung des Datenverkehrs durch das Add-on, sondern aufgrund der Gemeinkosten für die Koordinierung der Ausführung des Add-ons. Insbesondere erfordern solche Manipulationen den Start eines separaten Prozesses zur Ergänzung sowie die Verwendung von IPC zur Interaktion mit diesem Prozess und Datenserialisierungsmechanismen; - Das Add-on kontrolliert den gesamten Datenverkehr vollständig auf einem niedrigen Niveau, was enorme Möglichkeiten für Missbrauch und Datenschutzverletzungen eröffnet. Laut Google-Statistik nutzten 42 % aller erkannten bösartigen Add-ons die webRequest-API. Es wird darauf hingewiesen, dass jeden Monat durchschnittlich 1800 Versuche, schädliche Add-ons im Chrome Web Store-Katalog zu platzieren, blockiert werden. Leider ist es uns aufgrund der Überprüfung nicht möglich, ausnahmslos alle bösartigen Add-ons abzufangen. Um den Schutz zu erhöhen, wurde daher beschlossen, Add-ons auf API-Ebene einzuschränken. Die Grundidee besteht darin, Add-Ons nicht Zugriff auf den gesamten Datenverkehr zu gewähren, sondern nur auf die Daten, die zur Implementierung der beabsichtigten Funktionalität erforderlich sind. Insbesondere ist es zur Sperrung von Inhalten nicht erforderlich, dem Add-on vollen Zugriff auf alle vertraulichen Nutzerdaten zu gewähren;
- Vorgeschlagene deklarative Ersatz-API übernimmt die gesamte Arbeit der leistungsstarken Inhaltsfilterung und erfordert lediglich Add-ons zum Laden der Filterregeln. Das Add-on kann den Datenverkehr nicht beeinträchtigen und die privaten Daten des Benutzers bleiben unverletzlich;
- Google hat viele Kommentare bezüglich der mangelnden Funktionalität der declarativeNetRequest-API berücksichtigt und die Begrenzung der Anzahl der Filterregeln von den ursprünglich vorgeschlagenen 30 pro Erweiterung auf ein globales Maximum von 150 erweitert und außerdem die Möglichkeit zur dynamischen Filterung hinzugefügt Regeln ändern und hinzufügen, HTTP-Header (Referer, Cookie, Set-Cookie) und Anforderungsparameter entfernen und ersetzen;
- Für Unternehmen ist es möglich, den blockierenden Betriebsmodus der webRequest-API zu verwenden, da die Richtlinie für die Verwendung von Add-Ons von einem Administrator festgelegt wird, der die Funktionen der Infrastruktur versteht und sich der Risiken bewusst ist. Beispielsweise kann die angegebene API in Unternehmen verwendet werden, um die Verkehrsströme der Mitarbeiter aufzuzeichnen und in interne Systeme zu integrieren;
- Das Ziel von Google besteht nicht darin, Werbeblocker-Add-ons zu untergraben oder zu unterdrücken, sondern die Entwicklung sichererer und leistungsfähigerer Werbeblocker zu ermöglichen.
- Die Zurückhaltung, den blockierenden Betriebsmodus der webRequest-API zusammen mit dem neuen declarativeNetRequest zu verlassen, erklärt sich aus dem Wunsch, den Zugriff von Add-ons auf vertrauliche Daten zu beschränken. Wenn Sie die webRequest-API unverändert lassen, verwenden die meisten Add-ons nicht das sicherere deklarative NetRequest, da sich die meisten Entwickler bei der Wahl zwischen Sicherheit und Funktionalität normalerweise für die Funktionalität entscheiden.
:
- Durchgeführt von Add-on-Entwicklern zeigen einen unbedeutenden Gesamteinfluss auf die Leistung von Werbeblocker-Add-Ons (während des Tests wurde die Leistung verschiedener Add-Ons verglichen, jedoch ohne Berücksichtigung des Overheads eines zusätzlichen Prozesses, der die Ausführung von Handlern im Blockierungsmodus von koordiniert die webRequest-API);
- Es ist nicht praktikabel, die Unterstützung einer API, die aktiv in Add-ons verwendet wird, vollständig einzustellen. Anstatt es zu entfernen, können Sie eine separate Berechtigung hinzufügen und die Angemessenheit seiner Verwendung in Add-Ons streng kontrollieren, was den Autoren vieler beliebter Add-Ons die völlige Überarbeitung ihrer Produkte ersparen und eine Einschränkung der Funktionalität vermeiden würde;
- Um die Gemeinkosten zu senken, können Sie die API nicht löschen, sondern auf Basis des Promise-Mechanismus neu erstellen, ähnlich der Implementierung von webRequest in Firefox;
- Die vorgeschlagene Alternative, declarativeNetRequest, deckt nicht alle Anforderungen von Add-on-Entwicklern an Werbeblockierung und Sicherheit/Datenschutz ab, da sie keine vollständige Kontrolle über Netzwerkanfragen bietet, die Verwendung benutzerdefinierter Filteralgorithmen nicht zulässt und dies nicht zulässt die Verwendung komplexer Regeln, die sich je nach Bedingungen überschneiden;
- Mit dem aktuellen Stand der declarativeNetRequest-API ist es unmöglich, die bestehende Funktionalität der uBlock Origin- und uMatrix-Add-ons unverändert wiederherzustellen, und macht außerdem die Weiterentwicklung eines NoScript-Ports für Chrome sinnlos;
- Bedenken hinsichtlich des Datenschutzes sind weit hergeholt, da der schreibgeschützte, nicht blockierende Modus der webRequest-API bestehen bleibt und es böswilligen Add-ons weiterhin ermöglicht, den gesamten Datenverkehr zu kontrollieren, aber keine Möglichkeit bietet, in ihn einzugreifen fliegen (Inhalt ändern, Werbung platzieren, Miner ausführen und den Inhalt der Eingabeformulare analysieren, die nach dem Laden der Seite verwendet werden können);
- Browser-Entwickler , и , die auf der Chromium-Engine basieren, beabsichtigen, die Unterstützung für den webRequest-Blockierungsmodus in ihren Produkten beizubehalten.
Source: opennet.ru