Gerade wird uns die Diskussion um Kinderpornographie und Kinderschändung im und durch das Internet wieder von allen Seiten und mit enormem Presse- und Mediendruck um die Ohren gehauen.

Dazu einige Anmerkungen von mir aus technischer, praktischer und informationstheoretischer Sicht, warum das alles so, wie man es verlangt oder der Öffentlichkeit weismachen will, nicht möglich ist.

Innocence in Danger, BILD, FAZ, RTL II bombardieren uns mit einem Dauergeprassel des Themas Kinderpornographie und Kindesmißbrauch im und durch das Internet. Es erweckt alles den starken Eindruck, daß es sich um eine konzertierte Aktion zur Beeinflussung der öffentlichen Meinung handelt, nachdem der erste Anlauf zu Kinderpornosperren in Internet zur blamablen Bauchlandung geriet, was im wesentlichen an der öffentlichen Meinung lag, die man jetzt weichklopfen will. Und wie das heute bei uns in Politik, Gesellschaft und Zeitgeist so üblich ist, spielen Meinungsmache, politische Interessen und Personennetzwerkerei eine große, die Sachkunde dagegen nur eine sehr untergeordnete Rolle. Inkompetenz ist heute nichts mehr, dessen man sich schämen müßte. Es gilt heute als modern und durchsetzungsfähig, Entscheidungen zu treffen, die nicht von Realität getrübt sind.

So hat etwa Ursula von der Leyen in ihrer denkwürdigen Rede vor dem Bundestag vom 26.3.2009 (Plenarprotokoll 16/214) gesagt:

Das erste Argument lautet: technisch unmöglich. Wir haben es heute wieder in verschiedenen Varianten gehört. Aber wenn dieselben Telefongesellschaften, die auch hier in Deutschland sind, dies in Schweden, in Finnland, in Norwegen, in Dänemark, in Großbritannien, in der Schweiz und sogar in Italien umsetzen können, dann ist die Behauptung, das sei technisch unmöglich, ein krachendes Unfähigkeitszeugnis für Deutschland. Das sollten wir uns nicht ausstellen.

(Beifall bei der CDU/CSU sowie bei Abgeordneten der SPD)

Gerade heute erst meldet der Heise Newsticker von den Medientagen in München:

Der bayerische Ministerpräsident Horst Seehofer (CSU) hat sich zum Auftakt der Münchner Medientage für Netzsperren ausgesprochen. Das Sperren und Löschen von Seiten mit kinderpornographischen Inhalten sei international ein wichtiges Anliegen, meinte Seehofer in seiner ersten medienpolitischen Rede zum Start des dreitägigen Gipfeltreffens der Medienbranche. “Die fehlende Koordination und Technik ist keine Legitimation für die Gefährdung unserer Kinder”, sagte der bayerische Regierungschef mit Blick auf die Gegner der Sperren.

Es wird nicht gefragt, ob Sperren überhaupt effektiv möglich sind. Es wird einfach behauptet, als ob man politisch befehlen und herbeischimpfen könnte, was technisch möglich ist.

Ich möchte deshalb in einer losen Folge von Blog-Artikeln beleuchten, ob das so möglich ist, wie es da einige Politiker fordern. Daß speziell die DNS-Sperren nicht so wirken, wie man das will, sondern praktisch wirkungslos sind, ist inzwischen hinreichend öffentlich bekannt und erschöpfend diskutiert, und bedarf keiner weiteren Betrachtung. Ich werde daher auf DNS-Sperren nicht eingehen.

Hier im 1. Teil möchte ich deshalb eine andere Sperrmethode betrachten, die mitunter gefordert wird oder sich auf den ersten Blick als Alternative anbietet, nämlich das Erkennen der URLs in HTTP-Anfragen durch einen Internet-Provider mittels Deep Packet Inspection, also der Analyse der Nutzlast von IP-Paketen (oberhalb der TCP/IP-Ebene, hier also der HTTP-Anfragen), und dem Vergleich mit einer vorgegebenen Liste von zu sperrenden Webseiten oder -bildern, etwa wie sie vom Bundeskriminalamt verteilt werden sollte. Zu einer solchen Sperre müßte man greifen, da die Diskussion um DNS-Sperren ja bereits ergeben hat, daß eine Sperre des ganzen Webservers anhand seines Namens oder gar der IP-Adresse die große Gefahr mit sich bringt, noch andere – legale – Inhalte oder gar andere virtuelle Server zu sperren und damit beispielsweise in geschützte Grundrechte wie die Meinungs- und Pressefreiheit einzugreifen. Zudem soll die BKA-Sperrliste ja auch nicht nur Hostnamen, sondern ganze URLs enthalten, was auf eine über DNS hinausgehende Sperrmethode hinausläuft, also eben URL-Sperren.

