![](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2015\/01\/Chrome.jpg\")
Vorsichtige Entwarnung: Google kommt den Entwicklern von Adblocker-Erweiterungen ein St\u00fcck weit entgegen und weitet die Zahl der zul\u00e4ssigen Regeln f\u00fcr Chrome-Erweiterungen (in Manifest V3) stark aus. Zudem erkl\u00e4rt Google, warum die neue Schnittstelle eingef\u00fchrt wird. <\/p>\n
<\/p>\n
Was die Entwickler der Erweiterungen besonders aufregte: Mit der Einf\u00fchrung der neuen API wollte Google die Anzahl der Regeln, mit denen Entwickler Anzeigen herausfiltern k\u00f6nnen, auf max. 30.000 begrenzen. Bisherige Adblocker nutzten ein Mehrfaches dieser Regeln, bei Dr. Windows finden sich Zahlen von 75.000 Eintr\u00e4gen f\u00fcr Easy-List und 175.000 f\u00fcr uBlock Origin. <\/p>\n F\u00fcr die Entwickler von Adblocker-Chrome Extensions bedeutet die neue API gravierende Umbauma\u00dfnahmen, was nicht so einfach werden d\u00fcrfte. Und durch die begrenzten Filterregeln gibt es weitere Einschr\u00e4nkungen. Was besonders \u00e4rgerlich war: Die alte webRequest-<\/em>Schnittstelle sollte in Zukunft nur noch zahlenden Enterprise-Kunden in Chromium-Browsern zur Verf\u00fcgung stehen. <\/p>\n Ich hatte den Sachverhalt im Blog-Beitrag Google verhindert Adblocking in Chromium-Engines<\/a> thematisiert. Google wollte diese Grenze nochmals \u00fcberdenken, hatte aber Anfang Juni 2019 in diesem Posting<\/a> vom Chrome-Entwicklerteam wohl nun das finale Statement zum Stand der Entscheidung f\u00fcr Manifest V3 ver\u00f6ffentlicht (auch wenn man weiter mit der Community diskutieren will). Dieser Sachstand war im Blog-Beitrag \u00c4rger wegen Googles \u00c4nderungen f\u00fcr Adblocker in Chrome<\/a> nochmals aufbereitet worden. <\/p>\n ZDnet.com berichtet in diesem Artikel<\/a> ebenfalls \u00fcber den oben skizzierten Sachverhalt. Neu f\u00fcr mich war, dass Google begr\u00fcndet, warum man die alte webRequest-<\/em>Schnittstelle kippt. Laut Google sei diese alte API eine Quelle des Missbrauchs. Gut 42% aller b\u00f6sartigen Erweiterungen, die das Unternehmen seit Januar 2018 entdeckt hat, verwenden diese alte Schnittstelle f\u00fcr 'sch\u00e4ndliche Zwecke'.<\/p>\n \"Mit Web Request sendet Chrome alle Daten in einer Netzwerkanfrage an die Listening Extension – einschlie\u00dflich aller sensiblen Daten, die in dieser Anfrage enthalten sind, wie pers\u00f6nliche Fotos oder E-Mails\", schreibt<\/a> Simeon Vincent, Developer Advocate for Chrome Extensions. \u2013 wo auch der obige Screenshot ver\u00f6ffentlicht wurde. <\/p>\n Das Datenschutzrisiko ist offensichtlich: \"Da alle Anforderungsdaten der Erweiterung ausgesetzt sind, ist es f\u00fcr einen b\u00f6swilligen Entwickler sehr einfach, diesen Zugriff auf die Anmeldeinformationen, Konten oder pers\u00f6nlichen Daten eines Benutzers zu missbrauchen\", schreibt Vincent.<\/p>\n Mit der deklarativen Net Request API wird das alles unterbunden. Anstatt dass der Chrome-Browser alle Informationen \u00fcber eine Anfrage zum Zeitpunkt der Anfrage an die Listening Extensions sendet, wird das Ganze umgedreht. Die Chrome-Extensions m\u00fcssen im Browser Regeln registrieren, die dem Chrome mitteilen, was zu tun ist, wenn bestimmte Arten von Anfragen von Webseiten empfangen werden. Dieser Ansatz hat, laut Google, sowohl f\u00fcr die Benutzersicherheit und den Datenschutz als auch f\u00fcr die Leistung des Browsers Vorteile. Mit einem deklarativen Ansatz muss Chrome keine sensiblen Daten f\u00fcr die Erweiterung bereitstellen. Der Browser kann die von der Erweiterung angeforderte Aktion ausf\u00fchren, ohne ihr alle mit der Netzwerkanforderung verbundenen Daten zu senden, da die Erweiterung bereits die Bedingungen angibt, unter denen verschiedene Aktionen durchgef\u00fchrt werden. Auf diese Weise kann die Erweiterung eine Inhaltsblockierung durchf\u00fchren, ohne dass auf alle personenbezogenen Daten eines Benutzers zugegriffen werden muss.<\/p>\n Google schreibt, dass dies erhebliche Auswirkungen auf die Leistung habe. Vor allem ist ein persistenter, langlebiger Prozess nicht mehr notwendig, da Regeln registriert werden, bevor Anfragen gestellt werden, anstatt sie zur Laufzeit verarbeiten zu m\u00fcssen. Dies reduziert auch die Kosten f\u00fcr die Serialisierung aller Anforderungsdaten und das Herunterfahren der prozess\u00fcbergreifenden Nachrichten an die Lernerweiterungen. Diese Leistungssteigerungen werden Erweiterungen auf ressourcenbeschr\u00e4nkten Plattformen deutlich rentabler machen, so Google.<\/p>\n Dann schreibt Google, dass die Umstellung auf Declarative Net Request und das gesamte Manifest V3 noch sehr stark in Design und Entwicklung sind. Man signalisiert, auf das Feedback der Community zu h\u00f6ren. Als erste Ma\u00dfnahme planen wir derzeit, die Regelgrenze von maximal 30.000 Regeln pro Erweiterung auf ein globales Maximum von 150.000 zu erweitern. Das ist ja schon mal was. <\/p>\n \u00c4hnliche Artikel:<\/strong> Vorsichtige Entwarnung: Google kommt den Entwicklern von Adblocker-Erweiterungen ein St\u00fcck weit entgegen und weitet die Zahl der zul\u00e4ssigen Regeln f\u00fcr Chrome-Erweiterungen (in Manifest V3) stark aus. Zudem erkl\u00e4rt Google, warum die neue Schnittstelle eingef\u00fchrt wird.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1356],"tags":[3208,984],"class_list":["post-219199","post","type-post","status-publish","format-standard","hentry","category-google-chrome-internet","tag-adblocker","tag-google-chrome"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/219199","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=219199"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/219199\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=219199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=219199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=219199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Im Januar 2019 erkl\u00e4rte Google in Chromium die webRequest-<\/em>Schnittstelle, die von Adblockern wie uBlock Origin verwendet wird, als veraltet. Stattdessen f\u00fchrt Google die neue deklarativeNetRequest<\/em>-API ein. Diese neue im Manifest V3 beschriebene Schnittstelle ist aber viel weniger leistungsf\u00e4hig als die alte API. Zudem \u00fcbernimmt die neue API wieder die Kontrolle \u00fcber die Filterung (die Adblocker-Extension-Entwickler bisher selbst realisierten). In der neuen API m\u00fcssen Chrome-Erweiterungen Filterregeln \u00fcber den Browser umsetzen lassen. <\/p>\n
Google begr\u00fcndet die \u00c4nderungen<\/h2>\n<\/p>\n
(webRequest-<\/em>Schnittstelle, Quelle: Google)<\/p>\nMehr Sicherheit und Leistung<\/h2>\n
<\/b><\/p>\n
(Chrome Net Request API, Quelle: Chrome) <\/p>\nGoogle verspricht auf Adblocker-Entwickler zuzugehen<\/h2>\n
Google verhindert Adblocking in Chromium-Engines<\/a>
\u00c4rger wegen Googles \u00c4nderungen f\u00fcr Adblocker in Chrome<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
![\"Chrome](\"https:\/\/lh5.googleusercontent.com\/EPYm5B9rvvHuJ4qWn9Q2wZT4BOk0S0ZJLCToDU4eT4XE4-gDZgzlrNtiqielHEoQgbFTymhO1nwmc4EH00KPV5BeqUBN5UPA8Jdm8JmrdvRbSSXB3WaCnx8-eYy6eQC4nUsUQaKe\" "\\"Chrome")
![\"Chrome](\"https:\/\/lh6.googleusercontent.com\/BGH7hRuzkdSJpU3M9PEfn0Ew3uiLRahCY54NGbbpjnHhhtiRLuSTksXw2sFAq5XnnxwULdZqUPza9BF625JE9UdqCgBYQLEPbJ9FHgodPvEsF8UR4fryW9tDfMixJNt23zp6Vf0b\" "\\"Chrome")