AdguardFilters: Wo die Regellisten von AdGuard und uBlock Origin entstehen

AdguardFilters: textbasierte Regeln für AdGuard und uBlock Origin

Das Repository AdguardTeam/AdguardFilters ist die Quelle, in der die Filter für AdGuard und weitere Werbeblocker entstehen, namentlich nennt das README uBlock Origin. Als Hauptsprache führen die Metadaten Adblock Filter List, was den Kerninhalt zutreffend beschreibt: Es handelt sich nicht um Programmcode, sondern um Muster, die Werbeblocker interpretieren, um Werbung und als datenschutzinvasiv eingestufte Inhalte wie Banner, Pop-ups und Tracker auszufiltern. Das Repository steht unter GPL-3.0, verzeichnet 4.482 Sterne, 822 Forks und 642 offene Issues, der Standardzweig heißt master.

Jede Regel ist Text. Daraus folgt der eigentliche Charakter des Projekts: Eine Änderung ist ein Textdiff, reviewbar ohne Build, und der Filter wird von Dutzenden unterschiedlichen Anwendungen mit jeweils eigener Interpretationsbreite gelesen. Das README rahmt das Vorhaben mit dem Satz ein, hier würden Werbe-Tracker tatsächlich blockiert.

Für Anwender ist die Trennung zwischen Repository und Anwendung wichtig. AdguardFilters liefert die Listen, das Blockieren selbst übernimmt die jeweilige App. Wer eine Regel ändern will, arbeitet also an einer Quelle, deren Wirkung erst im Abonnement der Anwendung sichtbar wird.

Regionale und zweckgebundene Filter im AdguardFilters-Repository

Ein Filter besteht aus einer Menge textbasierter Regeln. Zusammengefasst wird nach zwei Kriterien. Regional abgegrenzte Regeln werden zu Länderfiltern gebündelt, das README nennt einen deutschen und einen russischen Filter. Zweckgebundene Regeln werden ebenfalls zu eigenen Listen, etwa ein Filter für soziale Netzwerke und ein Filter für Tracker-Schutz.

Die Bündelung hat einen praktischen Grund. Ein Anwender aktiviert oder deaktiviert einen gesamten Filter auf einmal, statt einzelne Regeln zu verwalten. Wer keine Werbung aus sozialen Netzwerken blockieren will, schaltet genau diese Liste aus und behält den Rest.

Eine vollständige Aufzählung der verfügbaren Filter enthält das README nicht, auch keine Anzahl. Die genannten Beispiele sind ausdrücklich Beispiele. Wer wissen will, welche Listen aktuell gepflegt werden, muss die Verzeichnisstruktur des Repositorys selbst sichten; die Dokumentation macht dazu im verfügbaren Material keine Angabe.

Meldungen über agrd.io/report und Regelvorschläge in Issue-Kommentaren

Der Rücklauf aus der Nutzerschaft ist der Motor des Projekts. Das README hält fest, dass die Filter fortlaufend aktualisiert werden und dass das Repository jedem die Möglichkeit gibt, auf übersehene Werbung oder auf False Positives hinzuweisen. Genau daraus entsteht der Großteil der 642 offenen Issues.

Für Meldungen gibt es ein eigenes Werkzeug unter agrd.io/report. Die Issues selbst sind darauf ausgelegt, dass Freiwillige nicht nur melden, sondern lösen: Jedes offene Issue verweist auf ein Problem mit einer konkreten Website, und wer möchte, schlägt in den Kommentaren eigene Regeln vor. Filterentwickler von AdGuard prüfen diese Vorschläge und übernehmen sie, wenn sie korrekt sind.

Voraussetzung für eigene Regeln ist die Syntaxdokumentation unter adguard.com/kb/general/ad-filtering/create-own-filters/, die das README ausdrücklich als Pflichtlektüre nennt. Ohne sie lassen sich Vorschläge nicht formulieren, die eine Prüfung überstehen. Für andere Beiträge verweist das Repository auf die Seite adguard.com/contribute.html.

AGLint und die Pages-Abzeichen im AdguardFilters-README

Oben im README sitzen zwei Statusabzeichen, die über den Inhalt hinaus etwas über den Betrieb aussagen. Das erste verweist auf den Workflow aglint.yml, das zweite auf die Bereitstellung über GitHub Pages. AGLint ist damit der Prüfschritt, der eingehende Regeländerungen gegen die Syntax und die Konventionen des Projekts hält; die Pages-Ausgabe liefert eine aufbereitete Sicht auf die Filter.

Was AGLint im einzelnen prüft und wie die Pages-Site genutzt werden soll, erklärt das README an dieser Stelle nicht. Diese Angaben sind in der hier verfügbaren Dokumentation nicht enthalten und müssten aus den Workflow-Dateien oder der separaten AGLint-Dokumentation erschlossen werden.

Die Existenz beider Workflows belegt aber eine Grundannahme: Regeländerungen laufen durch automatisierte Prüfung, bevor sie in den Filtern landen. Bei einem Repository mit 642 offenen Issues und Beiträgen aus der Community ist das der Mechanismus, der die Listen überhaupt konsistent hält.

Keine Release-Tags und 642 offene Issues bei AdguardFilters

