Chrome: Google nennt weitere Details zum künftigen Umgang mit Content-Blockern

• Kevin Kozuszek
• 30. Mai 2019
• • teilen

Bereits im vergangenen Januar kündigte Google das neue Manifest V3 für Chrome-Erweiterungen an und sorgte damit vor allem bei den Entwicklern von Content-Blockern gleich mal für ein richtiges Erdbeben. Hintergrund des Protests war vor allem der geplante Rauswurf der webRequests API, die von den meisten Erweiterungen wie uBlock Origin verwendet wird und ihnen weitreichende Möglichkeiten zum Blockieren bietet. Mit der declarativeNetRequests API übernimmt dagegen Chrome wieder die Kontrolle und die Erweiterungen müssen entsprechende Filterregeln über den Browser umsetzen. Gleichzeitig wurde die Zahl der Regeln auch noch auf maximal 30.000 Stück begrenzt.

Mittlerweile sind einige Monate ins Land gezogen und Google hatte versprochen, das Ganze nochmal zu überarbeiten. Die Ergebnisse hat Simeon Vincent vom Chrome-Entwicklerteam nun veröffentlicht und für den normalen Endnutzer sind diese ziemlich ernüchternd. Die webRequests API bleibt zwar erhalten, die Möglichkeit zum Blockieren von Inhalten wird künftig aber nur noch zahlenden Enterprise-Kunden zur Verfügung stehen. Im Gegenzug wird die declarativeNetRequests API etwas ausgebaut und kennt neben statischen nun auch dynamische Filterregeln. Wie an den Kommentaren unter dem Posting deutlich wird, hat sich an den Begrenzungen aktuell noch nicht viel geändert (30.000 statische und 5.000 dynamische Regeln im Maximum). Zum Vergleich: Die EasyList bringt es auf mindestens 75.000 Einträge und uBlock Origin hält bei mir in der Standardkonfiguration sogar fast 170.000 Einträge vor.

Letztlich bleibt es dabei, dass die geplanten Änderungen, die bis Jahresende umgesetzt werden sollen, bisherige Erweiterungen wie uBlock Origin zumindest in Chrome in ihrer derzeitigen Form unbrauchbar machen werden, sofern Google nicht noch weiter nachbessert. Nun ist der Einsatz von Adblockern immer ein Teufelskreis und man muss darüber diskutieren dürfen, wann und ob ein solcher Einsatz in Ordnung ist, aber in erster Linie fallen hierunter auch Erweiterungen, die Tracking unterbinden und die Sicherheit erhöhen (uBlock Origin blockiert zum Beispiel eine große Zahl an Malware-Domains). Unter anderem deswegen haben sich auch Entwickler wie die der Electronic Frontier Foundation, die unter anderem HTTPS Everywhere und den Privacy Badger entwickeln, gegen die Änderungen ausgesprochen. Gebracht hat es letztlich nichts.

Das eigentliche Problem ist aber ein Interessenkonflikt, der mit den Änderungen einher gehen wird. Mit Googles Quasi-Monopol im Bereich des Anzeigenmarktes und bei den Webbrowsern kollidieren zwei marktbeherrschende Stellungen mit Entwicklungen, die innerhalb von Chrome über die vergangenen Monate erfolgt sind. Mit dem „Bad Ads Blocker“ verfügt Chrome nämlich schon lange über einen eigenen Werbeblocker, dessen Basis aus der Arbeit in der Coalition for Better Ads hervorgegangen ist, auf den ich als Nutzer aber in keinster Weise Einfluss nehmen kann. Möchte ich eine Seite explizit auf eine Whitelist setzen, um sie zu unterstützen, geht das nicht. Google entscheidet also, was ich sehe und was nicht, ob und wie viele Anzeigen eine Seite anzeigen kann oder nicht. Wichtige andere Themen wie der Schutz vor Malvertising oder einem besseren Tracking-Schutz (an dem Google sowieso kaum bis gar kein Interesse hat) sind da noch gar nicht mit drin. Hinzu kommen Seiten, die Adblocker erkennen und mich erst weiter surfen lassen, wenn ich ein Abo abschließe (was ziemlich teuer wird bei vielen Seiten gleichzeitig) oder den Blocker deaktiviere. Mit dem „Bad Ads Blocker“ kann ich Letzteres vergessen.

Nun könnte man anmerken, dass man diese Funktionen einfach aus dem Browser ausgliedert und auf das Hardwarelevel bzw. ins lokale Netzwerk verlagert. Allerdings könnte mit DNS-over-HTTPS ein kommender Webstandard zur DNS-Verschlüsselung solche Bemühungen ins Leere laufen lassen, sofern ihr zum Beispiel einen PiHole als Ersatz betreibt. Eine entsprechende Diskussion gibt es immer noch bei Mozilla, da die Browserentwickler die entsprechenden DNS-Server nach dem aktuellen Entwurf fest in den Browser eincodieren müssen. Mozilla hat sich damals für Cloudflare entschieden, aber weitere Anbieter in Aussicht gestellt. Dass Google seinen eigenen Public DNS für Chrome wählen wird, dürfte klar sein. Das Endergebnis ist aber das Gleiche: Dem Browser wird es dann egal sein, welche DNS-Einstellungen ihr im Netzwerk oder in Windows getroffen habt, weil er immer zielsicher den voreingestellten DNS-Server ansteuern wird. Entsprechend fällt diese Alternative also (weitgehend) flach, sobald es entsprechend integriert wurde.

Die gute Nachricht ist aber, dass sich die Implementierung direkt in Chrome abspielen wird und die eigentlich Chromium-Basis – nach derzeitigem Stand – außenvor ist. Was also Microsoft Edge, Opera, Vivaldi und andere Derivate umsetzen, steht auf einem anderen Blatt. Gewisse Kollateralschäden wird es aber trotzdem geben, weil die meisten Chromium-Derivate keinen eigenen Store betreiben und wie Chrome auf den Chrome Web Store setzen. Gewisse Vorteile bekommen dadurch vor allem Microsoft und Opera in die Hände, die zwar mit gewissem Aufwand auch den CWS unterstützen, gleichzeitig aber auch eigene Stores für die Erweiterungen betreiben. Ob sich das aber auch in den Marktanteilen widerspiegeln wird, wird sich zeigen müssen.

• Quelle: GoogleWatchBlog
• Via: 9to5Google

• Themen:

• News
• Software

Über den Autor

Kevin Kozuszek

Seit 1999 bin ich Microsoft eng verbunden und habe in diesem Ökosystem meine digitale Heimat gefunden. Bei Dr. Windows halte ich euch seit November 2016 über alle Neuigkeiten auf dem Laufenden, die Microsoft bei seinen Open Source-Projekten und den Entwicklerthemen zu berichten hat. Beiträge über Mozilla, Europas Digitalwirtschaft und inklusive Informatik runden meinen Bereich ab.