Weitere Überlegungen zur Sperre von Kinderpornographie im Internet.

(Sorry, daß es etwas gedauert hat, ich war zwischendurch verreist.)

Im ersten Teil wurde die Frage untersucht, welche Probleme sich ergeben, wenn – wie es das Zugangserschwerungsgesetz vorsieht – eine Liste fester URLs gegeben ist und gesperrt werden soll. Es wurde unterstellt, daß jeder unzulässige Inhalt – Text, Bild, Video, was auch immer – einen festen, eindeutigen URL hat, den man in eine Liste aufnehmen kann, nach der man Zugriffe selektiv sperren kann, ohne die zulässigen Inhalte – wenn man beispielsweise legale politische Äußerungen oder legale Pornographie von verbotener Kinderpornographie im selben Forum abgrenzen will – zu beeinträchtigen. Schon da ergaben sich erhebliche technische Probleme.

Aber ist die dem Gesetz zugrundeliegende Annahme, daß sich jeder Inhalt durch einen URL eindeutig identifizieren läßt, überhaupt richtig? Nein.

Andere Protokolle als HTTP

Im Rahmen der Diskussion um die Kinderpornosperre wurde aus der Politik die Meinung geäußert, daß jede Datenübertragung im Internet auf einem URL – oder allgemeiner einem URI – beruht. Das ist so nicht richtig.

Nur wenige Protokolle, hauptsächlich HTTP und HTTPS, sind explizit auf die Verwendung von URLs ausgelegt. Viele alle Protokolle verwenden keine URLs, und man sollte sich bewußt machen, daß URLs erst mit dem World Wide Web eingeführt wurden, das Internet und manche seiner Protokolle aber schon viel älter sind, also nicht auf URLs beruhen können.

Freilich hat man URLs bzw. URIs so allgemein formuliert, daß man auch die Identifikationsangaben vieler dieser anderen oder älteren Protokolle als URL schreiben kann. Ein schönes Beispiel ist FTP. Auch da kann man den Server und den Pfad der Datei zusammen als URL schreiben und die Datei damit – mehr oder weniger, im Rahmen der hier und im ersten Teil vorgestellten Problematik – identifizieren. Daß man das als URL schreiben kann, heißt aber noch nicht, daß das Protokoll das auch so verwendet. Bei einem FTP-Zugriff tauchen die im URL angegebenen Daten nicht so zusammen auf, daß man dies als URL filtern könnte. Aus dem URL die FTP-Zugriffsdaten zu bestimmen, ist einfach. Aus dem FTP-Zugriff aber wieder den URL zusammenzusetzen, um damit auf die Sperre zu prüfen, ist weitaus schwieriger. So taucht bei einem FTP-Zugriff der Hostname, auf den der Client zugreift – anders als bei HTTP – im Protokoll nicht mehr auf. Auch der Pfad der Datei selbst taucht nicht in einem Stück auf. Der Client sendet dazu Change-Working-Directory-Befehle

CWD pub

und der Server antwortet nur mit einer Bestätigung ohne nähere Angabe:

250 Directory successfully changed

Der Client muß dabei nicht direkt in das Zielverzeichnis springen, sondern kann das Schritt für Schritt, Verzeichnis für Verzeichnis, tun, und dabei auch andere Verzeichnisse besuchen, wie man sich eben in einem Dateibaum bewegt. Das heißt aber, daß ein Filter, der das Protokoll überwachen soll, die ganze Zeit über alle diese Schritte mitlesen und mitinterpretieren müßte um zu sehen, in welchem Verzeichnis sich der Benutzer gerade bewegt. Aber selbst das wäre nicht eindeutig. Angenommen, ein Bild unter dem Pfad /a/bild.jpg wäre auf der Sperrliste. Wäre auf dem Server einfach ein logischer Link von /b/c nach /a angelegt, würde man dasselbe Bild auch unter /b/c/bild.jpg zugreifbar. Die Sperre würde also nicht greifen. Würde das Verzeichnis noch einen Link namens d auf sich selbst enthalten, könnte man das Bild auch unter /b/d/d/d/d/c/bild.jpg ansprechen usw. Und dabei wurde – vgl. die nachfolgenden Abschnitte – noch nicht einmal in die Funktion des Servers selbst eingegriffen.

Bei Zugriffen auf News-Server via NNTP könnte man beispielsweise bestimmte Message-IDs sperren. Schwieriger würde es aber schon, wenn Kinderpornos über eine Mailbox per Pop oder IMAP verteilt werden. Da ist das nicht mehr so einfach, eine bestimmte Nachricht zu identifizieren, was den Request angeht. Zwar haben auch Mails in der Regel eine Message-ID, aber die muß weder zwingend da noch eindeutig sein.

Die Annahme, daß das ganze Internet auf URLs basiere, ist unrichtig und beruht auf einer Sichtweise, die sich auf den Umgang mit Web-Browsern, Web-Mailern usw. beschränkt.

Benutzerspezifisches

Wer sagt, daß jeder Benutzer unter /a/bild.jpg immer das gleiche Bild sieht? Viele Protokolle erlauben es, sich als unterschiedliche Benutzer anzumelden, wie etwa HTTP und FTP. Und dabei können den verschiedenen Benutzern unterschiedliche Verzeichnisse zugeordnet werden. Es kann also sein, daß Hinz unter /a/bild.jpg etwas ganz anderes zu sehen bekommt, als Kunz. Im Prinzip können unterschiedliche Accounts sogar denselben Namen haben und sich nur durch die Passworte oder andere Authentifikationsmethoden unterscheiden, etwa One-Time-Passworte, Kerberos-Tickets, OpenID oder ähnliches.

Wie sollte man in diesem Falle den URL darstellen? Zwar unterstützt die URL-Schreibweise auch die Angabe von Benutzernamen und Passwörtern, aber das erhöht die Komplexität erheblich. Wenn sich der Benutzer beispielsweise einloggt, dafür ein Cookie bekommt und zunächst auf legale Inhalte zugreift, und erst später auf illegale Inhalte, müßte der Filter den Login-Vorgang abhören, die Semantik der Cookies verstehen (woran erkennt man schließlich, daß ein Cookie den Benutzer identifiziert?) und dann beim Zugriff auf weitere Inhalte den Zugriff in Kontext zum Benutzer setzt. Man müßte außer den Benutzerdaten auch noch detaillierte Angaben über die Session-Authentifikation haben.

Multiple Pfade

Im Normalfall bezeichnet ein URL meist eindeutig – für gewisse Zeit – irgendwelche Daten, Inhalte usw. Das ist der Zweck des URLs. Der Umkehrschluß, daß zu einem Datum – Text, Bild, usw. – eindeutig ein URL gehört, ist falsch. Wie schon im ersten Teil (Beispiel der Rewrite-Regel für Apache) beschrieben wurde, kann man sehr leicht zu einem Inhalt beliebig viele URLs generieren, die ein Sperren per Liste unmöglich machen. Auch andere Mechnismen, wie DNS-Wildcards, mit denen der Client den Servernamen beliebig wählen kann, machen es unmöglich, den Inhalt mit einem einzigen URL zu sperren.

Dynamisch erzeugte Inhalte

Welches Bild würde man auf einem Server unter dem Pfad /image-of-the-day.html erwarten? Eben. Jeden Tag ein anderes.

Viele Webserver beruhen heute nicht mehr auf statischen Inhalten, sondern erzeugen die Inhalte dynamisch. Das heißt, daß zu einem angefragten URL nicht eine Datei auf der Festplatte herumliegt und so herausgegeben wird, wie sie ist, sondern daß Software die Inhalte erzeugt. Dieses Blog hier arbeitet beispielsweise so. Und solche Software ist durchaus nicht gezwungen, zu einem URL immer dasselbe zu liefern.

Man kann etwa aus einem Vorrat von Bildern, nehmen wir an, eine Mischung aus legalen und illegalen, ein zufällig gemischtes Album erzeugen. Das könnte darauf hinauslaufen, daß alle Bilder unter demselben URL auftauchen, und man bei jedem Abruf das nächste bekommt. Oder daß unter /a/bild155.jpg ein Benutzer ein legales, ein anderer Benutzer ein illegales Bild sieht.

Das ist auch nicht auf Zufall beschränkt. Man kann beispielsweise auch die Quell-IP-Adresse des Benutzers, die Uhrzeit, das Land, den Provider, den Browser usw. in die Erzeugung mit einbeziehen. Man könnte etwa einen Server so konfigurieren, daß Kinderpornos nur außerhalb der normalen Dienstzeiten deutscher Behörden wie des BKA angezeigt werden. Oder nur für IP-Adressen in Ländern, in denen der Konsum nicht effektiv verfolgt wird. Oder den Referer-URL miteinbeziehen, daß man die Bilder nur dann sieht, wenn man von einer bestimmten anderen Webseite kommt.

Der Phantasie sind dabei kaum Grenzen gesetzt. Und wenn man unterstellt, daß Kinderpornographie ein kommerzieller, gar Milliardenmarkt sei, dann muß man auch davon ausgehen, daß die Anbieter das Wissen haben und den Aufwand treiben, solche Kunststückchen einzubauen und URL-Sperrlisten damit auszuhebeln.

Navigation über andere Mechanismen

Eine Variante der dynamischen Pfade ist die Navigation über andere Mechanismen als den URL. Dazu gibt es viele Möglichkeiten:

• Navigation über die Parameter, wie etwa /zeige.html?bildnr=153. Da man da noch beliebig viele andere, irrelevante Parameter einfügen und deren Reihenfolge ändern kann, läßt sich das nicht mehr mit einem einzelnen URL darstellen.
• Navigation über Cookies, etwa derart, daß man immer unter demselben Pfad /bild.jpg durch eine Sammlung von Bildern iteriert und als Zähler ein Cookie agiert.
• Navigation über Formulareingaben per PUT oder POST
• Navigation über den Referrer
• Navigation über graphische Eingaben

Und so weiter, und so weiter.

Quintessenz

Man kann Inhalte im Internet nicht selektiv über eine Liste von URLs sperren, wenn der Anbieter mehr Aufwand als nur die einfache Grundinstallation eines Webservers unternimmt. Das Konzept einer URL-Sperrliste setzt voraus, daß Web-Inhalte im einfachen Standard-Betrieb angeboten werden.