Sioni Content Blocker – warum ich meinen eigenen Schutz für Windows entwickelt habe

Werbung im Internet nervt mich. Aber eigentlich ist Werbung längst nicht mehr der Punkt, der mich am meisten stört.

Es sind Tracker, Telemetrie, Phishing-Seiten, bekannte Schadsoftware-Domains, Scam-Seiten und all die unsichtbaren Verbindungen, die im Hintergrund stattfinden, während man einfach nur seinen Rechner benutzen möchte.

Gleichzeitig verändert sich die Welt der klassischen Werbeblocker. Browserhersteller bestimmen immer stärker, was Erweiterungen dürfen und was nicht. Mit Manifest V3 wurde mir noch einmal deutlich, wie abhängig ein Browser-Blocker letztlich von der Plattform ist, auf der er läuft.

Und genau an diesem Punkt entstand die Idee hinter dem Sioni Content Blocker.

Ich wollte keinen weiteren Werbeblocker für einen einzelnen Browser.

Ich wollte einen Schutz für Windows selbst.

Nicht Chrome schützen. Nicht Firefox schützen. Den Rechner schützen.

Das war für mich von Anfang an einer der wichtigsten Gedanken.

Wenn ich meinen Browser wechsle, möchte ich nicht wieder eine neue Erweiterung installieren und konfigurieren müssen. Wenn ein anderes Programm eine unerwünschte Domain kontaktiert, bringt mir eine Browser-Erweiterung ohnehin nichts.

Also sollte Sioni eine Ebene tiefer ansetzen.

Der Sioni Content Blocker arbeitet deshalb systemweit unter Windows. Er soll unerwünschte Domains blockieren, unabhängig davon, ob die Anfrage aus Firefox, Chrome, Edge, Brave oder einem ganz anderen Programm kommt.

Keine XPI-Datei.

Keine CRX-Erweiterung.

Keine Abhängigkeit von der Erweiterungspolitik eines Browserherstellers.

Und kein separater Raspberry Pi oder Server, den ich erst aufbauen und administrieren muss.

Ich wollte etwas, das ich auf einem Windows-PC installiere, einschalte – und das dann genau dort arbeitet.

Einfacher als Pi-hole, aber mit einem ähnlichen Grundgedanken

Ich halte Projekte wie Pi-hole für sehr interessant.

Für viele normale Windows-Anwender ist so eine Lösung aber schlicht zu aufwendig. Zusätzliche Hardware, Netzwerkkenntnisse, DNS-Konfiguration und Administration sind nicht unbedingt das, womit man sich beschäftigen möchte, wenn man eigentlich nur seinen PC vernünftig schützen will.

Genau diese Lücke wollte ich mit Sioni schließen.

Der Content Blocker soll lokal auf dem Windows-Rechner arbeiten und beispielsweise bekannte Werbe-, Tracking-, Telemetrie-, Malware-, Phishing- und Scam-Domains erkennen und blockieren.

Dabei kommen gepflegte Filterquellen zum Einsatz, unter anderem Listen wie HaGeZi, ergänzt durch spezialisierte Sicherheitsquellen.

Der Benutzer soll sich aber nicht durch kryptische Listennamen und technische DNS-Begriffe kämpfen müssen.

Mich interessiert als Anwender letztlich etwas anderes:

Was schützt mich diese Einstellung eigentlich?

Genau so möchte ich die Oberfläche auch aufbauen.

Ich wollte keinen Blocker, der meinen Rechner übernimmt

Bei diesem Projekt habe ich allerdings auch gelernt, wie schmal die Grenze zwischen einem leistungsfähigen Systemwerkzeug und einer Software sein kann, die zu aggressiv in Windows eingreift.

Eine sehr frühe Version verfolgte noch einen falschen technischen Ansatz. Filterregeln wurden viel zu pauschal verarbeitet und über die Windows-HOSTS-Datei umgesetzt.

Das Ergebnis war ziemlich eindeutig:

Der Blocker blockierte.

Leider teilweise Dinge, die er überhaupt nicht blockieren sollte.

Firefox bekam Probleme, der Explorer wurde beeinträchtigt und selbst Netzwerkverbindungen konnten betroffen sein.

Für mich war damit klar:

So darf diese Software niemals funktionieren.

Die ursprüngliche HOSTS-Datei wurde vollständig wiederhergestellt und dieser technische Weg anschließend verworfen.

Seitdem gilt für das Projekt eine sehr klare Regel:

Die Windows-HOSTS-Datei bleibt unangetastet.

Das war rückblickend ein wichtiger Punkt in der Entwicklung des Content Blockers.

Nicht, weil Fehler etwas Besonderes wären. Fehler gehören zur Softwareentwicklung.

