Simeon Vincent, der im Chrome-Team für die Interaktion mit Erweiterungsentwicklern verantwortlich ist (hat die Position des Extensions Developer Advocate inne), Googles aktuelle Position zur dritten Ausgabe des Chrome-Manifests, viele Add-ons, um unangemessene Inhalte zu blockieren und die Sicherheit zu gewährleisten. Das Unternehmen beabsichtigt nicht, seinen ursprünglichen Plan aufzugeben, den Blockierungsmodus der webRequest-API nicht mehr zu unterstützen, der es Ihnen ermöglicht, die empfangenen Inhalte im Handumdrehen zu ändern. Eine Ausnahme wird nur für die Enterprise-Edition von Chrome gemacht (), wobei die Unterstützung für die webRequest-API wie bisher erhalten bleibt.
Für normale Chrome-API-Benutzer wird auf den schreibgeschützten Modus beschränkt. Es wurde eine deklarative API vorgeschlagen, um die webRequest-API für die Inhaltsfilterung zu ersetzen , das nur einen begrenzten Teil der Funktionen moderner Werbeblocker abdeckt. Im Wesentlichen wird anstelle proprietärer Handler, die vollen Zugriff auf Netzwerkanfragen haben, eine vorgefertigte, universelle integrierte Filter-Engine angeboten, die Blockierungsregeln selbst verarbeitet. Mit der declarativeNetRequest-API können Sie beispielsweise keine eigenen Filteralgorithmen verwenden und keine komplexen Regeln erstellen, die sich je nach Bedingungen überschneiden.
Die Entwickler von Werbeblocker-Add-ons haben gemeinsam vorbereitet , in dem die Mängel der declarativeNetRequest-API aufgeführt sind. Google stimmte vielen Kommentaren zu und fügte die declarativeNetRequest-API hinzu. Insbesondere wurde die Unterstützung für das dynamische Ändern und Hinzufügen von Regeln hinzugefügt, und es ist möglich, HTTP-Header zu löschen, jedoch nur diejenigen in der Whitelist (Referer, Cookie, Set-Cookie). Wir planen, Unterstützung für das Hinzufügen und Ersetzen von HTTP-Headern (z. B. für Set-Cookie-Ersetzung und CSP-Anweisungen) sowie die Möglichkeit zum Löschen und Ersetzen von Anforderungsparametern zu implementieren.
Eine vorläufige Version der dritten Version des Manifests, die die Liste der für Chrome-Add-ons bereitgestellten Funktionen und Ressourcen definiert, soll in den kommenden Monaten für Tests in experimentellen Builds von Chrome Canary verwendet werden.
Gleichzeitig bleibt die Motivation für das Verbot von Änderungen an empfangenen Inhalten über die webRequest-API unklar. Behauptungen, dass sich der Blockierungsmodus der webRequest-API negativ auf die Leistung auswirkt, weil der Browser darauf wartet, dass der Add-on-Handler seine Arbeit abschließt, bevor er die Seite rendert, halten der Kritik nicht stand. Zuvor durchgeführt Die Leistung von Werbeblocker-Add-ons hat gezeigt, dass die Verzögerung, die sie verursachen, vernachlässigbar ist. Im Durchschnitt verlangsamt der Einsatz eines Blockers die Ausführung einer Anfrage nur um einen Bruchteil von Millisekunden, was im Vergleich zum Gesamthintergrund vernachlässigbar ist.
Auch das zweite Argument, das sich auf den Wunsch bezieht, Benutzer vor dem unkontrollierten Zugriff von Add-ons auf Inhalte zu schützen, erscheint nicht überzeugend, da statt der Entfernung altbewährter und weit verbreiteter Funktionen in legitimen Add-ons eine neue hinzugefügt werden konnte Art der Berechtigung und geben dem Benutzer die endgültige Wahl, ob er ein Add-on mit vollem Zugriff auf Netzwerkanfragen installieren möchte oder nicht. Darüber hinaus hat Google die Unterstützung für die Verwendung der webRequest-API im schreibgeschützten Modus beibehalten, sodass eine vollständige Überwachung des Datenverkehrs ohne Eingriffe auf niedriger Ebene möglich ist.
Add-ons können den Inhalt geladener Webseiten über andere APIs ändern (bösartige Add-ons können beispielsweise weiterhin ihre Werbung ausliefern, Miner starten und den Inhalt von Eingabeformularen analysieren).
Raymond Hill, Autor der Systeme uBlock Origin und uMatrix zum Blockieren unerwünschter Inhalte, ist ziemlich streng Antwort eines Google-Vertreters und deutete auf Demagogie und Spiele hinter den Kulissen hin, bei denen Google unter dem Deckmantel einer guten Gelegenheit versucht, seine Geschäftsinteressen im Bereich der Internetwerbung voranzutreiben, die Kontrolle über seine Filtermechanismen zu erlangen und sich zu rechtfertigen diese Aktionen in den Augen der breiten Öffentlichkeit.
Er erhielt nie überzeugende Argumente für die Notwendigkeit, die bei Add-on-Entwicklern weit verbreitete und beliebte API zu stoppen. Laut Raymond ist der Leistungsabfall kein Argument, da Seiten aufgrund ihrer Aufblähung langsam geladen werden und nicht aufgrund der Verwendung des webRequest-Blockierungsmodus in korrekt implementierten Add-Ons. Wenn Google wirklich Wert auf Leistung gelegt hätte, hätten sie webRequest basierend auf dem Mechanismus neu gestaltet , analog zu webRequest in Firefox.
Laut Raymond besteht die Strategie von Google darin, das optimale Gleichgewicht zwischen der Erweiterung der Chrome-Nutzerbasis und dem durch den Einsatz von Inhaltsblockern verursachten Geschäftsschaden zu ermitteln. In der ersten Phase der Chrome-Erweiterung musste Google Werbeblocker als eines der beliebtesten Add-ons bei den Nutzern in Kauf nehmen. Doch nachdem Chrome die Vorherrschaft erlangt hatte, versuchte das Unternehmen, durch Werbung den Ausschlag zu seinen Gunsten zu geben und die Kontrolle über die Blockierung zu erlangen um Funktionen zum Blockieren unangemessener Werbung in Chrome zu integrieren. Die webRequest-API verfehlt diesen Zweck, da die Kontrolle über die Inhaltsblockierung derzeit in den Händen von Werbeblocker-Drittentwicklern liegt.
Source: opennet.ru