Neue Chrome API könnte Adblocker aussperren – Entwickler wehren sich

Entwickler wurden in helle Aufregung versetzt, als Google ankündigte die Schnittstellen für Chrome-Erweiterungen zu verändern. Denn die ersten Pläne würden für uBlock Origin etwa das Aus im Browser bedeuten. Kritiker verweisen auf Googles Bestreben, wirtschaftliche Vorteile zu erlangen, weil neben dem eigenen Blocking – das Google Ads nicht blockiert – Erweiterungen nur bedingt funktionieren würden. Allerdings erklärt Google, dass noch keine Entscheidungen fix sind, die Veränderung bei der API-Struktur jedoch notwendig ist.

Weg von der webRequest API

Die webRequest API von Google Chrome erlaubt es Erweiterungen, wie etwa uBlock Origin, Netzwerkanfragen zu unterbrechen und entsprechend zu blockieren, zu modifizieren oder umzuleiten. Auf diesem System basieren demnach die gängigen Erweiterungen. Dass damit aber auch Sicherheitsrisiken einhergehen, weil genauso jede böswillige Erweiterung zur Manipulation von Netzwerkanfragen fähig ist, veranlasst Google zum Umdenken. Chrome-Sicherheitsmanager Justin Schuh unterstreicht das bei Twitter.

https://twitter.com/justinschuh/status/1088097104864530432

Ersetzen möchte man diese API durch die declarativeNetRequest API, die derzeit in der Betaphase ist. Dank dieser kann laut The Register Chrome selbst die Netzwerkanfragen einsehen und entscheiden, wie mit ihnen verfahren wird. Das Manifest V3 beschreibt diese Änderungen, die grundsätzlich zu mehr Sicherheit für die Nutzer führen sollen:

The new declarativeNetRequest API will be used as the primary content-blocking API in extensions, as it is more performant and offers better privacy guarantees to users.

Diese Umstellung käme jedoch vielen Erweiterungen im Bereich der Adblocker ungelegen, weil sie mehr oder minder auf die webRequest API angewiesen sind.

Die Kritik der Entwickler

Kritisiert wird an der Änderung zum einen, dass ein Filtersystem mit „nur“ 30.000 Elementen implementiert wird. Allerdings haben Adblocker meist Datenbanken mit an die 70.000 Einträge, die es zu blockieren gilt. Zum anderen wird bemängelt, dass etablierte Blocking-Dienste wie uBlock Origin oder Matrix mit der declarativeNetRequest API gar nicht mehr funktionieren könnten. Das gibt Raymond Hill in seinem Kommentar zum Manifest V3 an:

From the description of the declarativeNetRequest API[1], I understand that its purpose is to merely enforce Adblock Plus („ABP“)-compatible filtering capabilities[2]. 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).

Adblock Plus und Chromes Blocking wären Nutznießer

Adblock Plus hingegen würde, auch nach eigenen Angaben, weiterhin funktionsfähig bleiben. Dafür sorgen eigene Anpassungen an die neue API, die im Gange sind, wie Der Standard berichtet. Abgesehen davon würde natürlich auch Googles in Chrome implementierter Adblocker funktionieren. Dieser blockt aber bekanntlich keine Google-eigenen Ads.

Auch die Cliqz GmbH, Entwickler der Tracking-Erweiterung Ghostery, sieht in den Plänen Googles ein Problem. Geschäftsführer Marc Al-Hames erläutert:

Die Änderung im Chrome-Browser würde bedeuten, dass Google Werbeblocker und Datenschutztools, wie wir sie heute kennen, zerstört. Google tut so, als ob sie dies zugunsten der Privatsphäre und Browser-Performance machten, tatsächlich blieben den Nutzern aber nur sehr begrenzte Möglichkeiten, ihr Surfverhalten geheim zu halten, ihre Privatsphäre zu schützen und unerwünschte Inhalte zu blockieren. Niemand könnte mehr einen substanziellen Mehrwert gegenüber Googles eingebauter Technologie bieten, die bekanntlich ja keine Google-eigene Werbung blockiert. Egal ob Google dies nun tut, um sein Werbegeschäft zu schützen oder um allen anderen seine eigenen Regeln aufzuzwingen – am Ende wäre es ein weiterer eklatanter Fall von Missbrauch einer marktbeherrschenden Stellung.

Würden die Änderungen hin zu einer declarativeNetRequest API ohne Einschränkungen vonstatten gehen, erwägt das Unternehmen gar eine Kartellbeschwerde – und wähnt sich nicht allein.

Google relativiert und arbeitet weiter an der Umstellung

Um der Kritik der Entwickler entgegenzutreten, hat Googles Softwareentwickler Devlin Cronin jetzt auf die negative Wahrnehmung der API-Veränderungen reagiert. Dabei wird klar, dass noch keine konkreten Änderungen in Stein gemeißelt sind. Die webRequest API soll außerdem nicht komplett eingestellt werden, während das Ausmaß der Umwälzungen bei den Schnittstellen weiter zur Diskussion steht. Das Design der Pläne werde sich vermutlich noch ändern. Zudem sei es keineswegs Googles Ziel Adblocker aus dem Browser auszusperren:

Our goal is not to break extensions.  We are working with extension developers to strive to keep this breakage to a minimum, while still advancing the platform to enhance security, privacy, and performance for all users.

Feedback ist dem Team der Entwickler willkommen. Cronin betont, dass er die Bedenken zur declarativeNetRequest API nachvollziehen kann, da diese tatsächlich restriktiver und weniger flexibel als die webRequest API wäre. Nach Googles Ermessen jedoch zum Schutz der Nutzer.

Dass dieses Ziel Priorität hat, sollte nicht bestritten werden. Doch gleichsam ist es wichtig, dass diese Nutzer auch künftig noch die Möglichkeit haben Anti-Tracking Tools oder Adblocker einzusetzen, die ihre Privatsphäre schützen; und dabei nicht allein von Google Chromes Alternativen abhängig zu sein. Cliqz kritisiert, dass derlei Technologien auf KI-Basis bei der geplanten API nicht funktionieren würden. Es bleibt also zu hoffen, dass Google in der Entwicklung eine Balance zwischen Nutzersicherheit und Flexibilität für die Browsererweiterungen schafft. Andernfalls drohen vonseiten der Entwickler nicht nur Kritik, sondern womöglich auch rechtliche Schritte.