Das Rights Protection System RPS
Um die Jahrtausendwende machte das Rights Protection System von sich reden und wurde - obwohl nur als Idee vorgetragen, heftig diskutiert.
Da das System durch einen sehr leicht verständlichen Funktionsansatz glänzt, wollen wir es hier stellvertretend für schwerer in der Wirkungsweise durchschaubare Systeme einmal näher betrachten.
Funktionsweise
Die Funktionsweise ist schnell erläutert.
Alle http-Zugriffe werden über ein RPS-Gerät geführt. Dafür sollen alle IP-Transportanbieter (gesetzlich gezwungen) Sorge tragen.
Das Gerät vergleicht nun den abgerufenen URL mit einer im Gerät gespeicherten Blacklist. Steht dieser url auf der Blacklist, wird der Verbindungsaufbau der http-Verbindung unterbrochen; steht der URL nicht auf der Blacklist, wird der Verbindungsaufbau erlaubt, die Verbindung kommt zustande.
Das System ist offenbar nicht auf Verhinderung von Urheberrechtsverletzungen beschränkt, wurde aber nur in diesem Zusammenhang diskutiert.
Die Klassifikation eines Inhaltes erfolgt hier also nicht anhand des Inhaltes sondern als Filterkriterium wird die Adresse des Inhaltes (nichts anderes ist ein uniform resource locator) herangezogen.
Die in der Diskussion immer angegebene Beschränkung auf http-urls wirkt etwas willkürlich, eine Ausdehnung auf den gesamten Adressraum, den urls aufspannen, ist sicher angemessen, denn warum sollte z.B. per ftp abrufbarer Inhalt anders als per http abrufbarer Inhalt bewertet werden?
Der Aufwand dafür läge in der gleichen Grössenordnung wie der aktuelle Aufwand für den Transport der Pakete: zwar muss das RPS-Filter sich nur einen Teil des gesamten Verkehrs (nämlich Abrufe mit http) ansehen, dazu muss es aber trotzdem komplette tcp-Verbindungen mitlesen (weil in einer tcp-Verbindung mehrere http-GETs auftreten können) und der Vergleich des abgerufenen url mit der Blacklist ist aufwendiger als z.B. der Routing-Vorgang, der auf einen Vergleich der Zieladresse des Pakete mit der Routing-Tabelle hinausläuft: IP-Adressen haben feste Längen, urls sind variabel, das macht die Aufgabe schwieriger.
Insofern liegt es nicht fern anzunehmen, dass ein RPS den apparativen Aufwand eines ISP verdoppelte. Das muss signifikante Auswikungen auf die Preise der Dienstleistung haben.
Aber dieser Aufwand allein stellt keinen Grund dar, warum der Zwang zur Anwendung des RPS eine unverhältnismässige Massnahme darstellte.
Unverhältnismässig wäre solch ein System, weil es absurd wäre.
Sehen wir uns die oben skizzierte Wirkungsweise nochmal genauer an.
Ein Uniform Resource Locator (der Name ist hier Programm: Uniformität auch für verschiedene Applikationsprotokolle, Zeiger auf eine Resource, die Daten liefert, aber nicht unbedingt eine Adresse, da nicht immer ein Speicher adressiert wird) hat die folgende Form:
protokoll://IP-Adresse/resource
Für protokoll sind dabei Werte wie http, ftp, https aber auch jederzeit neue, noch einzuführende Protokolle erlaubt. Die Applikation, die den url auswertet, muss halt nur mit diesem neuen Protokoll etwas anfangen können; bei vielen Browsern kann man z.B. über externe Programme die Behandlung von Protokollen, die im Browser-Programm nicht "eingebaut" sind, nachrüsten.
Das blaue :// ist als ein Zeichen zu sehen. Die Abfolge von Doppelpunkt und zwei Slashes trennt die Bezeichung des Protokolles von der IP-Adresse.
Die IP-Adresse kann dabei in allen denkbaren Varianten angegeben werden. die bekanntesten sind
- dotted quad, z.B. 192.168.12.42
- colon format, z.B. fe80::240:f4ff:fea8:6ab7 (IPv6 Adressen werden regelmäßig so angegeben, ist aber auch für IPv4 Adressen möglich)
- symbolische Form, die aufgelöst werden muß, z.B.
www.hase.net; hier wird der Browser (oder sonstiges Programm) dann idR. die Funktiongethostbyname()aufrufen, die dann z.B. aus dem DNS eine IP-Adresse liefert - dotted quad, hex-Ziffern, z.B. C0.A8.0C.2A (entspricht 192.168.12.42)
Weniger üblich aber möglich sind auch die Darstellung der Adresse einfach als Dezimalzahl, aus 192.168.12.42 wird damit dann 3232238634, aber da kann kein Mensch mehr routing-relevante Informationen erkennen, daher hat man ja die dotted quad-Schreibweise eingeführt.
Auf die IP-Adresse folgt dann ein Slash, der oben grün dargestellt ist.
Danach kommt der resource Teil. Dieser ist
- quasi beliebig lang
- aus beliebigen Zeichen zusammengesetzt, wobei auch Slash / und Doppelpunkt enthalten sein dürfen
Also: der grüne Slash hat eine besondere Bedeutung, alle weiteren haben keine.
Typische resource-Teile von urls lehnen sich dann auch an Unix-Dateipfade an, denn auf einem Unix-System sind viele der Grundlagen zu http ja entstanden. Das sieht dann wie
http://www.hase.net/home/hase/SAK
aus.
Ein anderer typischer Vertreter des URL zeigt, dass so auch auf Inhalte gezeigt werden kann, die z.B. in einer Datenbank liegen
http://www.lotus.de/home.nsf/ALL/F1A26B49D1CDC647C12567AD004D01C3
Besonders interessant ist ide Variante, wo der URL nicht einen Speicherort angibt sondern ein Programm, dessen Ausgabe dann an den Browser (oder anderes URL-abfragendes Programm, denken Sie hier z.B. an einen "Mediaplayer") gesendet wird. So werden z.B. Audio- oder Videostreams aber eben auch Ausgaben beliebiger anderer Programme per URL adressierbar:
http://www.hase.net/pmwiki/pmwiki.php/Filter/RPS
Hier wird das Programm pmwiki.php auf dem Server aufgerufen. Diesem werden Parameter übergeben (die "?" trennen die Parameter voneinander). In der Tat stammt ja alles, was Sie hier lesen, aus diesem Wiki-Programm.
Genau dieses Mittel läßt sich nun trefflich nutzen, um RPS völlig ad absurdum zu führen.
Nocheinmal rekapituliert, wie RPS funktionieren soll
- alle http-Aufrufe werden mit eine Liste verglichen. Diese Blacklist enthält dabei URLs, die auf Inhalte verweisen, deren Übertragung eine Rechteverletzung darstellt; Zugriffe auf solche URLs sind zu blockieren.
Die Blacklist enthält dabei also vollständige URLs in der o.a. Form und auch die vollständigen URLs werden verglichen.
Es reicht offenbar nicht aus, nur die Teile protokll://IP-Adresse/ zu vergleichen, denn http://ip-addr/Meinung.txt kann einfache Meinungsäußerung (immer erlaubt) sein, http://ip-addr/fieser-download.mp3 dagegen eine Rechtsverletzung.
Auch reicht zum "Sperren" eines bestimmten Inhaltes oft das Listen eines URL nicht aus: es ist ja absolut möglich, dass zwei völlig verschiedene URLs auf genau dieselbe Resource verweisen.
Trivial ist es dabei, wenn einmal die symbolische Form der IP-Adresse (www.hase.net) und einmal die Adresse in dotted quad (192.168.12.42) verwendet wird (wir nehmen hier mal an, dass www.hase.net zu 192.168.12.42 per DNS aufgelöst wird).
Aber es ist natürlich auch möglich, dieselbe IP-Adresse (192.168.12.42) unter einem ganz anderen
Namen (z.B. serv1-hase.dyn.kiez.net) einzutragen, ja unter praktisch beliebig vielen Namen.
Dies bedeutet schon einen erheblichen Umfang (und damit Rechenzeitaufwand für die Vergleiche jedes Aufrufes mit der Liste) für die Blacklist.
Zudem ist das Web und speziell der Teil, der rechtsverletzende Inhalte bereitstellt, ständig in Bewegung.
Die Blacklist muss also dem sich ständig verändernden Angebot permanent nachgeführt werden: neu auftauchende URLs, die auf alte Inhalte verweisen, müssen nachgepflegt werden.
Der "RPS Absurder"
Und genau hier wird RPS jetzt völlig absurd, denn die URLs für dieselbe Resource kann ja ein Computerprogramm erzeugen.
Als triviales Beispiel soll hier
http://ip-addr/fieser-rechteverletzender-download.cgi?2005-04-11-12-32-05
dienen. Hier wird das Programm fieser-rechteverletzender-download.cgi auf dem Zielserver aufgerufen, erhält den Parameter 2005-04-11-12-32 (was z.B. die aktuelle Uhrzeit sein könnte) und seine Ausgabe wird zurückgeliefert.
So ein URL ändert sich also jede Minute automatisch.
Wir haben oben gesehen, dass es nicht ausreicht, nur URL-Teile mit der Blacklist zu vergleichen. Zwar kann man in diesem trivialen Beispiel mit cgi und Uhrzeit auf die Idee kommen, einfach alle Aufrufe von fieser-rechteverletzender-download.cgi zu sperren, aber ggf. sind nicht alle Ausgaben dieses Programmes wirklich zu sperrende sondern absolut unverwerflich.
Das Aktualisieren der Blacklist läuft damit auf ein Wettrennen zwischen einem Menschen (der die Listen aktualisiert) und einem Computer (der die URLs verändert) hinaus - ein Rennen das der Mensch nicht gewinnen kann.
Jeder Rettungsversuch für das System läuft aber auf False Positives in Massen - und damit auf eine Beschneidung der Meinungsfreiheit hinaus.
Die Implikationen auf Datenschutz (das zentrale RPS-Gerät könnte massiv Daten über Download-Versuche sammeln), Strafverfolgung (jeder Download-Versuch könnte einen Anfangsverdacht ausreichend für einen Durchsuchungsbeschluss darstellen) Pressefreiheit oder freien Wettbewerb (geben Sie einmal in Gedanken "versehentlich" http://www.amazon.de/index.html oder http://www.heise.de/tp/r4/artikel/5/5893/1.html in die Blacklist ein) müssen wir hier gar nicht mehr betrachten.
Man kann eigentlich nur zu dem Schluss kommen, dass ein Zwang zur RPS-Anwendung unverhältnismässig wäre.
Für andere Systeme gilt im Prinzip das gleiche, auch wenn die Wirkungsansätze weit differenzierter sind:
kann die Umgehung des Filters automatisiert werden, die Pflege der Filterregeln aber nicht, dann ist das Filter wirkungslos.