Die zu betrachtende Frage ist also, ob ein Internet-Provider zuverlässig den HTTP-Verkehr überwachen und dabei Zugriffe auf unerlaubte Inhalte anhand einer URL-Blacklist erkennen und unterbinden kann.

Verschlüsselung

Die erste Frage ist natürlich, wie der Provider – oder wer immer die Sperrung vornehmen soll – mit Verschlüsselung umzugehen hätte. Denn an Stelle eines HTTP-Servers einfach einen HTTPS-Server zu verwenden, bietet sich an und ist nicht schwierig umzusetzen. Ohne aktiv in die Verschlüsselung einzugreifen kann man die URLs nicht auslesen, das ist Sinn, Zweck und Funktion der Verschlüsselung. Also fällt ein unmittelbares URL-Filtern schon aus.

Eine Möglichkeit wäre, jede HTTPS-Verbindung zu einem solchen Server zu unterbinden, was aber grundsätzlich wieder das Problem mit sich bringt, daß man möglicherweise legale Inhalte sperrt (auch wenn die Gefahr deutlich geringer als bei HTTP ist, weil sich die Erweiterung des Protokolls auf virtuelle HTTPS-Server nicht durchgesetzt hat und deshalb keine virtuellen HTTPS-Server in Gebrauch sind). Man könnte also nicht die verfassungsrechtlich gebotene enge Einschränkung auf verbotene Inhalte einhalten.

Eine andere Variante wäre, aktiv in die Verschlüsselung einzugreifen. Grundsätzlich ist sowas möglich und gehört zum Standard-Repertoire von Security-Workshops. In jedem Browser gibt es eine längere Liste von Root-CAs, deren Zertifikaten vertraut wird. Da auch der ein oder andere deutsche Provider eine in den Browsern verankerte CA hat, könnte man prinzipiell das Zertifikat von HTTPS-Servern unbemerkt fälschen und sich in den Datenverkehr einschalten. Auch das bringt aber erhebliche Probleme mit sich. Man müßte den gesamten Datenverkehr umleiten und auf den oberen Applikationsschichten (SSL, HTTP, Webserver) einen transparenten Proxy einbauen, der entsprechend filtert oder durchläßt. Das allerdings wäre ein sehr tiefer und auch sehr aufwendiger Eingriff in den IP-Verkehr. Der Provider wäre im Prinzip nicht mehr Provider, und die Glaubwürdigkeit von Zertifikaten wäre noch weiter untergraben, als sie es schon ist.

Und wenn sich bei der Analyse herausstellt, daß der Client hier eben keine verbotene, sondern eine erlaubte Seite abgerufen hat, dann hat man – unzulässigerweise – massiv in legale Kommunikation eingegriffen.

Und würde sich der Client per eigenem Zertifikat gegenüber dem Server authentifizieren, würde das auch nicht funktionieren. Zwar könnte der transparente Proxy auf selbst auf die Client-Authentifizierung verzichten oder die Prüfung unterlassen. Im Falle einer legalen Anfrage könnte der Proxy die Anfrage aber nicht mehr an den echten Server durchreichen, es käme zu einer Funktionsstörung.

Eine Vorgehensweise ohne technische Störungen und ohne rechtswidrige Manipulation legaler Zugriffe sehe ich dabei nicht. Dabei ist zu bedenken, daß es bisher relativ wenige verschlüsselte Webserver gibt, weil es bisher keine Virtualisierungstechnik gibt, die sich allgemein durchgesetzt hat und breit unterstützt wird. Deshalb kann auf einem Port und einer IP-Adresse nur ein Server und nicht beliebig viele Server laufen. Außerdem kosten offizielle Zertifikate meist Geld. Setzt sich aber erst einmal IPv6 durch, kann man jedem virtuellen Server eine eigene IP-Adresse geben und damit im großen Maßstab verschlüsseln, es dürfte also in Zukunft mit IPv6 deutlich mehr verschlüsselte Webserver geben – falls wir nicht in eine Krypto-Verbot laufen.