Entscheidend war vielmehr die Konsequenz daraus.

Schutz darf Windows nicht beschädigen

Ein Sicherheitsprogramm hat für mich eine besondere Verantwortung.

Wenn ein Texteditor abstürzt, ist das ärgerlich.

Wenn eine Software tief in Netzwerkfunktionen eingreift und dabei einen Fehler macht, kann plötzlich der gesamte Rechner ohne funktionierende Internetverbindung dastehen.

Auch damit musste ich mich während der Entwicklung sehr konkret auseinandersetzen.

Dadurch wurde aus einer technischen Anforderung eine meiner wichtigsten Regeln für das gesamte Projekt:

Windows muss immer funktionsfähig bleiben.

Der Content Blocker darf keinen Zustand erzeugen, aus dem der Benutzer seinen Rechner erst mühsam retten muss.

Änderungen müssen nachvollziehbar und reversibel sein. Der ursprüngliche DNS-Zustand muss bekannt sein und wiederhergestellt werden können. Fehler dürfen nicht einfach dazu führen, dass das Netzwerk dauerhaft blockiert bleibt.

Im Zweifel gilt für mich inzwischen:

Fail-open statt Internet kaputt.

Ein Content Blocker, der im Fehlerfall Werbung durchlässt, hat für diesen Moment seine Aufgabe nicht erfüllt.

Ein Content Blocker, der im Fehlerfall den gesamten Netzwerkzugang des Rechners zerstört, hat ein wesentlich größeres Problem verursacht.

Diese Unterscheidung klingt simpel. Technisch ist sie enorm wichtig.

DNS ist Technik – nicht das Produkt

Während der Entwicklung gab es außerdem eine Sache, die mir zunehmend wichtig wurde.

Ich möchte den Sioni Content Blocker nicht einfach als „DNS-Blocker“ bezeichnen.

DNS ist ein Bestandteil der technischen Umsetzung.

Der Benutzer kauft oder verwendet aber keinen DNS-Server.

Er möchte Schutz.

Genau deshalb gehören für mich mehrere Ebenen zusammen: lokales DNS-Filtering über IPv4 und IPv6, UDP und TCP, Filterlisten, eigene Listen, Allowlist, Protokollierung, Heuristiken, Wiederherstellung, Überwachung des Schutzstatus und zusätzliche Windows-Mechanismen dort, wo sie technisch sinnvoll und sicher eingesetzt werden können.

Dabei gibt es aber klare Grenzen.

Ich möchte beispielsweise keine HTTPS-Verbindungen aufbrechen und keine eigenen Root-Zertifikate auf dem Rechner installieren.

Ich möchte auch nicht heimlich Browserprofile verändern oder Netzwerkverkehr durch irgendwelche fragwürdigen Umleitungen schicken.

Sioni soll schützen.

Nicht den Besitzer seines PCs entmündigen.

Eine grüne Anzeige reicht mir nicht

Eine weitere Sache hat mich bei der Entwicklung mehr beschäftigt, als ich zunächst gedacht hätte.

Es ist erstaunlich einfach, eine Benutzeroberfläche zu bauen, auf der steht:

„Schutz aktiv.“

Daneben ein grüner Haken.

Sieht hervorragend aus.

Aber schützt das Programm wirklich etwas?

Genau das ist für mich inzwischen der entscheidende Punkt.

Wenn im Programm „Schutz aktiv“ steht, während gleichzeitig keine einzige Anfrage durch den Filter läuft und Webseiten weiterhin voller Werbung sind, dann ist diese Anzeige wertlos.

Sioni darf Schutz nicht nur behaupten.

Der Schutz muss tatsächlich stattfinden und überprüfbar sein.

Das bedeutet für mich auch, dass Statistiken, Protokolle und Statusanzeigen nicht bloß Dekoration sein dürfen. Sie müssen den realen Zustand widerspiegeln.

Ein echter Block muss ein echter Block sein.

Eine Allowlist-Freigabe muss tatsächlich greifen.

Und wenn etwas nicht funktioniert, möchte ich lieber eine klare Fehlermeldung sehen als einen hübschen grünen Status.

False Positives gehören zu den schwierigsten Problemen

Je stärker ein Blocker wird, desto größer wird auch eine andere Gefahr:

Er blockiert irgendwann etwas, das der Benutzer benötigt.

Das habe ich ebenfalls sehr konkret erlebt.

Ein legitimer Windows-Download funktionierte bei aktiviertem Sioni Content Blocker nicht mehr. Nachdem der Blocker beendet wurde, lief derselbe Vorgang problemlos durch.

Genau bei solchen Fehlern möchte ich nicht einfach ganze Dienste pauschal freischalten.

Das wäre zwar bequem, würde aber den eigentlichen Schutz immer weiter aufweichen.

Ich möchte wissen:

Welche Domain wurde blockiert?

Welche Liste war dafür verantwortlich?

Welche Regel hat gegriffen?

Gab es eine Weiterleitung?

War ein CNAME beteiligt?

Und ist die Blockierung tatsächlich gerechtfertigt?

Das ist aufwendiger.

Aber genau diese Arbeit unterscheidet für mich einen ernsthaften Content Blocker von einer Software, die einfach hunderttausende Domains sperrt und anschließend behauptet, besonders sicher zu sein.

Eine möglichst große Blockliste ist noch lange kein Qualitätsmerkmal.

Möglichst wenig Ressourcen, möglichst wenig Theater

Bei Systemprogrammen stört mich außerdem eine Sache besonders: Software, die ständig mit sich selbst beschäftigt ist.

Ein Content Blocker läuft im Hintergrund.

Also sollte er sich dort auch benehmen.

Er soll schnell starten, Filter effizient laden, möglichst wenig Arbeitsspeicher benötigen und anschließend seine Aufgabe erledigen.

Ohne permanent Fenster zu öffnen.

Ohne unnötige Animationen.

Ohne einen ganzen Zoo an Hintergrundprozessen.

Und ohne den Benutzer ständig daran erinnern zu müssen, dass er existiert.

Genau deshalb habe ich bei der weiteren Entwicklung auch viel Wert auf Ladezeiten und Speicherbedarf gelegt. Solche Verbesserungen sieht man auf einem Screenshot kaum.

Im täglichen Einsatz sind sie mir aber wesentlich wichtiger als der nächste grafische Effekt.

Sicherheit bedeutet für mich auch Kontrolle

Der Name Content Blocker klingt zunächst nach einem klassischen Werbeblocker.

Das Projekt ist inzwischen aber breiter gedacht.

Werbung ist eine Kategorie.

Tracking eine weitere.

Dazu kommen bekannte Malware-Infrastrukturen, Phishing, Scam, Telemetrie und andere unerwünschte oder gefährliche Ziele.

Trotzdem möchte ich daraus keine Blackbox machen.

Der Benutzer soll entscheiden können, wie weit der Schutz geht.

Eine Domain muss freigegeben werden können. Eigene Regeln sollen möglich sein. Unterschiedliche Schutzprofile sollen verständlich bleiben.

Und vor allem:

Aus muss wirklich aus bedeuten.

Wenn ich den Schutz abschalte, darf im Hintergrund nicht irgendein versteckter Mechanismus trotzdem weiter an meinem Netzwerk herumschrauben.

Gerade bei Sicherheitssoftware halte ich das für elementar.

Warum ich das Projekt weiterentwickle

Der Sioni Content Blocker ist eines dieser Projekte, bei denen ich während der Entwicklung meine eigenen Anforderungen mehrfach verschärft habe.

Am Anfang stand die Idee:

Werbung und Tracking systemweit blockieren.

Heute denke ich wesentlich weiter.

Wie verhindere ich, dass eine fehlerhafte Regel Windows beeinträchtigt?

Wie erkenne ich echte Schutzwirkung?

Wie gehe ich mit False Positives um?

Wie verhindere ich Umgehungen?

Wie kann ein normaler Benutzer verstehen, was gerade passiert?

Wie stelle ich nach einem Fehler garantiert einen sicheren Netzwerkzustand wieder her?

Und wie mache ich all das, ohne aus einem kleinen Windows-Werkzeug eine schwergewichtige Security-Suite zu bauen?

Genau diese Fragen machen das Projekt für mich interessant.

Mein Ziel ist eigentlich ziemlich einfach

Ich möchte irgendwann den Sioni Content Blocker auf einem Windows-Rechner installieren, den Schutz einschalten und anschließend vergessen können, dass das Programm überhaupt läuft.

Keine Werbung auf jeder zweiten Seite.

Weniger Tracking.

Bekannte gefährliche Domains werden bereits auf Systemebene gestoppt.

Kein Browser-Plugin notwendig.

Kein zusätzlicher Server im Keller.

Keine Manipulation der HOSTS-Datei.

Keine dubiosen Zertifikate.

Und vor allem kein Sicherheitsprogramm, das glaubt, mehr Rechte über meinen Computer zu haben als ich selbst.

Das ist der Anspruch.

Der Sioni Content Blocker soll nicht möglichst viel Kontrolle über Windows bekommen.

Er soll mir mehr Kontrolle über meinen eigenen Windows-PC geben.

Für mich ist das ein ziemlich großer Unterschied.

Und genau deshalb entwickle ich ihn.

Sioni Content Blocker Download: https://sioni.de/download.php?slug=sioni-content-blocker