Das kommende Manifest V3 für Google Chrome-Erweiterungen wird die Funktionsweise von Werbeblockern in Chrome ändern. Ist das der richtige Weg für Werbeblocker und Google?
Google Chrome ist derzeit der beliebteste plattformübergreifende Webbrowser auf dem Markt. beansprucht 62,7 % des weltweiten Browser-Nutzungsanteils bis Mai 2019, wobei Apples Safari mit 15,89 % den zweiten Platz belegte und Mozillas Firefox 5,07 % erreichte. Aufgrund seines Löwenanteils wirken sich die kleinsten Änderungen, die Google Chrome an seiner Plattform vornimmt, am Ende auf Millionen von Nutzern auf der ganzen Welt aus. Als Google also die nächste Version des Erweiterungsmanifests in Form von Manifest V3 für Google Chrome Extensions ankündigte, wussten wir, dass wir es wussten Wir standen vor einigen großen Veränderungen, insbesondere als bekannt wurde, dass Google eine Content-Blocker-API in Chrome einbaute selbst.
Was ist Manifest V3?
Wenn Sie ein aktiver Chrome-Benutzer sind, verwenden Sie zweifellos einige Erweiterungen. Erweiterungen sind kleine Softwareprogramme, die das Surferlebnis mithilfe von anpassen
APIs, die der Browser bereitstelltDadurch können Benutzer Funktionen und Verhalten an ihre individuellen Bedürfnisse und Vorlieben anpassen. Diese Erweiterungen werden hauptsächlich über die verteilt Chrome-Webstore, das mehr als 180.000 Nebenstellen beherbergt.Seit Ende letzten JahresGoogle hat an „Manifest V3“ gearbeitet, einer Reihe vorgeschlagener Änderungen an der Chrome Extensions-Plattform, die als „Breaking Changes“ eingestuft werden können. Als die Öffentliches Diskussionsdokument für Manifest V3 besagt, dass die Erweiterungsmanifestversion ein Mechanismus zur Beschränkung bestimmter Funktionen auf eine bestimmte Klasse von Erweiterungen ist. Diese Einschränkungen können entweder in Form einer Mindestversion oder einer Maximalversion vorliegen. Durch die Beschränkung auf eine Mindestversion sind neuere APIs oder Funktionen nur für neuere Erweiterungen verfügbar während die Beschränkung auf eine maximale Manifestversion die schrittweise Erweiterung älterer APIs oder Funktionen ermöglicht veraltet.
Einfacher ausgedrückt ermöglicht eine neue Manifestversion Chrome, APIs und Funktionen auf diese neue Manifestversion zu beschränken um Erweiterungsentwickler zu zwingen, von bestimmten älteren APIs abzuweichen, da diese negative Auswirkungen auf den Benutzer haben Erfahrung. Die Implementierung einer Erweiterung in Manifest V3 sollte theoretisch stärkere Garantien im Hinblick auf Sicherheit, Datenschutz und Leistung bieten.
Während in Manifest V3 eine Vielzahl von Änderungen beschrieben sind, bezieht sich die umstrittenste Änderung auf die Entscheidung von Google, die in der bestehenden Version vorhandenen Blockierungsfunktionen einzuschränken chrome.webRequest API (und konzentrieren Sie die API auf Beobachtung statt auf Blockierung) und präsentieren Sie diese Blockierungsfähigkeiten dann durch eine neue chrome.declarativeNetRequest API. Diese besondere Änderung hat entzündete die Gemeinschaft da es letztlich auf den Werbeblocker-Mechanismus der berühmten Werbeblocker-Erweiterung abzielt, uBlock Originund wirkt sich direkt auf die über 10 Millionen Benutzer aus.
Bevor wir uns mit diesem Problem befassen, schauen wir uns an, wie das funktioniert webRequest API ist vergleichbar mit declarativeNetRequest API.
Web Request API und Declarative Net Request API
Das Geschenk
Die offizielle Beschreibung von Web Request beschreibt die API wie folgt:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Mit Web Request sendet Chrome alle die Daten in einer Netzwerkanforderung an die darauf wartende Nebenstelle. Die Erweiterung hat dann die Möglichkeit, die Anfrage auszuwerten und Chrome anzuweisen, was mit der Anfrage zu tun ist: sie zulassen, blockieren oder mit einigen Änderungen senden.
Verfolgen Sie die Abfolge der Ereignisse, um zu verstehen, was passiert, wenn Erweiterungen die Web Request API verwenden. Wenn ein Benutzer mit einer installierten Web Request-Erweiterung auf einen Link klickt, informiert Chrome die Erweiterung darüber, dass eine Datenanfrage gestellt wurde, bevor die Anfrage den Server erreicht. Die Erweiterung kann die Anfrage in dieser Phase ändern. Der Server antwortet dann, aber die Antwort durchläuft erneut die Erweiterung, und die Erweiterung kann bestimmen, ob die Antwort geändert werden muss. Anschließend rendert Chrome die Seite schließlich und der Nutzer kann das Ergebnis seiner Klickaktion sehen.
Als Chrome übergibt alle Daten in einer Netzwerkanfrage, Erweiterungen, die die Web Request API verwenden, haben Zugriff, um alles zu lesen und zu ändern, was ein Benutzer im Web tut. Während Inhaltsblocker wie uBlock Origin das Potenzial dieser API sinnvoll nutzen, behauptet Google dies Andere Erweiterungen mit böswilligen Absichten haben dies missbraucht, um Zugriff auf die persönlichen Daten der Benutzer zu erhalten Information. Laut Google nutzen seit Januar 2018 42 % der bösartigen Erweiterungen die Web Request API. Google behauptet außerdem, dass die API als blockierende Version mit „erheblichen Leistungseinbußen“ verbunden sei Dies erfordert einen beharrlichen und oft langwierigen Prozess, der grundsätzlich nicht mit „faulem“ Verhalten vereinbar ist. Prozesse.
Mit Manifest V3 schlägt Google vor, diese API in ihrer Blockierungsform einzuschränken. Als Alternative stellt Google die Declarative Net Request API bereit.
Die Zukunft
Die offizielle Beschreibung von Declarative Net Request beschreibt die API wie folgt:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Mit Declarative Net Request muss Chrome nicht alle Informationen zu einer Anfrage an die Listening-Erweiterung senden. Stattdessen registriert die Erweiterung Regeln bei Chrome, die dem Browser vorab mitteilen, was zu tun ist, wenn bestimmte Arten von Anfragen gesehen werden.
Die Erweiterung legt ihre Regeln im Voraus fest. Die Anfrage des Benutzers wird dann vom Browser (und nicht von der Erweiterung) mit dieser Regel abgeglichen, die Aktion wird ebenfalls vom Browser ausgeführt und die Seite anschließend gerendert. Google erwähnt, dass sie dadurch die Effizienz gewährleisten können, da sie die Kontrolle über den Algorithmus ausüben können, der das Ergebnis bestimmt, und ineffiziente Regeln verhindern oder deaktivieren können. Außerdem bietet es dem Endbenutzer bessere Datenschutzgarantien, da die Details der Netzwerkanfrage der Erweiterung nicht zugänglich gemacht werden. Da persistente und lang laufende Prozesse nicht mehr nötig seien (da die Regeln vorher registriert werden), behauptet Google das Dieser Ansatz bringt auch Leistungsverbesserungen mit sich, die Erweiterungen bei ressourcenbeschränkten Ressourcen deutlich rentabler machen Plattformen.
Die deklarative Netzanfrage wird sowohl für Manifest V2 (aktuell) als auch für Manifest V3 verfügbar sein, aber es wird die primäre Möglichkeit sein, mit der Google die Änderung von Netzwerkanfragen in Manifest V3 zulässt.
Die Kontroverse
Die Änderungen von Google scheinen sinnvoll zu sein, bis Sie die andere Seite der Geschichte hören, hauptsächlich die der Werbeblocker. Diese spezielle API-Migration wird als Googles Weg angesehen, Werbeblocker abzuschaffen, da sie die Funktionsweise eines der beliebtesten Werbeblocker grundlegend verändert. Dies knüpft an die „Theorie“ an, dass Google diese Änderung eher aus geschäftlicher Sicht als aus Sicht der Benutzersicherheit anstrebt. Schließlich ist Google für seine Einnahmen in hohem Maße auf Werbung angewiesen, und Werbeblocker werden in dieser Hinsicht als direkte Bedrohung für die Kunden von Google wahrgenommen, wie durch enthüllt wurde Alphabets SEC-Formular 10-K-Einreichung 2018 (über Das Register):
Neue und bestehende Technologien könnten unsere Fähigkeit zur Personalisierung von Anzeigen beeinträchtigen und/oder Online-Anzeigen blockieren, was unserem Geschäft schaden würde.
Es wurden Technologien entwickelt, um anpassbare Anzeigen zu erschweren oder die Anzeige von Anzeigen ganz und bei einigen Anbietern zu blockieren der Online-Dienste verfügen über integrierte Technologien, die möglicherweise die Kernfunktionalität der digitalen Dienste Dritter beeinträchtigen könnten Werbung. Der Großteil unserer Google-Einnahmen stammt aus Gebühren, die wir im Zusammenhang mit der Anzeige von Online-Anzeigen zahlen. Daher könnten sich solche Technologien und Tools negativ auf unsere Betriebsergebnisse auswirken.
Google musste eine Erklärung abgeben Um dieses Problem anzugehen, bekräftigt es seinen Standpunkt, dass die Änderung im Interesse der Privatsphäre der Nutzer und nicht als direkter Angriff auf Werbeblocker erfolgt:
Wir verhindern nicht die Entwicklung von Werbeblockern oder hindern Benutzer daran, Anzeigen zu blockieren. Stattdessen möchten wir Entwicklern, einschließlich Inhaltsblockern, dabei helfen, Erweiterungen so zu schreiben, dass die Privatsphäre der Benutzer geschützt wird.
Es muss auf zwei der beliebtesten Werbeblocker verwiesen werden, die in Google Chrome verfügbar sind: uBlock Origin Und Adblock Plus, die beide unterschiedliche Ansätze verfolgen, um das gleiche Ergebnis der Inhaltsblockierung zu erzielen. uBlock Origin verlässt sich stark auf die Web Request API und die Community hat im Laufe der Jahre dieser Erweiterung den Vorzug gegeben. Adblock Plus und andere Erweiterungen zum Blockieren von Inhalten basieren ebenfalls auf dem Blockierungsteil von Web Request, sodass Änderungen an dieser API letztendlich zumindest teilweise Auswirkungen auf die meisten Inhaltsblocker haben.
Der Vorstoß von Google, Web Request abzulehnen, wird uBlock Origin in seinem aktuellen Format im Wesentlichen zum Erliegen bringen, was in der Tat viele Benutzer betreffen wird. Während Benutzer ohne Loyalität (und ohne die Absicht, sich darum zu kümmern, wie der Werbeblocker erreicht wird) alternative Lösungen finden werden, die ihre eigenen Nachteile haben, wird dies unmöglich für Loyalisten und Enthusiasten, neue Filter-Engine-Designs zu entwickeln, um die verschiedenen Techniken zu umgehen, die Websites irgendwann entwickeln werden, um Werbeblocker auf dieser spezifischen API zu bekämpfen.
Es wurde auch vorgeschlagen, dass es sich bei Declarative Net Request um eine eher eingeschränkte Filter-Engine handelt zunächst geplant eine Beschränkung von 30.000 Regeln für statische Filterregeln pro Erweiterung (Regeln, die während der Installation deklariert werden) zu haben; und 5.000 Regeln für dynamische Filterregeln pro Erweiterung (Regeln, die nach der Installation hinzugefügt werden können). Alle überschüssigen Regeln werden ignoriert, was ein kleines Problem darstellt, da EasyList für Adblock Plus selbst über 70.000 Regeln verfügt, während uBlock Origin für die Ausführung mit über 100.000 Regeln konfiguriert werden kann. Nach der anfänglichen Gegenreaktion der Community Google hat geantwortet durch das Versprechen, das statische Regellimit von 30.000 Regeln pro Erweiterung auf ein globales Maximum von 150.000 Regeln zu ändern. Dies hat dann den Nebeneffekt, dass Benutzer daran gehindert werden, andere regelintensive Skripte in Verbindung mit einem Werbeblocker zu verwenden, sodass Benutzer mit ihren Präferenzen herumspielen müssen.
Anders als das begrenzte Filterlimit, Declarative Net Request kann nur auf statische URLs umleiten, daher ist keine Unterstützung für den Mustervergleich enthalten. uBlock Origin verlässt sich stark auf den Mustervergleich und den Erweiterungsentwickler angegeben, dass eine Nachrüstung nicht möglich sei den Matching-Algorithmus seiner Erweiterung, um die API-Anforderungen zu erfüllen. Die API würde auch ein komplettes Erweiterungsupdate erfordern, um einfach die Filterliste zu aktualisieren, was angesichts der viel zu häufigen Aktivität wäre Häufigkeit, mit der diese Filterlisten aktualisiert werden. Natürlich hängen diese Aktualisierungen auch von den Überprüfungskriterien und -prozessen von Google für Erweiterungen ab.
Andererseits hat Google immer an der Haltung festgehalten, dass seine Absicht, sich von Web Request zu entfernen, von a Sicherheitsaspekt, da die Web Request API in ihrer aktuellen Form zu leistungsfähig ist und einen sehr großen Spielraum offen lässt Missbrauch. Dieser Missbrauch ist nicht nur theoretisch, denn Google hat erwähnt, dass 42 % der böswilligen Erweiterungen diese API missbraucht haben. Apple Safaris Inhaltsblocker-API wurde aus ähnlichen Gründen wie Declarative Net Request entwickelt, da es für einen betrügerischen Entwickler weniger Spielraum zum Ausnutzen gibt. Auf der abgeschwächten Web-Anfrage wären Netzwerkanfragen weiterhin beobachtbar, sie würden jedoch Berechtigungen auf den relevanten Hosts benötigen. Mit Manifest V3 ändern sich auch die Hostberechtigungen erheblich und können nicht mehr pauschal zum Zeitpunkt der Installation gewährt werden.
Google hat auch Leistungseinbußen als Motiv für den Wechsel herangezogen. Die Auswertung von Netzwerkanfragen erfolgt im JavaScript-Thread der Erweiterung, was sich negativ auf die Leistung auswirken kann. Als Gegenargument erwähnt der Entwickler von uBlock Origin, dass seine Erweiterung führt zu keinen nennenswerten Leistungseinbußen selbst wenn bis zu 140.000 statische Filter durchgesetzt werden müssen. Die entstandenen Kosten lassen sich angeblich leicht durch die Ressourcen ausgleichen, die daran gehindert werden, von Remote-Servern heruntergeladen und somit nicht vom Browser verarbeitet zu werden.
Auch wenn Google diese Argumentation nicht verwendet, kann ein Argument gegen Web Request auch wegen der Effizienz beim Anzeigenblockieren vorgebracht werden. Wenn bei Web Request eine Erweiterung nicht rechtzeitig antwortet (aufgrund einer Verzögerung oder eines Absturzes), wird die Netzwerkverarbeitungsanforderung einfach zugelassen, wodurch Anzeigen durch den Werbeblocker gelangen. Declarative Net Request hingegen hätte diesen Nachteil nicht. Stattdessen werden Anzeigen weitergeleitet, wenn sie sich nicht an die statischen Regeln halten, was in den meisten Fällen der Fall sein wird.
Abschluss
Aus den obigen Erläuterungen geht klar hervor, dass Declarative Net Request kein 1:1-Funktionsklon für die Blockierung ist Die Funktionen der Web Request API sind nicht mehr verfügbar, und Erweiterungsentwickler werden sich bestimmt ärgern, wenn ihre harte Arbeit dadurch beeinträchtigt wird solche Veränderungen. Aber auch die Argumentation von Google hat Gewicht – Web Request ist zu mächtig, und seine Befugnisse müssen es auch sein im größeren Interesse der Benutzergemeinschaft (die aus durchschnittlichen Benutzern besteht) eingeschränkt Enthusiasten).
Der Schritt hin zu Declarative Net Request hätte auch ein positiver PR-Schritt sein können – schließlich fügt Google Chrome eine integrierte Content-Blocker-API hinzu! Da die neue API jedoch ihre eigenen starken Einschränkungen mit sich bringt, sieht die Community dies zu Recht als eine Beschneidung ihrer Flügel an. Im Idealfall hätte Google die Funktionsweise von Werbeblockern wie uBlock Origin untersuchen sollen, bevor es die neue API herausbrachte. In der jetzigen Form könnte die neue API weitere Lockerungen ihrer Regelgrenzen gebrauchen, um Szenarien zu berücksichtigen, in denen Benutzer zwei filterlastige Erweiterungen verwenden möchten.
Entsprechend Das Register, die ersten Builds mit Manifest V3-Änderungen werden ab Juli 2019 verfügbar sein. Wir hoffen, dass Google bei diesen Builds das Feedback der Community der Erweiterungsentwickler berücksichtigt.
Besonderer Dank geht an XDA-Chefredakteur Mishaal Rahman für seine Beiträge und seine Unterstützung!
Bearbeiten: Der Artikel hat die Funktionsweise von Adblock Plus fälschlicherweise mit der Funktionsweise der Declarative Net Request API gleichgesetzt. Der Artikel wurde entsprechend geändert. Adblock Plus wird auch von der Entfernung der Blockierungsfunktionen der Web Request API betroffen sein.