Gehen wir nachfolgend aber weiter von unverschlüsselten, normalen HTTP-Verbindungen aus.

URL-Variationen

Nehmen wir also an, wir haben normalen, unverschlüsselten HTTP-Verkehr, und der Provider könnte daraus den angefragten URL ablesen. HTTP funktioniert so, daß der Client nach Aufbau der TCP-Verbindung dem Server einen Request schickt, und der Server dann darauf antwortet. In diesem Request sind die verschiedenen Teile des URLs enthalten, aber funktional aufgetrennt, u.a. in den Hostnamen (damit der Server erkennen kann, welcher virtuelle Server angesprochen ist) und den Pfad-Teil des URL. Eine Anfrage nach https://www.danisch.de/blog/ könnte also (etwas verkürzt) so aussehen:

GET /blog/ HTTP/1.1
Host: www.danisch.de
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml,application/xml ...
...

Der Provider könnte als durch ein Mitlesen der Nutzlast der IP-Pakete (zu Problemen hierbei siehe unten) den vorderen Teil des URL mit dem Hostnamen aus der Host:-Zeile und den hinteren Teil, den Pfad, aus der GET-Befehl herauslesen, zusammensetzen und gegen eine Liste von zu sperrenden Webseiten vergleichen. Diese Listen sollen typischerweise bis zu 10.000 Einträgen enthalten, und sie beruhen auf der Annahme, daß eine Webseite immer einen eindeutigen URL hat.

Das ist aber nicht der Fall. Zu einem URL kann man normalerweise eine Vielzahl äquivalenter, aber anderslautender URLs angeben, die dann nicht mehr mit der Liste übereinstimmen würden. Ohne überhaupt etwas am Server zu ändern (der Betreiber des Servers muß sich also nicht einmal daran beteiligen oder davon wissen) ist die Ersetzung von Zeichen im URL durch die Hex-Schreibweise, die in URLs auch zulässig ist. Diese ist zwar eigentlich dafür gedacht, auch die Zeichen in einem URL anzugeben, die dort syntaktisch nicht reinpassen oder anderweitig Durcheinander verursachen könnten, aber funktioniert mit jedem beliebigen Zeichen. Statt des Zeichens wird einfach ein Prozentzeichen mit der Hexadezimaldarstellung des Zeichencodes eingefügt. Man kennt das von URLs mit Beizeichnungen mit Nicht-ASCII-Zeichen. Als die Browser noch nicht so gut UTF-8 konnten, haben sie beispielsweise Umlaute oft so dargestellt. Und so kann man das natürlich auch mit anderen Zeichen machen. Betrachten wir als Beispiel den URL

https://www.danisch.de/blog/

Das kleine g am Ende des URLs hat in ASCII (oder im UTF-8) den Zeichencode 103, Hexadezimal 67. Wir können das g also durch %67 ersetzen:

https://www.danisch.de/blo%67/

Manche Browser (beispielsweise ein aktueller Firefox) zeigen den Link, wenn man mit der Maus drüberstreicht, sogar wieder in Normalschreibweise an, sieht also zunächst aus wie ein g. Betrachtet man sich aber den Netzwerkverkehr, dann sieht man, daß der Browser tatsächlich /blo%67/ im GET-Befehl angegeben hat. Trotzdem hat der Server die richtige Seite geliefert, weil er das zunächst dekodiert und dann erst bearbeitet. Ein Vergleich mit einer Sperrliste mit dem normalen URL wäre also schon fehlgeschlagen, wenn der Provider nur unverändert vergleicht.

Man könnte zu jedem Zeichen des Pfades im URL frei wählen, ob man es normal oder in der %-Schreibweise angibt. Ist der Pfad nach dem ersten / noch n Zeichen lang, kann man auf diese Weise also 2ⁿ äquivalente URLs erzeugen, die nicht mit dem Original-URL übereinstimmen, aber trotzdem funktionieren. Besteht der Pfad dabei aus 41 Zeichen einschließlich des führenden /, hätte man 2⁴⁰, also ungefähr eine Billion verschiedener URLs für dieselbe Seite (Nicht jedes Programm verträgt es, auch das erste / so umzuwandeln, aber auf einen mehr oder weniger kommt es uns hier nicht an). Das heißt, daß der Provider nicht einfach nur mitlesen kann, sondern vor dem Vergleich den URL normalisieren muß, was beispielsweise bei der hohen Last im Feierabend-Web-Verkehr ziemlich viel Rechenleistung erfordert. Bei manchen älteren Webservern kann man sogar noch mehr Kombinationen finden, indem man redundante UTF-8-Kodierungen verwendet (mehr Byte verwenden als nötig).