Die Metadaten fallen in zwei Punkten aus dem Rahmen. Erstens sind im Material keine Veröffentlichungen geführt, die Liste der Releases ist leer. Es gibt also keine Version, auf die sich ein Anwender oder ein anderer Blocker fest beziehen könnte, sondern nur den jeweiligen Stand im Zweig master. Wer einen stabilen Bezugspunkt braucht, muss einen Commit oder ein Datum festhalten.

Zweitens ist das Feld für die letzte Aktivität im Material leer. Eine Aussage zur Pflegehäufigkeit lässt sich daraus nicht ableiten. Das README formuliert stattdessen einen Selbstanspruch: Die AdGuard-Filter gehörten zu den am aktivsten entwickelten Filterlisten, wenn nicht zur aktivsten. Das ist eine Aussage des Projekts über sich selbst und durch die Metadaten nicht unabhängig bestätigt.

Die Zahl der offenen Issues von 642 kann man in beide Richtungen lesen. Sie belegt einen lebhaften Rücklauf, zeigt aber auch, dass der Rückstand nicht klein ist. Für eine Meldung zu einer spezifischen Website ist das kein Hindernis, weil Meldungen über das eigene Werkzeug laufen und nicht darauf warten, dass ein Issue geschlossen wird.

GPL-3.0 für Filterregeln: was bei AdguardFilters unter Weitergabe fällt

Das Repository ist unter GPL-3.0 lizenziert, und das betrifft die Regeln selbst, nicht nur begleitenden Code. Für die Praxis heißt das: Wer eine AdGuard-Filterliste verändert und weitergibt, muss die Änderung als solche kennzeichnen und dieselben Freiheiten an die Empfänger weiterreichen. Eine eigene, abgeleitete Liste unter abweichender Lizenz zu veröffentlichen, ist damit nicht ohne weiteres möglich.

Für reine Anwender ist das folgenlos, weil das Abonnieren einer Liste keine Weitergabe darstellt. Anders sieht es aus, wenn eine Filterliste in ein Produkt eingebettet oder als eigene Subscription angeboten wird. An dieser Stelle lohnt der Blick in den vollständigen Lizenztext, den das Repository unter master verlinkt.

Neben der Lizenz gibt es eine eigene Filterrichtlinie unter adguard.com/kb/general/ad-filtering/filter-policy/. Sie legt fest, nach welchen Kriterien Filter gepflegt werden, und damit auch, welche Art von Regel aufgenommen wird und welche nicht. Wer einen Vorschlag einreicht, sollte diese Kriterien kennen.

AdguardFilters abonnieren oder eine eigene Liste mit der dokumentierten Syntax pflegen

Die Alternative zum Abonnieren ist eine eigene Filterliste. Die Syntax dafür ist unter adguard.com/kb/general/ad-filtering/create-own-filters/ dokumentiert, und technisch genügt eine Textdatei mit Regeln, die in AdGuard oder uBlock Origin als eigene Subscription eingebunden wird.

Der Unterschied liegt in der Arbeitsteilung. AdguardFilters bringt die Pflege durch eine Community mit: Neue Werbeformate werden gemeldet, False Positives fallen auf, und Regelvorschläge werden von Filterentwicklern geprüft. Eine eigene Liste hat davon nichts; dafür wirkt eine eigene Regel sofort, ohne Prüfschritt und ohne Rücksicht auf die Filterrichtlinie.

Für Einzelprobleme ist die eigene Liste deshalb das schnellere Werkzeug. Wer etwa eine interne Anwendung betreibt, die von einer Regel irrtümlich blockiert wird, ergänzt eine Ausnahme in der eigenen Liste, statt auf eine Filteranpassung zu warten. Für die Breite des Webs skaliert dieser Ansatz nicht, weil die Pflege an einer Person hängt.

Für wen sich AdguardFilters als Quelle eignet

Als Abonnementquelle passt das Repository für alle, die eine fortlaufend gepflegte Liste wollen und damit leben können, dass es keine Version zum Festnageln gibt. Die regionale und zweckgebundene Aufteilung erlaubt es, die eigene Konfiguration grob zu steuern, ohne in Regeln einzugreifen.

Als Mitwirkungsort passt es für Menschen, die Muster schreiben können und Geduld für den Prüfprozess haben. Der Weg führt über die Syntaxdokumentation und danach in die offenen Issues, in denen konkrete Websites verhandelt werden.

Weniger geeignet ist das Repository als Bezugsquelle für automatisierte Builds, die einen unveränderlichen Stand erwarten. Ohne Release-Tags bleibt nur das Festhalten eines Commits, und die leere Aktivitätsangabe im Material erlaubt keine Aussage darüber, wie schnell auf einen gemeldeten Fehler reagiert wird.

Redaktionelles Fazit

AdguardFilters eignet sich für Anwender, die eine fortlaufend gepflegte Regelliste für AdGuard oder uBlock Origin abonnieren wollen und Fehler über den vorgesehenen Meldeweg zurückgeben können. Weniger geeignet ist das Repository für Projekte, die eine versionierte, einzeln abonnierbare Datei mit festem Stand brauchen, weil im Material keine Release-Tags geführt sind. Wer Regeln in ein eigenes Produkt übernimmt, sollte die GPL-3.0-Weitergabebedingungen vorher klären. Als Einstieg empfiehlt sich ein Blick in die offenen Issues: Sie zeigen, welche Websites gerade False Positives melden, und machen sichtbar, wie schnell Regelvorschläge überprüft werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository