Ein Werbeblocker muss auch reparieren können
Weniger Werbung ist das Ziel. Genauso wichtig ist mir aber, dass eine Website weiter benutzbar bleibt. Deshalb gehört die Reparatur für mich von Anfang an zum Werbeblocker dazu.
RiffBlock steht schon eine Weile auf meinem Zettel. Beim aktuellen Stand geht es mir nicht um einen großen Schalter mit einem möglichst beeindruckenden Zähler. Ich möchte erkennen können, ob der Schutz wirklich eingerichtet ist, und verstehen, was ich tun kann, wenn eine einzelne Seite Probleme macht.
Nicht nur „eingeschaltet“ anzeigen
Die Grundlage sind drei native Safari-Inhaltsblocker: Werbung, Datenschutz und Darstellung. Nach der Einrichtung prüft die App ihre tatsächliche Wirkung auf einer erlaubten Safari-Seite. Der Test gehört zur aktiven Filtergeneration. Damit kann ein alter gespeicherter Zustand nicht einfach als frischer Funktionsbeleg gelten.
Das ist weniger auffällig als eine Erfolgsanimation, aber im Alltag für mich die wichtigere Aussage. Die angezeigten Zahlen sind Regelzahlen. Ich erfinde daraus weder eine Anzahl entfernter Anzeigen noch einen Akkugewinn.
Die aktuelle Website statt gleich alles
Die zusätzliche Safari-Erweiterung kümmert sich um dynamische Seiten und bestimmte Videozustände. Wenn sie zu weit greift, kann ich zunächst die Zusatzlogik für die aktuelle Website lockern. Weitere Reparaturschritte nehmen gezielt passende Regeln zurück. Die Website ganz zu pausieren bleibt eine klare letzte Möglichkeit.
Eigene Auswahlregeln lassen sich vorher ansehen und wieder rückgängig machen. Mir ist wichtig, dass eine Reparatur nachvollziehbar bleibt und nicht heimlich den Schutz auf anderen Websites verändert. Auch Einstellungen und gelernte Regeln sollen sich lokal sichern lassen.
Mehr Sprachen, ohne die besuchten Seiten zu melden
Im aktuellen Build ergänze ich die internationalen Filter um lokale Sprachpakete. Die Auswahl kann sich nach den Gerätesprachen richten. Ein Besuch auf einer Website löst dafür keinen spontanen Paketdownload aus. Die Auswahl und besuchte Websites werden nicht an mich geschickt.
Reguläre Filterupdates brauchen weiterhin eine Verbindung zu den öffentlichen Quellen. Bewusst angelegte Problemmeldungen bleiben dagegen im aktuellen Produkt lokal. Einen aktiven Meldedienst gibt es noch nicht.
Ein Entwicklungsstand mit klaren Grenzen
Die derzeitige Testfassung trägt 1.0.0, Build 2. Die Bilder hier zeigen den Aufbau der App und das Safari-Popup aus dem iPhone-Simulator. Vor einer öffentlichen Veröffentlichung muss ich weitere Geräte und echte Safari-Situationen prüfen.
Besonders bei Videoanzeigen gibt es keine einfache Zusage für alle Anbieter. Bestimmte Anzeigen lassen sich entfernen, andere höchstens ruhig überbrücken. Die unvermeidbare Wartezeit verschwindet dadurch nicht. Ich möchte die Grenzen zeigen und die einzelnen Abläufe besser machen, statt eine perfekte Erkennung zu versprechen.