Es geht aber noch mehr, wenn der Serveradministrator mitspielt. Man kann ohne weiteres, etwa unter Apache mit dem RewriteRule-Befehl, Teile aus dem URL herausschneiden, so würde

 
RewriteRule ^/schlechte/[0-9a-zA-Z]+/bilder/(.*)$ /schlechte/bilder/$1 [L]

dafür sorgen, daß der Benutzer eine beliebige Zeichenkette aus Ziffern und Buchstaben zwischen /schlechte/ und /bilder/ einfügen kann. Also ein Bild, das normal unter /schlechte/bilder/dreck.jpg liegt auch unter /schlechte/434238924/bilder/dreck.jpg zu finden ist. Und dann hilft auch die Normalisierung nicht mehr, weil der Provider nicht mehr erkennen und entscheiden kann, ob die beiden URLs wirklich äquivalent sind und die Sperre für beide gilt. Damit kann man sich beliebig viele verschiedene URLs ausdenken, die zum Ziel führen, und alle (bis auf die Normaldarstellung) nicht zu sperren sind, sofern man nicht den gesamten Server sperren möchte. Der Phantasie beim Aufbau der URLs und der Umsetzungsregeln sind praktisch keine Grenzen gesetzt. Eine Sperrliste als Blacklist läuft damit zwangsläufig ins Leere.

Fragmentierung und Speicherung

Kommen wir nochmal auf die Struktur eines HTTP-Requests (also die Anfrage, die der Browser an den Server schickt, worauf dieser antwortet) zurück. Die könnte also so aussehen:

GET /schlechte/bilder/dreck.jpg HTTP/1.1
Host: www.kinderpornoserver.de
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml,application/xml ...
...

und nehmen wir mal an, daß der URL dazu in der Sperrliste stünde: http://www.kinderpornoserver.de/schlechte/bilder/dreck.jpg .

Nun ist das Internet aber paketorientiert. Ein Datenstrom wird nicht kontinuierlich (wie z. B. bei ISDN) übertragen, sondern in lauter kleine Pakete, die Internet- oder IP-Pakete aufgeteilt, und beim Empfänger wieder zusammengesetzt. Das Protokoll und die Funktionseinheit, die für dieses Zerlegen und Zusammensetzen zuständig sind, nennt man TCP. Und weil IP und TCP in den allermeisten Fällen zusammen verwendet werden (auch bei solchen Webzugriffen) nennt man das kurz auch TCP/IP.

In den meisten Fällen darf so ein Paket maximal ungefähr 1.500 Byte groß sein. Manchmal auch etwas weniger. Ein gewöhnlicher einfacher HTTP-Request, ohne zusätzlichen Schnickschnack oder einen Haufen Cookies paßt normalerweise in ein einzelnes Paket. Deshalb kommt dieser Request meistens in einem Stück, in einem Paket beim Provider vorbei. Deshalb glauben viele, daß man das so einfach erkennen könnte.

Man muß das aber nicht so schicken. Man kann die Pakete auch entsprechend kleiner wählen, so daß der Header nicht mehr in einem Stück übertragen wird:

• Man kann die MTU (Maximum Transmission Unit, maximale Paketgröße) heruntersetzen, und damit kleinere Pakete oder eine Fragmentierung der Pakete auf Schicht 3 herbeiführen, damit der Request auf mehr als ein Paket verteilt wird.
• Man kann die TCP-MSS (Maximum Segment Size) oder die Pufferlänge so manipulieren, daß der Rechner die Daten in kleineren Portionen, also auch wieder verteilt auf mehrere Pakete, versendet.
• Man kann auf Software-Ebene dafür sorgen, daß der Request nicht in einem Stück versandt wird. Im Prinzip kann man jedes einzelne Zeichen im Request in einem separaten IP-Paket senden. (Quasi als ob man in einer Terminal-Sitzung einzelne Tasten drückt.)

Man kann damit also im einfachsten Fall dafür sorgen, daß der Hostname und der Pfad nicht mehr im selben IP-Paket übertragen werden, oder daß sogar der Pfad oder der Hostname selbst auf mehrere Pakete verteilt werden.

