AdGuard veröffentlicht den weltweit ersten Werbeblocker auf Basis von Manifest V3

Manifest V3, die neue Erweiterungs-API von Chrome, ist nicht mehr eine Scheinbedrohung. Sie ist jetzt die neue Realität, in der Dutzende von Werbeblocker-Erweiterungen, einschließlich AdGuard Browsererweiterung, funktionieren sollen (wenn sie können).

Die Welle von Manifest V3 hat sich langsam aber sicher aufgebaut. Als Google 2018 zum ersten Mal ein Dokument zur Beschreibung der neuen API veröffentlichte, brach die Entwicklergemeinschaft in Kritik aus. Auch wir standen nicht abseits und veröffentlichten mehrere Artikel, in denen wir die möglichen negativen Folgen der Manifest V3-Implementierung beschrieben und sogar die Hoffnung äußerten, dass sich die Dinge nicht so schlecht entwickeln würden.

Trotz des öffentlichen Aufschreis wurde Manifest V3 Ende 2020 zusammen mit Chrome 88 Beta verfügbar. Seit Januar 2022 ist es nicht mehr möglich, neue Erweiterungen, die auf Manifest V2 basieren, zum Chrome Web Store hinzuzufügen. Die letzte Phase der Einführung wird sehr bald kommen: Ab Januar 2023 werden alle Erweiterungen, die auf Manifest V2 basieren, nicht mehr funktionieren, auch nicht diejenigen, die zuvor zum Chrome Web Store hinzugefügt wurden.

Wenn Sie AdGuard für Windows, Mac oder Android verwenden, sollten Sie sich keine Sorgen um MV3 machen. Diese Produkte sind durch keinen Browser eingeschränkt.

Zum Glück sind wir darauf vorbereitet.

Experimentelle AdGuard MV3-Browsererweiterung

Mitte 2021 begannen wir mit der Arbeit am Prototyp einer neuen Erweiterung, die in der Lage sein sollte, Anzeigen auch innerhalb der strengen Grenzen von Manifest V3 zu blockieren. Die Aufgabe war nicht einfach: Die neue API war noch unausgereift, einige Aspekte wurden gerade fertiggestellt und funktionierten nicht wie vorgesehen. Aber wir haben sie natürlich gemeistert und bewiesen, dass Werbeblocker auch nach der Apokalypse von Manifest V3 überleben werden.

Während der Entwicklung des Prototyps sahen wir uns mit vielen ernsthaften Problemen konfrontiert, die durch die Funktionen der neuen API verursacht wurden: einige davon konnten wir überwinden, mit anderen mussten wir uns abfinden. Wir werden über jedes dieser Probleme im Detail sprechen.

Wenn Sie es in der Zwischenzeit ausprobieren möchten, können Sie es aus dem Chrome WebStore installieren.

Hier ist ein kurzes Video, das zeigt, wie es funktioniert

Grenzwerte der Regel

Wenn Sie nicht wissen, was Filterregeln sind und wie Werbeblocker im Allgemeinen funktionieren, oder wenn Sie Ihr Wissen auffrischen möchten, besuchen Sie unsere Wissensdatenbank für eine kurze Erklärung.

Alle Regeln, die in den Erweiterungsfiltern enthalten sind, wurden von Manifest V3 in statische (eingebaute) und dynamische Regeln unterteilt. Deren Anzahl wurde drastisch begrenzt.

Für statische Regeln legte Chrome eine garantierte Mindestgrenze von 30.000 Regeln pro Erweiterung und eine Gesamtgrenze von 330.000 Regeln für alle Erweiterungen im Browser fest. Dies berücksichtigt auch die Grenze von 1.000 Regexp-Regeln pro Erweiterung. Der Trick besteht darin, dass eine Erweiterung die gesamte zulässige Anzahl von Regeln erhalten kann. Wenn es mehr als eine Erweiterung gibt, können einige davon nicht genug Platz für ihre Regeln haben.

