Google reagiert auf Bedenken hinsichtlich der Adblock-Blockierung durch Chromium

Im Januar schrieben wir von einer wachsenden Aufregung wegen Pläne von Google, die webRequest-API einzustellen und ersetzen Sie es durch eine neue deklarative NetRequest-API, die viel weniger leistungsfähig ist und die Anzahl der Regeln begrenzt, die Entwickler verwenden können, um Anzeigen herauszufiltern.

Damals sagte der Entwickler einer der besten Adbock-Apps, uBlock Origin, auf bugs.chromium.org:

Wenn diese (ziemlich begrenzte) deklarative NetRequest-API die einzige Möglichkeit für Inhaltsblocker ist, ihre Pflicht zu erfüllen, bedeutet dies im Wesentlichen, dass zwei Inhaltsblocker, die ich seit Jahren betreue, uBlock Origin („uBO“) und uMatrix, nicht mehr existieren können.

Jetzt a Google-Ingenieur, der an Chromium arbeitet, hat geantwortet auf Bedenken und hat einigen Zugeständnissen zugestimmt, obgleich nicht klar ist, ob diese weit genug gehen.

Google war nach wie vor entschlossen, den webRequest AP loszuwerden, da er eine Quelle für zunehmenden Missbrauch sei, hat sich jedoch bereit erklärt, die deklarative NetRequest-API auf folgende Weise zu verbessern:

• Dynamische Regelunterstützung: Wir sind uns einig, dass dies beim Erstellen ausgeklügelter Inhaltsblockierungserweiterungen wertvoll ist, und werden Unterstützung für deklarative Regeln hinzufügen, die zur Laufzeit der declarativeNetRequest-API hinzugefügt oder entfernt werden können.
• Erhöhte Regelsatzgröße: Wir werden das Regellimit vom Entwurfswert 30 anheben. Eine Obergrenze ist jedoch immer noch erforderlich, um die Leistung für die Benutzer sicherzustellen. Sperrlisten waren in der Regel „Push-only“, bei denen neue Regeln hinzugefügt, aber veraltete Regeln selten, wenn überhaupt, entfernt werden (externe Forschung hat gezeigt, dass 90 % der EasyList-Blockierungsregeln in üblichen Blockierungsszenarien keinen Vorteil brachten). Es ist problematisch, diese Liste unbegrenzt weiter wachsen zu lassen.
• Zusätzliche Aktionen und Bedingungen: Wir planen, Unterstützung für den Abgleich basierend auf weiteren Bedingungen, wie z. B. der Ressourcengröße, hinzuzufügen und Aktionen bereitzustellen, um Teile einer Anfrage zu ändern, anstatt sie nur zu blockieren, wie z. B. das Entfernen von Cookies. Wir untersuchen auch andere Bedingungen und Aktionen, die möglicherweise sinnvoll hinzugefügt werden können, wie z. B. den Abgleich basierend auf der Top-Level-Domain. (Ein zusätzlicher Hinweis: Während wir die Unterstützung für CSP-Modifikationen untersuchen, wurde das Hinzufügen eines CSP-Headers zum Deaktivieren von JavaScript häufig als Anwendungsfall erwähnt; dies ist bereits durch die Inhaltseinstellungen API. Wenn dies nicht ausreicht, teilen Sie uns bitte mit, warum.)

Google sagte, dass sie weiterhin mit Entwicklern zusammenarbeiten und die webRequest-API nicht entfernen würden, bevor der Ersatz fertig und ausgereift ist, und sagte:

Einmal mehr setzen wir uns dafür ein, Erweiterungen in Chrome zu unterstützen. Wir werden weiterhin mit Entwicklern zusammenarbeiten. Wir werden Manifest V3 erst starten, wenn es fertig ist, und es wird eine Migrationsphase geben, in der wir uns weiterhin mit Feedback und Problemen befassen können. Wir werden die Unterstützung für Manifest V2 erst entfernen, wenn wir von der Plattform überzeugt sind.

Viele bleiben skeptisch, aber das eigentliche Ziel von Google ist es, die Benutzererfahrung strenger zu kontrollieren, um Tracking und Anzeigenschaltung für Milliarden von Benutzern zu ermöglichen.

Glauben unsere Leser, dass Google seine zunehmende Kontrolle über die weltweiten Web-Rendering-Engines über Chromium nutzen wird, um ihr Anzeigengeschäft weiter anzukurbeln, oder gibt es genug Browser-Konkurrenz, um sie ehrlich zu halten? Lassen Sie es uns unten wissen.

Weitere Informationen zur Stelle und den Ansprechpartner in unserem Hause finden Sie hier: Das Register