Die Konsequenz daraus ist, daß der Provider bzw. dessen Filtereinrichtungen den angefragten URL nicht mehr anhand eines einzelnen Paketes und damit nicht mehr auf einfache Weise erkennen können. Die Sperreinrichtung des Providers muß also Pakete speichern, sie defragmentieren, und den Strom auf TCP-Ebene zusammensetzen, um den vollständigen URL zu erkennen. Also praktisch den TCP-Stack eines Betriebssystems nachahmen.

Und das ist anfällig gegen Denial-of-Service-Angriffe. Denn die Sperreinrichtung muß IP-Pakete oder zumindest deren Nutzlast zwischenspeichern, bis sie den URL zusammengesetzt hat und ihn prüfen kann, ob sie ihn sperren will oder nicht (wobei man sich fragen kann, was sie bis dahin mit dem aufgelaufenen Verkehr macht, ob sie ihn schon mal an den Server weiterleitet und dann im Falle verbotenen Zugriffs die Verbindung nachträglich kappt, oder sich als Server ausgibt, in dessen Namen antworten und dann in der Bredouille ist, wenn es doch legal war). Der Sperrfilter muß jedenfalls alles vom GET-Befehl bis zum Ende des Host:-Eintrages speichern bis er entscheiden kann, ob er sperrt oder nicht.

Und Speicher ist endlich. Irgendwann ist der voll und dann fallen Verbindungen hinten runter. Man könnte das provozieren, indem man ganz viele Verbindungen aufmacht und nur einen Teil des Requests schickt. Der Sperrfilter wäre gezwungen zu warten, bis der Request vollständig vorliegt. Da man eine TCP-Verbindung, wenn man es drauf anlegt, auch stunden- oder tagelang aufrecht erhalten kann, müßte der Filter die Pakete auch so lange speichern, weil er ja nie weiß, ob es ja noch weitergeht oder das nur ein Bluff war.

Und ein Filter kann eben zu vertretbarem Preis nicht genug schnellen Speicher haben, um die – beispielsweise im Feierabendwebverkehr eines großen Providers – bei voller Bandbreite alle diese Pakete aufzuzeichnen und so lange vorzuhalten bis klar ist, ob gesperrt wird oder nicht.

Der Client könnte also einfach ganz viele TCP-Verbindungen (notfalls mit einem Paketgenerator am Betriebssystem vorbei) aufmachen und jeweils den Request nur halb senden. Und wenn er ganz viele offen hat, und davon ausgehen kann, daß der Speicher des Filters voll ist, sucht er sich zufällig eine der angefangenen Verbindungen heraus, mit der er weiter macht. (Setzt natürlich voraus, daß der Server entsprechend vorbereitet ist und die überzähligen Verbindungen verwirft.)

Ein drastisches Beispiel dazu:

Wir gehen mal von IPv6 aus. Wir unterstellen, daß sowohl der Client, als auch der Server jeweils ein /48-Netz haben, und damit jeweils 128-48 = 80 Bit der IP-Adresse zur freien Verfügung haben. Nehmen wir weiter an, daß der Server auf allen diesen Adressen (durch NAT) gleichzeitig hört oder – besser noch – auf einer davon hört und auf den anderen Adressen ein Dummy lauert, der zu jeder TCP-Verbindung das Protokoll vorgaukelt, ohne daß es da einen echten Webserver gäbe.

Nun könnte der Client mit jeder seiner 2⁸⁰ Adressen mit jeder seiner 2¹⁶ Client-Ports jede dieser 2⁸⁰ Empfänger-Adressen ansprechen, könnte also theoretisch 2¹⁷⁶ TCP-Verbindungen vorgaukeln, was in der Realität und im Rahmen seiner Bandbreite darauf hinausläuft, daß er nur so zum Spaß ein paar Stunden lang TCP-Verbindungen aufbaut bzw. simuliert, und damit den schnellen Hauptspeicher einer solchen Filtermaschine überlastet. Selbst wenn das Ding einen riesigen Hauptspeicher hätte (RAM wohlgemerkt, Platte ist zu langsam), könnte bei den heutigen Bandbreiten schon ein einziger Benutzer/Kunde in kurzer Zeit den Speicher vollblasen und die Sperrfunktion damit außer Funktion setzen. Und man könnte ihm daraus nicht einmal einen Vorwurf machen, weil der Benutzer/Kunde in diesem Fall nur normale, reguläre IP-Pakete versendet. Ob die tatsächlich in den oberen Schichten Sinn ergeben oder willkürlich gesetzt sind, ist Sache des Kunden, das kann der machen, wie er will. Sowas ist formal kein Angriff, solange Sender und Empfänger damit einverstanden sind. Ganz normaler IP-Verkehr.