Wenn dies bei unserer Erweiterung auftritt (und dies kann jederzeit passieren, z. B. nach einem Update, einem Neustart des Service Workers, einer Änderung der Filtereinstellungen in unseren oder in den Werbeblockern von Drittanbietern), wird eine Meldung angezeigt, die besagt, dass der Browser die Liste der aktiven Filter geändert hat und nur noch der AdGuard Basisfilter aktiviert ist. Im schlimmsten Fall könnte sogar der Basisfilter nicht aktiviert werden, da er mehr als 30.000 Regeln enthält. In diesem Fall würden Benutzer:innen ohne AdGuard-Schutz dastehen.

Alle diese Fälle sind von uns vorgesehen und werden auf einem separaten Bildschirm mit einer Beschreibung angezeigt, was der Browser deaktiviert hat und was er aktiviert gelassen hat.

Für die dynamischen Regeln, innerhalb derer Benutzer:innen ihre eigenen Regeln oder Filter hinzufügen können, gibt es eine winzige Grenze von 5.000, einschließlich der Grenze von 1.000 Regexp-Regeln. Wenn dieses Limit überschritten wird, kann AdGuard MV3 nur die ersten 5.000 Regeln anwenden, der Rest bleibt inaktiv.

Benachrichtigungen über das Überschreiten des Limits sehen dann so aus:

Die Einschränkungen von Manifest V3 schaden nicht nur der Qualität der Filter und der Benutzerfreundlichkeit, sondern auch der Gemeinschaft der Filterentwickler:innen. Früher konnte jeder einen Filter für sich selbst erstellen, und mit der Zeit konnte ein solcher Filter populär werden und in die Liste der empfohlenen Werbeblocker aufgenommen werden. Jetzt ist es viel schwieriger, dies zu erreichen. Schließlich müssen die Werbeblocker voreingestellte Filter verwenden (nicht mehr als 50), und wir müssen sehr selektiv auswählen, welche Filter den Benutzer:innen zur Verfügung stehen sollen. Natürlich können Sie Ihre eigenen Filter auch manuell setzen. Vergessen Sie aber nicht die Begrenzung auf 5.000 Regeln für alle benutzerdefinierten Filter und Benutzerregeln.

Die weitere Beschreibung der Probleme enthält eine Menge Details, die vor allem für Entwickler:innen verständlich sind. Wenn Sie nicht so technisch versiert sind, können Sie diesen Teil überspringen.

Deklarative Regeln

Vor den Einschränkungen von Manifest V3 wurde die Filter-Engine dynamisch aus Filtern aufgebaut, die die Erweiterung vom Server heruntergeladen hat. Außerdem wurden die Regeln, aus denen die Filter bestehen, in verschiedenen Phasen des Seitenladens angewendet.

So konnten beispielsweise Regeln ausgelöst werden, bevor der Browser überhaupt eine Anfrage sendete: Mit dem Ereignis onBeforeRequest fragte der Browser, was mit einer bestimmten Anfrage zu tun sei. Die Erweiterung antwortete dynamisch, indem sie die Anfrage blockierte oder weiterleitete. Die kosmetischen Regeln wurden etwas später angewendet, als die Seite bereits geladen war und das DOM erschien.

Seitdem Manifest V3 in Kraft getreten ist, kann die Methode onBeforeRequest nicht mehr angewendet werden. Chrome schlägt stattdessen vor, die declarativeNetRequest API zu verwenden, mit der dem Browser das Recht eingeräumt wird, Anfragen zu ändern. Die Erweiterung legt lediglich eine Reihe von deklarativen Regeln fest, nach denen der Browser Netzanfragen ändern oder blockieren wird.

Syntax der deklarativen Regeln

Die Syntax der deklarativen Regeln unterscheidet sich deutlich von der Syntax, die Filterentwickler:innen üblicherweise verwenden. Viele Community-Mitglieder werden die Arbeit mit Manifest V3 wahrscheinlich aufgeben, weil sie nicht die Zeit aufwenden wollen, um Chrome-spezifische Regeln zu erstellen.

