Google Chrome: Neue Schnittstelle könnte das Aus für uBlock Origin und andere Inhalte-Blocker bedeuten

Der Browser ist für viele Nutzer das Herzstück der digitalen Welt. Er zeigt Webseiten an – aber oftmals auch Werbung. Ad-Blocker sind die Lösung für Nutzer, die sich leicht ablenken lassen oder Angst davor haben, dass sie über Werbung mit Malware infiziert werden. Ich selbst nutzte seit der großen Ad-Blocker-Diskussion vor ein paar Jahren keinerlei Blocking-Erweiterungen mehr – bisher ging das gut und verlief ohne Schäden.

Jedenfalls sitzen diese Ad-Blocker in der Regel als Erweiterung in Google Chrome. Hier droht nun eine Änderung, die die Funktionsweise mancher Inhalte-Blocker unmöglich macht. Das erklärt Raymond Hill, seines Zeichens Entwickler von uBlock Origin, einer sehr beliebten Erweiterung für das Blockieren von Inhalten.

Demnach wird in Manifest V3 die webRequest API für das Blockieren von Inhalten eingeschränkt, dafür steht dann die declarativeNetRequest API zur Verfügung. Allerdings beschränkt sich die Funktionsweise der Schnittstelle auf eine solche, wie sie auch von AdBlock Plus eingesetzt wird. Dabei handelt es sich um eine sehr einfache Filterung, die von anderen Ad-Blockern ist da komplexer und lässt sich nicht über die neue Schnittstelle realisieren.

Noch ist die Änderung nicht in Stein gemeißelt, sie ist Teil der Vorschläge für Manifest V3. Wenn das aber einmal abgenickt ist, dann gibt es so schnell wohl kein zurück mehr. Blockieren ließen sich dann nur noch bestimmte Inhalte, die auch auf bestimmte Weise auftreten müssen. Erweiterte Algorithmen zur Erkennung von unerwünschten Inhalten wären so nicht mehr möglich:

From the description of the declarativeNetRequest API, I understand that its purpose is to merely enforce Adblock Plus („ABP“)-compatible filtering capabilities. It shares the same basic filtering syntax: double-pipe to anchor to hostname, single pipe to anchor to start or end of URL, caret as a special placeholder, and so on. The described matching algorithm is exactly that of a ABP-like filtering engine.

If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin („uBO“) and uMatrix, can no longer exist.

Beside causing uBO and uMatrix to no longer be able to exist, it’s really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone).

Key portions of uBlock Origin and all of uMatrix use a different matching algorithm than that of the declarativeNetRequest API. Block/allow rules are enforced according to their *specificity*, whereas block/allow rules can override each others with no limit. This cannot be translated into a declarativeNetRequest API (assuming a 30,000 entries limit would not be a crippling limitation in itself).

There are other features (which I understand are appreciated by many users) which can’t be implemented with the declarativeNetRequest API, for examples, the blocking of media element which are larger than a set size, the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc. — and all of these can be set to override a less specific setting, i.e. one could choose to globally block large media elements, but allow them on a few specific sites, and so on still be able to override these rules with ever more specific rules.

Extensions act on behalf of users, they add capabilities to a *user agent*, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render.

With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical „user agent“ will still be a proper category to classify Chromium.

Sollte das nun so festgelegt werden, wie es vorgeschlagen wurde, dürfte das für einige Inhalte-Blocker das Aus in Chrome bedeuten. Begründet werden die Änderungen übrigens mit Sicherheit, da es immer wieder Erweiterungen gibt, die Dinge auslesen, die sich nicht sollen. Ob das nun aber der richtige Weg ist?