Fazit

Ich kenne keine Methode, auf zuverlässige, nicht angreifbare und nicht zu umgehende Weise auf Provider-Ebene URLs nach Art einer Blacklist zu sperren. Und dabei haben wir noch nicht einmal das Protokoll selbst verändert, sondern uns bisher brav an die politische Annahme gehalten, daß Pornokonsumenten alle standardkonformes HTTP sprechen. Schon wenn man den Server nur auf einen andere Port als 80 legt, wird das ganze schon dahingehend schwierig, daß man nicht mehr ordentlich erkennt, ob es da überhaupt um HTTP oder was auch immer handelt.

Bevor ich mir allerdings den Tadel „krachend unfähig” anheften lasse, wie es unsere Ministerin von der Leyen zu formulieren beliebte, müßte man mir zunächst belegen, wie Schweden, Finnen, Norweger, Dänen, Briten, Schweizer und Italiener das besser machen.

In der Diskussion bisher zeigte sich, daß einige dieser Länder eine noch einfachere und wirkungslosere DNS-Sperre probieren, was kaum mehr als Kosmetik ist.

In Italien scheint man ganze IP-Adressen zu blockieren, was zwar grundsätzlich funktioniert, aber eben zu dem verfassungswidrigen Zustand führt, daß man auch legale Inhalte desselben oder anderer virtueller Server mit sperrt. Und ob man dann bei IPv6, wenn ein Server vielleicht unter beliebig vielen Adressen eines /48-Netzes erreichbar ist, das ganze /48 sperrt, wäre auch die Frage. Diese Quelle hingegen legt nahe, daß man sich nicht auf eine Methode festgelegt hat, sondern das einfach mal per Gesetz vorgeschrieben und es den Providern überlassen hat, eine Lösung zu finden. Was natürlich die von der Leyen’sche Aussage ad absurdum führt, wonach die Italiener technisch besser wären als die Deutschen. Wobei sich ja inzwischen mehrfach herausgestellt hat, daß Frau von der Leyen es mit Realität und Technik nicht so genau nimmt, wenn sie lospoltert. Der Zweck heiligt die Rhetorik.

Bekannt ist auch, daß einige Mobilfunkprovider, auch in Großbritannien, über ihre Zwangs-Web-Proxies filtern. Das ist natürlich deutlich effektiver, aber es ist kein „Internet-Zugang” im eigentlichen Sinne. Und durch die oben beschriebenen DoS-Angriffe und URL-Variationen verwundbar, besonders unter IPv6. Allerdings sind hier die hohen Nutzungskosten und niedrigen Bandbreiten das, was die durch Begrenzung noch rettet. Auf normale Festnetzanschlüsse ist das nicht übertragbar.

Auch das britische System scheint auf Trigger-URLs zu beruhen, also angreifbar zu sein, und nach diesem Text ohnehin eher dazu gedacht, die Regierung zu beruhigen, als wirklich effektiv zu blockieren. Zumal nicht klar hervorgeht, wie der Filter genau funktioniert, aber das dürfte auch gegen die hier beschriebenen Maßnahmen nicht resistent zu sein. Verschlüsselte Verbindungen oder variierende URLs bekommen die damit auch nicht erfaßt.

Laut 3Sat steht die Wirksamkeit der Filter in diesen Ländern in Frage, und viele kommen gar nicht erst über die kosmetischen DNS-Blockaden hinaus, blockieren also gar nicht, sondern tun nur so als ob, um der Politik die gewünschten potemkinschen Sperren vorzugaukeln.

Ich sehe daher derzeit keine Methode, die zuverlässig und störungsfrei sperrt, und auch kein Land, das das tut, sofern man grundsätzlich am Internetzugang festhält. Die Brachialmethode wäre natürlich, den Leuten kein echtes Internet mehr zu gestatten, also Internet zu verbieten.

Derzeit plane ich zwei weitere Teile zu dem Thema, einen über das Blocken von Inhalten (Bildern blocken, nicht URLs) und einen über verbotene Inhalte auf Festplatten.