Eigene Filter und Quick Fixes-Filter entfernt: Der Einfluss der MV3-Politik
Wo sind die Eigenen Filter? Und was ist mit dem Quick Fixes-Filter passiert?
Um die strenge Richtlinie zur Remote-Ausführung von Chrome unter Manifest V3 einzuhalten, mussten wir einige schwierige Entscheidungen treffen. Die Eigenen Filter sind vorübergehend nicht verfügbar, und der Quick Fixes-Filter wurde endgültig entfernt.
Warum das? Die Chrome-Richtlinien verbieten das Einfügen von Skripten oder remote gehostetem Code. Die Absicht hinter dieser Richtlinie ist zwar gut, aber die Formulierungen sind so weit gefasst, dass sogar Werbeblocker-Regeln darunterfallen können — und das war leider sowohl bei den Eigenen Filtern als auch beim Quick Fixes-Filter der Fall.
Warum dies ein Problem ist
Der Quick Fixes-Filter wurde ursprünglich nur eingeführt, weil MV3 so viele Einschränkungen mit sich bringt.
In der MV3-Erweiterung sind alle AdGuard-Filter direkt in die Erweiterung integriert. Das bedeutet: Um die Filter zu aktualisieren, muss die gesamte Erweiterung aktualisiert werden, zusammen mit Überprüfung im Store — und dieser Prozess kann Tage dauern, bis diese Updates bei den Nutzer:innen ankommen. Wenn also eine beliebte Website nicht mehr richtig funktioniert, müssen Nutzer:innen auf eine Lösung warten — was für alle Beteiligten frustrierend ist.
In MV2 konnten wir dieses Problem mit differenziellen Updates lösen. Dadurch konnten wir neue Filter schnell bereitstellen, ohne die gesamte Erweiterung aktualisieren zu müssen. Aber MV3 erlaubt das nicht, und der Quick Fixes-Filter war unser Workaround, um trotzdem Echtzeit-Updates liefern zu können.
Trotz aller Versuche, diesen Filter konform zu gestalten (lesen Sie unten die quälende Geschichte unseres Hin und Her um diesen Filter), zwangen uns die Chrome-Richtlinien schließlich, ihn komplett zu entfernen. Und das ist nur ein großer Verlust.
Ein weiterer Verlust sind die Eigenen Filter, die ebenfalls den Richtlinien zur Remote-Ausführung zum Opfer gefallen sind.
Eigene Filter ermöglichen das Hinzufügen von Filtern Dritter über eine URL. Tausende von Freiwilligen pflegen diese Filter, die für das Wachstum des Werbeblocker-Ökosystems entscheidend sind. Wir können nicht alle Filter in unsere „vorkonfigurierten“ Listen aufnehmen, und Eigene Filter waren die perfekte Möglichkeit, die Filterung individuell anzupassen und neue Filter einfach zu testen und zu verteilen.
Der Verlust der Eigenen Filter ist nicht nur ein Rückschlag für die Nutzer:innen; wir werden unser Bestes tun, um unsere Erweiterung für sie effektiv zu halten — sondern trifft auch die Community, die die Welt der Werbeblocker am Laufen hält. Wie wir schon in einem unserer vielen MV3-bezogenen Beiträge gesagt haben, „Die wahren Opfer dieses Übergangs sind die Filterentwickler“.
Wie wir das Problem lösen
Wir überarbeiten, wie AdGuard mit Filterregeln umgeht, um den Chrome-Richtlinien zu entsprechen — und dabei die Funktionalität der Erweiterung zu erhalten.
Das sind unsere nächsten Schritte:
-
Um die Eigenen Filter zurückzubringen, werden wir die API
userScripts. Damit können wir Skripte so registrieren, dass sie den MV3-Richtlinien entsprechen.Aber es gibt einen Haken: Man muss den Entwicklermodus aktivieren, um Eigene Filter zu verwenden — ein zusätzlicher Schritt, der für weniger technikaffine Nutzer:innen ein Hindernis sein könnte. Sobald wir die Version mit eigenen Filtern einführen, werden wir sicherstellen, dass es klare Anleitungen zur Aktivierung dieses Modus und zum Hinzufügen von Filtern gibt.
-
Da der Quick Fixes-Filter in seiner ursprünglichen Form nicht mehr existieren kann, setzen wir auf den Fast-Track-Überprüfungsprozess von Chrome. Damit können wir die Filter häufiger aktualisieren, ohne jedes Mal die gesamte Erweiterung überprüfen lassen zu müssen.
Diese Methode hat jedoch einige Einschränkungen: Sie gilt nur für Änderungen an DNR-Regelsätzen und „sicheren“ Regeln.
Künftig wird es zwei Arten von Updates geben:
- Schnelle Updates, die automatisch alle paar Stunden durchgeführt werden
- Vollständige Updates mit Überprüfung im Chrome Web Store
Es war ein langer Weg zu dieser nicht ganz idealen Lösung. Im Folgenden finden Sie eine Chronologie aller Schritte, die wir unternommen haben, um unsere Erweiterung mit den Richtlinien von Chrome in Einklang zu bringen und gleichzeitig Werbung effektiv zu blockieren und den Nutzer:innen die Möglichkeit zu geben, die Filterung nach ihren Wünschen anzupassen.
Die Zeitleiste unseres Kampfes
- 1. Ablehnung: Remote Skriptausführung
Unsere Einreichung wurde abgelehnt, weil wir <script>-Tags zur Anwendung von Regeln verwendet haben. Wir haben in der Tat einen Mechanismus verwendet, bei dem die Erweiterung Skripte aus Regeln extrahiert und sie über den <script>-Tag auf die Seite anwendet. Für MV3-Erweiterungen sind die Anforderungen an die Content Security Policy strenger als für MV2, und wir können nicht einfach Skriptregeln einfügen, was die den Entwicklern zur Verfügung stehenden Tools zur Änderung von Seiteninhalten stark einschränkt. Aus diesem Grund mussten wir in einigen Fällen die Injektion des <script>-Tags verbessern, was zu einem Problem wurde.
Was wir unternommen haben:
Wir haben eine Lösung übernommen, die wir bereits in Firefox verwendet hatten: die Umwandlung von Skriptregeln in lokale JavaScript-Funktionen, die in der Erweiterung gespeichert sind. Auf diese Weise konnten wir die Regeln nativ ohne <script>-Tags anwenden. Wir fügten auch Überprüfungen hinzu, um sicherzustellen, dass Skripte Teil integrierter Regeln sind, bevor sie angewendet werden.
Ausnahmen wurden jedoch für Benutzerregeln, Eigene Filter und den Quick Fixes-Filter beibehalten, die weiterhin <script> zum Einfügen von Regeln verwendeten.
Ergebnis: Die Version mit diesen Änderungen wurde zunächst genehmigt — aber dann wieder abgelehnt.
- 2. Ablehnung: Download des Quick Fixes-Filters
Diesmal hat Chrome den Mechanismus beanstandet, mit dem der Quick Fixes-Filter von einer Remote-Quelle heruntergeladen wurde.
Was wir unternommen haben:
Wir fügten ausführliche Kommentare hinzu, die den Zweck des Quick Fixes-Filters erläuterten und klarstellten, wie er entwickelt wurde, um die Einschränkungen von MV3 zu beheben, ohne gegen die Richtlinien zu verstoßen.
Ergebnis: Nicht genug für die Reviewer.
- 3. und 4. Ablehnung: Komplette Entfernung des Quick Fixes-Filters
Wir haben den Quick Fixes-Filter komplett entfernt und die Erweiterung erneut eingereicht. Nach wiederholten Ablehnungen haben wir den Support kontaktiert und eine Version eingereicht, die auch den Download von Metadaten deaktivierte.
Ergebnis: Kurzzeitig genehmigt, dann wieder abgelehnt.
- 5. Ablehnung: Scriptlets und Parameter
Chrome stufte die Nutzung von Scriptlets (eingebaute JavaScript-Funktionen) als Verstoß ein, da sie mit Parametern ausgeführt werden können.
Was wir unternommen haben:
Wir haben alle Skriptlets direkt in die Erweiterung hardcodiert. Die Erweiterungs-Engine prüft nun, ob eine Regel einer vorkonfigurierten Filterkategorie entspricht (z. B. Werbeblockierung oder Sicherheit). Wenn es eine Übereinstimmung gibt, wird die Regel angewandt; andernfalls wird sie verworfen.
Außerdem haben wir den Quick Fixes-Filter in eingeschränkter Form wieder eingeführt, allerdings ohne <script>-basierte Ausführung.
Ergebnis: Die Erweiterung wurde trotz dieser Änderungen weiterhin abgelehnt.
Das große Ganze
Natürlich werden wir auch diese Herausforderung meistern — das ist schließlich unser Job. Aber es geht hier nicht nur um AdGuard. Die Chrome-Richtlinien betreffen alle Werbeblocker und Erweiterungen.
Entwickler brauchen klarere Richtlinien und mehr Transparenz vom Chrome Web Store. Wir hoffen, dass diese Situation eine Diskussion darüber anregt, wie man Sicherheit und Funktionalität besser ausbalancieren kann — zum Nutzen von uns allen.