Jede Regel sollte aus den folgenden Feldern bestehen:

• id ist der Bezeichner der Regel. Er kann verwendet werden, um eine deklarative Regel mit einer Textregel zu verknüpfen
• priority ist die Priorität der Regel. Sie bestimmt, wie die Regel auf die Abfrage angewendet wird
• action ist die Aktion der Regel
  Es gibt drei Arten von Aktionen:
  • block – Aktionen, die Anfragen blockieren
  • redirect oder upgradeScheme – Aktionen, die Anfragen umleiten
  • allow or allowAllRequests – Aktionen, die Anfragen zulassen
• condition – Bedingung, unter der die Regel angewendet wird

Beispielregel:

{
  "id": 1,
  "priority": 1,
  "action": { "type" : "block" },
  "condition": {
    "urlFilter": "abc",
    "domains": ["example.org"],
    "resourceTypes": ["script"]
  }
}

Diese Regel blockiert alle Anfragen an Skripte, die eine Teilzeichenkette abc in ihrer Adresse haben und von einer Website mit der Domain example.org stammen.

In dieser Situation haben wir ein starkes Déjà-vu-Gefühl: Als wir die Safari-Erweiterung zum Blockieren von Werbung entwickelten, mussten wir einen Weg finden, unsere Regelsyntax in die von den Browser-Entwickler:innen vorgegebene Syntax zu konvertieren. Dieses Mal verwenden wir eine ähnliche Lösung, um unsere Syntax in deklarative Chrome-Regeln umzuwandeln.

Um statische und dynamische Regeln zu konvertieren, haben wir ein Modul zu unserer Bibliothek @adguard/tsurlfilter hinzugefügt. Die Bibliothek geht die Filterregeln durch und wandelt sie in deklarative Regeln um, die sie zu Regelsätzen zusammenfasst und in json-Dateien ablegt. Um die Verbindung zwischen einer Textregel und einer json-Regel nicht zu verlieren, baut die Bibliothek eine Korrespondenztabelle zwischen ihnen auf.

Ein paar Beispiele dafür, wie der Konverter funktioniert:

Die Regel ||example.com^$script wird konvertiert in

{
    "id": 1,
    "action": {
        "type": "block"
    },
    "condition": {
        "urlFilter": "||example.com^",
        "resourceTypes": [
            "script"
        ],
        "isUrlFilterCaseSensitive": false
    }
}

Die Regel @@||example.com^$script$domain=example.org wird konvertiert in

{
    "priority": 1,
    "id": 23,
    "action": {
        "type": "allow"
    },
    "condition": {
        "urlFilter": "||example.com^$script",
        "initiatorDomains": [
            "example.org"
        ],
        "isUrlFilterCaseSensitive": false
    }
}

Die meisten Regeln werden korrekt konvertiert, aber einige Funktionen gehen aufgrund verschiedener Einschränkungen verloren:

• $removeparam unterstützt keine Ausschlüsse (~) und reguläre Ausdrücke (regexp)
• Für reguläre Ausdrücke verwendet Chrome seine eigene Implementierung solcher Ausdrücke, so dass einige Standardfunktionen nicht unterstützt werden. Dies sind zum Beispiel reguläre Ausdrücke, die Rückverweise, negative Lookaheads und Possessivquantoren enthalten.
• negative lookahead wird oft in Filtern verwendet. Eine schnelle Suche ergab, dass es derzeit 43 Regeln mit diesem Ausdruck in den Filtern gibt. Dies mag relativ wenig erscheinen, aber bedenken Sie, dass jede dieser Regeln für mehrere Websites gedacht ist - allein diese Einschränkung verhindert bereits das Funktionieren von Werbeblockern auf mehr als 1000 Websites.
• Reguläre Ausdrücke werden in Chrome zusätzlich auf den verbrauchten Speicherplatz überprüft. Da wir nicht genau wissen, welche Implementierung verwendet wird, können reguläre Ausdrücke Probleme verursachen.
• Cookie-Regeln werden nicht unterstützt.
• Es gibt noch viele andere Probleme, die wir hier nicht erwähnen, um den Beitrag nicht zu überfrachten.

Das Problem mit deklarativen Regeln liegt auf der Hand: Ihre Syntax schränkt die Möglichkeiten unserer Erweiterung stark ein. Und leider können wir nichts dagegen tun, außer zu hoffen, dass die Chrome-Entwickler:innen dies im Laufe der Zeit verbessern.

Regelsätze

Gemäß der neuen API müssen deklarative Regeln zu Regelsätzen zusammengefasst werden.

Ein Beispiel für die Integration eines Regelsatzes in Manifest V3:

{
  "name": "AdGuard AdBlocker MV3",
  "version": "1",
  "declarative_net_request": {
     "rule_resources": [{
       "id": "ruleset_1",
       "enabled": true,
       "path": "rules.json"
     }]
   },
   …
}

Regelsätze werden in der Datei manifest.json angegeben und werden nur geladen, wenn die Erweiterung installiert oder aktualisiert wird. Und auch das ist ein großes Problem.

Es kann vorkommen, dass eine Filterregel das Layout oder die Funktionalität einer oder mehrerer Websites beeinträchtigt. Bei einer so unglaublich großen Anzahl von Regeln ist es statistisch gesehen fast unmöglich, solche Vorfälle vollständig zu vermeiden. Hinzu kommt, dass sich Websites ständig ändern, und Regeln, die früher problemlos funktionierten, können heute Probleme verursachen. Aber das ist in Ordnung: Wir haben eine einfache Lösung dafür.

Stellen Sie sich vor, dass sich eine solche Regel im Filter befindet und Sie sie schnell deaktivieren müssen. In den Manifest V2-Erweiterungen wurde zu diesem Zweck der Modifikator $badfilter verwendet. Die Filterentwickler:innen fügten eine Regel mit dem angegebenen Modifikator hinzu, die Erweiterung wurde dynamisch aktualisiert, die neue Regel deaktivierte die betreffende Regel, und alles lief besser. Wie Sie verstehen, geht dieser „Trick“ nicht mit Manifest V3.

Jetzt müssen Sie möglicherweise mehrere Tage auf die Filter-Updates warten: Es reicht nicht aus, eine neue Version der Erweiterung in den Chrome Store zu stellen, Sie müssen auch warten, bis sie die Prüfung bestanden hat. Leider gibt es keine andere Möglichkeit, den Benutzer:innen aktualisierte Filter zur Verfügung zu stellen. Die Diskussion über die Möglichkeit, einzelne Regeln zu aktivieren und zu deaktivieren, lässt hoffen. Es besteht eine kleine Chance, dass Erweiterungen doch noch die Möglichkeit erhalten, Filter schnell zu aktualisieren.

Statistiken und Filterungsprotokoll

Die auf Manifest V2 basierende AdGuard Browsererweiterung verfügt über ein Filterungsprotokoll, das alle von Ihrem Browser gesendeten Anfragen und detaillierte Informationen dazu anzeigt. Insbesondere können Sie sehen, welche Filterregel verwendet wurde, um diese bei Bedarf zu modifizieren.

Da Chrome jetzt selbst Anfragen blockiert und Statistiken nur noch an Erweiterungen weitergibt, die im Entwicklermodus entpackt und installiert wurden, können wir das Filterungsprotokoll nicht mehr wie früher implementieren. Aber wir können uns eine besondere Alternative einfallen lassen, die wir in der endgültigen Version der Erweiterung umsetzen wollen.

Wenn Sie also das Filterungsprotokoll öffnen, wird eine Engine gestartet, die nach den Regeln von Manifest V2 arbeitet. Sie wird nichts mit den Anfragen machen, sondern nur zeigen, welche Regeln angewendet wurden. Durch den Vergleich der Chrome-Statistiken mit den Ergebnissen der alten Engine erhalten wir ein grobes Bild davon, wie die Anfragen verarbeitet werden.

In der aktuellen Version des Prototyps ist kein Filterungsprotokoll implementiert. Stattdessen müssen die Filterentwickler:innen den von Chrome empfohlenen Mechanismus verwenden. Der Punkt ist, dass mit Hilfe von declarativeNetRequest können Sie feststellen, welche Regel ausgelöst wurde. Es gibt jedoch eine Nuance: Sie müssen die Erweiterung in „ungepackter“ Form installieren. Das heißt, Sie müssen unser Repository klonen, die Erweiterung „erstellen“, den Browser in den Entwicklermodus schalten, und nur in diesem Fall können Sie die Tools zum Debuggen von Filtern verwenden.

Service Worker

Mit Manifest V2 ist die Hintergrundseite nun ein Ding der Vergangenheit. Diese Seite diente dazu, die Erweiterung einmalig nach der Installation oder beim Öffnen eines Browsers zu starten. Sie arbeitete im Hintergrund. In Manifest V3 wird diese Hintergrundseite durch den sogenannten Service Worker ersetzt, der häufig vom Browser unterbrochen wird.

Wenn der Browser den Service Worker anhält, geht die Erweiterung in eine Art Schlafmodus über: Deklarative Regeln funktionieren, aber kosmetische Regeln, die dynamisch geladen werden, nicht. Damit die Erweiterung funktioniert, muss der Service Worker aufgeweckt werden, z. B. durch das Laden einer Seite oder durch eine Nachricht, die an den Service Worker gesendet wird.

Wenn der Service Worker aufwacht, beginnt die Erweiterung, Filterregeln aus dem Repository zu lesen und zu verarbeiten, um sie dann schnell zu finden. Während dieser Zeit, d. h. für 1,5-2 Sekunden, wendet die Erweiterung keine kosmetische Filterung an, sondern die Werbeanfragen werden vom Browser selbst blockiert. Danach wird die Engine gestartet und die Werbung verschwindet.

Wir planen, die Aufwachzeit des Service Workers zu verkürzen und die meisten kosmetischen Regeln in das Inhaltsskript zu verlagern (das im Kontext der Website arbeitet und nicht jede Minute abgeschaltet wird), aber für einige Fälle werden wir den Service Worker weiterhin benötigen.

Fazit

Trotz der Einschränkungen von Manifest V3 schützt AdGuard MV3 immer noch recht gut vor Werbung und Tracking:

• Blockiert präventiv Anfragen an Tracker
• Blendet Werbebanner, Widgets für soziale Netzwerke und andere störende Elemente aus
• Blockiert Werbung auf Video-Hosting-Plattformen, einschließlich YouTube

Die experimentelle Erweiterung ist zwar nicht so effektiv wie ihre Vorgängerin, aber die meisten Nutzer:innen werden den Unterschied nicht bemerken. Das Einzige, was sich bemerkbar machen wird, ist ein Aufflackern von Anzeigen wegen der Verzögerung bei der Anwendung kosmetischer Regeln.

Mit diesem Prototyp wollen wir den neuen Ansatz testen und Feedback einholen. Also bitte probieren Sie die neue Erweiterung aus und sagen Sie uns, was daran verbessert werden kann. Wie üblich ist der Prototyp quelloffen, Sie können ihn auf Github finden. Wenn Sie Probleme damit haben oder etwas vorschlagen möchten, teilen Sie uns dies auf GitHub mit.

Mit dem Release von der ersten Browsererweiterung, die auf Manifest V3 basiert, können wir sagen: Wir haben Googles Herausforderung bestanden. Es gibt noch viel zu tun, aber auch nach der Einstellung von Manifest V3 werden Chrome-Nutzer:innen in der Lage sein, sich mit AdGuard Browsererweiterung vor Werbung und Trackern zu schützen.