Schöner tauschen III

08. August 2000 Erik Möller

Führerlos: Gnutella, FreeNet, Jungle Monkey & Co

Der folgende Beitrag ist vor 2021 erschienen. Unsere Redaktion hat seither ein neues Leitbild und redaktionelle Standards. Weitere Informationen finden Sie hier.

Die Klagen gegen Napster und Scour zeigen die Verwundbarkeit zentralisierter Tauschbörsen. Doch etliche Programme machen den Server beim Dateitausch überflüssig - und anonymisieren dabei zum Teil gleichzeitig noch ihre Benutzer.

Die Streitigkeiten um die MP3-Tauschbörse Napster und die "Mediensuchmaschine" Scour dauern an und werden, wenn es nicht zu einer Einigung kommt, wohl bis zur höchsten Ebene des US-Justizsystems getragen werden. Dann wird es spannend: Sollte der Oberste Gerichtshof Napster für illegal erklären, ist der Ofen für vergleichbar arbeitende Systeme aus. Davon wären alle in Teil 1 (Napster und seine Freunde) und Teil 2 (Napsters Konkurrenten - zentralisierte Tauschbörsen dieser Serie vorgestellten Programme betroffen.

Ausgerechnet Napster bildet dabei vielleicht noch eine Ausnahme, da mit OpenNap (siehe Teil 1) ein offener, kostenloser Server verfügbar ist. Zwar würden wohl die meisten Betreiber von OpenNap-Servern bereits bei der Androhung rechtlicher Schritte den Laden dichtmachen - "Ich habe keine Million Dollar", begründet dies z.B. Adam Mead, der seit 3 Monaten einen OpenNap-Server betreibt. Aber wenn der Server in Europa oder Russland steht, sieht die Lage schon ganz anders aus. Von der Geschwindigkeit her sollte das kein Problem sein, da ein Dienst wie Napster vergleichsweise wenig Bandbreite benötigt.

OpenNap zeichnet sich durch eine weitere Eigenschaft aus: Mehrere Server fungieren als ein Netzwerk, das Daten austauscht und Suchanfragen beantwortet. Dabei ist das Netzwerk in diesem Fall allerdings relativ klein: an die 10 Server bedienen Tausende Benutzer gleichzeitig. Man hat es also mit einer Wenige-zu-viele-Beziehung zu tun, wobei die wenigen Server immer noch relativ leicht unter Kontrolle zu bringen sind.

Einen Schritt in eine völlig neue Richtung wagte im März dieses Jahres Justin Frankel, Chefentwickler des MP3-Players Winamp und bekennender Lama-Liebhaber, mit Gnutella. Zunächst wurde das Programm ohne große öffentliche Aufmerksamkeit entwickelt. Ziel war die Schaffung von Open-Source-Software zum Tauschen von Dateien. Das GNU im Namen deutet an, dass das Programm unter der GNU General Public License stehen sollte, die Quelltextoffenheit und Modifizierbarkeit von Programmen sicherstellt.

Doch es kam anders. Zunächst fragte Nullsoft, Frankels Software-Firma, am 13. März bei BetaNews nach Testern für die Software an. Am nächsten Tag berichtete Slashdot über Gnutella - und Tausende Interessierte testeten das unfertige Programm.

Andere Medien griffen die Story auf, und schließlich passierte das Unvermeidliche. Seit Juni 1999 gehört Nullsoft zum Medienimperium von AOL. Es ist wenig verwunderlich, dass der Netzgigant die Entwicklung einer potentiell urheberrechtsverletzenden Tauschbörse, die noch dazu kein Geld einbringen würde, nicht dulden konnte. Also verschwand das Programm von der Nullsoft-Seite. Die offizielle Entwicklung wurde eingestellt. Der Quellcode gelangte nie in die Öffentlichkeit.

Als das Programm durch die Medienberichte zunehmend an Popularität gewann, tauchten jedoch plötzlich scheinbar aus dem Nichts neue Versionen auf, die schwerwiegende Mängel behoben. Und in einer IRC-Sitzung gab ein anonymer Chatter Details des Gnutella-Protokolls preis, die für die Entwicklung von Gnutella-Klone von elementarer Bedeutung war. Es bestehen kaum Zweifel daran, dass es sich dabei um Justin Frankel handelte. Mittlerweile ist das Protokoll vollständig dokumentiert.

Gnutella: verteilt und anarchisch

Was genau ist Gnutella? Es handelt sich im Wesentlichen um ein Netzwerk aus Rechnern, das untereinander Suchanfragen austauscht und beantwortet. Die ersten Versionen des Programms stellten beim Start eine Verbindung zu einem Server namens "findshit.gnutella.org" her. Dieser diente als "Host-Cache" und lieferte eine Reihe von gültigen IP-Adressen gerade eingeloggter Benutzer zurück. Dieser zentrale Einstiegspunkt dient lediglich der Bequemlichkeit: So muss man nicht mühsam nach der IP-Adresse eines Gnutella-Benutzers fahnden. Hat man einen gefunden, so ist man mit dem gesamten Netz verbunden.

Insgesamt wird eine einstellbare Zahl von Verbindungen zu anderen Rechnern aufrecht erhalten. Außerdem können sich natürlich auch andere Rechner mit dem eigenen verbinden. Startet man eine Suchanfrage, so wird diese an alle Rechner, mit denen man direkt verbunden ist, weitergeleitet.

Die Suchanfrage ist mit einer "Time To Live" (TTL) versehen, ein Zähler, nach dessen Ablaufen die Abfrage "stirbt" und nicht mehr weitergeleitet wird. Der erste andere Rechner, den die Abfrage erreicht, zieht 1 von diesem Wert ab und leitet sie dann an alle umgebenden Rechner weiter, die wiederum das gleiche tun. Eine Art Kettenbrief mit festgesetzter Lebensdauer: Die Zahl der Empfänger steigt exponentiell bis zu einem definierten Punkt.

Jeder Rechner, der die Suchanfrage empfängt, prüft seine lokale Dateiliste und liefert Treffer über den gleichen Weg, den die Anfrage gegangen ist, zurück. Um dies zu erreichen, wird die Suchantwort an den gleichen Host verschickt, von dem man die Anfrage bekommen hat, der wiederum das gleiche tut. Theoretisch sind sowohl Anfrage als auch Antwort anonym, da sie über mehrere Zwischenstationen gehen und so nicht einer bestimmten IP-Adresse zugeordnet werden können. In der Praxis müssen die Antworten aber die IP-Adresse des Datei-Anbieters enthalten. Der eigentliche Dateitransfer wird nämlich über eine direkte Verbindung abgewickelt, bei der das Gnutella-Netz keine Rolle mehr spielt.

Das Übertragungsprotokoll ist dabei übrigens HTTP (Hypertext Transfer Protocol), das auchim WWW zum Einsatz kommt. Deshalb ist es möglich, auf Gnutella-Dateien über einen Web-Browser zuzugreifen, was sich verschiedene Web-Suchmaschinen zu Nutze machen. Da diese aber nicht das gleichzeitige Anbieten von Dateien ermöglichen, sind sie verständlicherweise recht unbeliebt in der Community.

Damit sind die wesentlichen Charakteristika des Gnutella-Netzes erklärt, es gibt jedoch noch einige bedeutende Details. Diese Details sind der Grund, warum das "große" Gnutella-Netz, auf das sich die meisten Informationen beziehen, derzeit kaum zu gebrauchen ist. Da sind zum einen die so genannten Pings und Pongs. Diese werden über das gesamte Netzwerk geroutet, um andere Gnutella-Benutzer zu finden und zu zählen.

Teilnehmer eines Gnutella-Netzes heißen "Servants", im Folgenden wird auch von Hosts oder Nodes die Rede sein. Ein Gnutella-Servant schickt in regelmäßigen Abständen Ping-Pakete an seine unmittelbaren Nachbarn. Diese werden auf die gleiche Weise im Netz verteilt wie Suchanfragen, auch sie haben eine begrenzte TTL. Jeder Empfänger einer Ping-Anfrage antwortet mit einem Pong-Paket, das wie eine Suchantwort auf dem Eingangsweg zurückgeleitet wird und die IP-Adresse des Servants, dessen Port, die Zahl seiner Dateien sowie deren Größe enthält.

Auf diese Weise füllt Gnutella einen "Host-Catcher", der die IP-Adressen von Hunderten oder Tausenden Servants enthält und aktualisiert gleichzeitig Statistiken über die Größe des sichtbaren Netzes (da die Angaben über die Menge und Größe von Dateien jedoch leicht gefälscht werden können, sind diese Statistiken unbrauchbar). Startet der Nutzer das nächste Mal das Programm, so werden die IP-Adressen aus dem Host-Catcher der Reihe nach durchprobiert. Auf diese Weise muss man sich, sobald man sich einmal erfolgreich ins Netz eingeloggt hat, danach nie wieder auf die Suche nach einer IP-Adresse machen und ist auch auf Host-Caches nicht mehr angewiesen.

Ein weiteres wichtiges Detail neben Pings und Pongs sind die so genannten PUSH-Requests. Diese sind notwendig für Servants, die sich hinter Firewalls befinden und Dateien nicht über den herkömmlichen Wege übertragen können. Die PUSH-Requests sollten über den gleichen Weg geroutet werden, den die Suchantwort genommen hat, werden aber von einigen Gnutella-Implementierungen über das ganze Netz verteilt.

Auf den ersten Blick würde man vermuten, dass die Suchanfragen den größten Teil des Gnutella-Datenverkehrs ausmachen, insbesondere, wenn man den "Search Monitor" einschaltet und die eingehenden Suchanfragen vorbeirasen sieht. Doch dem ist nicht so. Push, Ping und Pong sind die wesentlichen Belastungen des Gnutella-Netzes.

Dabei handelt es sich um ziemlich krasse Schnitzer bei der ursprünglichen Gnutella-Protokolldefinition. Kein Wunder, hat doch Justin Frankel Pionierarbeit geleistet -- und sich sicherlich nicht mit der Theorie verteilter Systeme beschäftigt. Da es aber kein "offizielles" Gnutella-Entwicklerteam mehr gibt und jeder Client, der die Kompatibilität mit dem alten Protokoll bricht, nicht mehr mit dem "großen" Netz in Verbindung treten kann, gibt es in diesem Bereich momentan einen Stillstand.

Justin Frankel hat dieses Problem und weitere erkannt. In einem Update seines .plan-Files (mittlerweile ersetzt) fasste er die Hauptmängel des Gnutella-Netzes zusammen:

schlechtes Ping/Pong-Routing
Servants mit schlechten Verbindungen müssen zuviel Datenverkehr übernehmen
ineffizientes Routing, statt nachrichtenspezifischer IDs sollten Routing-Tabellen mit Host-IDs verwendet werden

Seiner Ansicht nach wären nach Behebung dieser Mängel sechsstellige Servant-Zahlen zu erreichen. Verglichen mit den rund 2000 Nutzern, die derzeit die Obergrenze des Netzes bilden, wäre das ein gewaltiger Schritt nach vorne. Nach Napsters Scheinniederlage vor Gericht und der darauffolgenden Berichterstattung stürmten so viele Nutzer das GnutellaNet, dass es für Benutzer von Dial-Up-Verbindungen kaum noch verwendbar war und nach wie vor sehr langsam ist.

Neben Protokollfehlern rauben auch einfache Suchanfragen nach "mp3", "avi" oder "jpg" Bandbreite. Diese werden oft von Anfängern eingegeben, oder von Usern, die eine möglichst große Auswahl haben möchten. Die Belastung des Gesamtnetzes dadurch ist sehr groß, da fast jeder Servant hierfür lange Antwortlisten zurückliefern muss und diese über große Teile des Netzes verteilt werden. Hier müssen die Clients (die auf einem Rechner laufende Implementierung des Protokolls, also ein einzelnes Programm -- der Begriff "Client" ist in diesem Zusammenhang etwas schwammig) bei der Eingabe einer Suchanfrage zu unspezifische Anfragen ablehnen.

Auch Sabotage macht den Gnutella-Nutzern das Leben schwer. Die ersten Versionen des Nullsoft-Clients vertrauten voll und ganz auf die Gutmütigkeit der Benutzer - mit der Konsequenz, dass einige von denen, die berüchtigten "Skript Kiddiez", sofort das Netz mit Suchanfragen wie "Napster 0wnz Y0U!" oder "NAPSTER R0X" oder auch einfach nur "MOOOOOOOOOOOOOOO" überfluteten, die im Suchmonitor, der eingehende Suchanfragen anzeigt, sichtbar waren. Andere nutzten den Suchmonitor zum Chatten.

Der derzeit nach Angaben des Gnotella-Entwicklers (s.u.) Yytrium einzige implementierte Flooding-Schutz besteht in einem einfachen Textkettenvergleich, Pakete mit randomisierten Inhalten werden nicht gefiltert. Eine recht einfache Gegenstrategie bestünde darin, nur eine begrenzte Zahl von Nachrichten pro IP-Adresse zu akzeptieren und den Rest nicht weiterzuleiten oder gar die entsprechende Adresse zu bannen. Dies betrifft aber auch Nachrichten, die von dem Servant nur weitergeleitet werden, da dazwischen nicht sicher unterschieden werden kann. Da aber jeder Host mehrere Verbindungen hat, sollte eine legitime Nachricht, eventuell versehen mit einer höheren TTL, dennoch ihren Weg durch das Netz finden.

Ein weiteres Problem sind falsche Antworten. So kann ein Servant jede eingehende Suchanfrage beantworten. Sinn und Zweck: Man verweist z.B. auf eine HTML-Datei, die ein Werbebanner enthält und genau den Namen der Suchanfrage hat. Sucht ein Nutzer nach Metallica, erhält er "metallica.html". Lädt er diese Datei, wird das Banner geholt, und der Spammer verdient. Diese Variante ist die harmlose, da man nach dem Download der Datei die IP-Adresse des Benutzers kennt. Gegen den kann man dann vorgehen - und die erwähnten Skript Kiddiez tun das sicher auch, wenn man ihnen lange genug auf die Nerven geht.

Eine andere Möglichkeit besteht aber darin, falsche Ergebnisse mit zufälliger IP zurückzugeben. Da die Antwort nicht direkt versandt wird, sondern über das Gnutella-Netz geroutet wird, ist sie in diesem Fall völlig anonym. Das macht auf den ersten Blick wenig Sinn, wurde aber schon eingesetzt, um auf eine Anfrage wie "child porn" als Suchergebnis "mail xyz@whatever.com for child porn" zurückzuliefern. Das Ergebnis: massenhaft Spam-Mail, vor allem von besorgten Nutzern, die aus reiner Neugier nach "child porn" gesucht haben und dem unwissenden Opfer der falschen Ergebnisse anschließend per Mail mit Mord, Totschlag und Polizei drohten.

Anonymität im Gnutella-Netz?

Eine weitverbreitete Illusion über Gnutella ist, dass es anonym sei. Wie wir gesehen haben, ist dies nicht der Fall, sofern ein Dateitransfer zustande kommen soll. Darüber hinaus sind jedem Benutzer die IP-Adressen Hunderter anderer Benutzer bekannt. Das Einzige, was wirklich anonym ist, ist das Suchen.

Dies macht allerdings nur begrenzt Sinn, da Suchen nach kontroversen Informationen nicht strafbar ist. Und wenn tatsächlich ein Download zustande kommt, wird die IP-Adresse ohnehin preisgegeben (mit dieser lässt sich im Regelfall durch eine Anfrage beim Provider der Benutzer exakt ermitteln, dazu werden mit begrenzter Dauer Protokolle der angemeldeten Benutzer und ihrer IP-Adressen geführt).

Die Skalierbarkeit und Sabotagesicherheit des Gnutella-Netzes ließe sich erheblich erhöhen, wenn die Suchanfrage auch die IP-Adresse des Suchenden enthielte. Dann könnte der direkt antworten, ohne das GnutellaNet in Anspruch zu nehmen. Auch könnte man auf dem Anfrageweg durch Bestätigungsanfragen verifizieren, ob die Anfrage authentisch ist. So kann man die Zahl der Anfragen pro IP-Adresse limitieren und Flooding effizient vermeiden. Das gleiche gilt für Ping-Pakete und Push-Requests.

Welchen Client?

Trotz der Fehler im Protokoll ist die Gnutella-Szene enorm groß. Solange die Nutzerzahl noch vergleichsweise klein war, funktionierte das Gnutella-Netz hervorragend und lieferte im Gegensatz zu Napster alle denkbaren Dateien zurück: komplette Filme, Pornobilder, Kochrezepte, wissenschaftliche Daten (vieles davon legal, vieles illegal).

Aufgrund der Tatsache, dass der Windows-Client nicht mehr weiterentwickelt wurde, nicht open-source war wie angekündigt und damit auch nicht für andere Plattformen verfügbar, schossen Klone wie die Pilze aus dem Boden.

Bis heute sind die meisten davon jedoch unfertig und bieten nicht die Stabilität, Kompaktheit und Funktionalität des Nullsoft-Clients, auch wenn sie in der Regel dessen schwerwiegendste Design-Schwächen korrigieren. Es wäre unsinnig, alle derzeit verfügbaren Clients vorzustellen, wir beschränken uns deshalb auf die gebräuchlichsten und interessantesten. Eine vollständige Liste findet sich bei den Gnutelliums. Das Original von Nullsoft kann man noch von der Gnutella-Portal-Seite herunterladen, sollte es aber wegen seiner Mängel nicht verwenden.

Gnotella (Windows)

Gnotella gehörte zu den ersten Clients und ist aufgrund seiner Funktionalität sehr beliebt. Von allen Gnutella-Clients ist Gnotella mit 3 MB der größte, aber das Warten lohnt sich, denn das Programm bietet einige interessante Features:

Die Programmoberfläche lässt sich mit Skins schmücken, wie man sie z.B. von Winamp kennt
Man kann unerwünschte Suchen abfangen (wenn man z.B. Suchen nach "child porn" nicht weiterleiten will)
Man kann unerwünschte Suchantworten ignorieren (das betrifft per Default Werbung für Webseiten, HTML-Dateien, VBS-Viren und ähnliches -- will man nach HTML-Dateien suchen, muss man die entsprechende Option abschalten)
Die Zahl der gleichzeitigen Up- und Downloads sowie der ein- und ausgehenden Verbindungen lässt sich einstellen
Die gesamte Bandbreite für Uploads lässt sich regulieren
Bis zu 3 Suchen gleichzeitig sind möglich
Durch Verändern des Gnutella-Erkennungstextes lassen sich private Netze formen, denen kein Nutzer beitreten kann, der diesen Text nicht ebenfalls in seinem Client konfiguriert hat (diese Netze haben dann logischerweise auch nicht mit den Verstopfungsproblemen des "großen" Gnutella-Netzes zu kämpfen, solange sie eine bestimmte Größe nicht überschreiten).

Vor allem die fehlenden Features zur Bandbreitenkontrolle machten dem Nullsoft-Client zu schaffen: Ließ man diesen über Nacht laufen, hatte man am Ende unter Umständen 40 eingehende Verbindungen und 30 Uploads. Das Programm neigte dazu, die gesamte Bandbreite von Standleitungen "abzusaugen".

Gnotella ist innovativ und stabil. Die Spam-Filter-Funktionen lassen an Zensur denken, aber wer ein anonymes, nicht zensierbares Netz will, darf Gnutella ohnehin nicht verwenden. Der Quellcode soll in Kürze veröffentlicht werden.

Toadnode (Windows)

Erst seit Mitte Juli gibt es diesen Client, der alle notwendigen Features unter einer einfach zu bedienenden MDI-Oberfläche vereint. Wie Gnotella erlaubt auch Toadnode umfangreiche Kontrolle über die verwendete Bandbreite, eingehende Anfragen und Ergebnisse lassen sich jedoch nicht filtern. Die große Stärke des Programms ist seine einfache Bedienbarkeit, dank "Quick Connect" muss sich der Newbie nicht um IP-Adressen kümmern, das Programm stellt wie Gnotella automatisch eine Verbindung zu gängigen "Host Caches" here.

Ein sehr interessantes Toadnode-Feature ist die Unterstützung von SOCKS-Servern. Dies sind generische Proxies, die als Zwischenstationen für Datenverkehr beliebiger Internet-Programme dienen können. Kennt man einen SOCKS-Server, kann man damit seine Gnutella-Nutzung anonymiseren. Der Nachteil: Die Geschwindigkeit sinkt in der Regel. Listen von SOCKS-Servern gibt es im Internet, die meisten von ihnen stehen aber unfreiwillig aufgrund von Sicherheitslücken offen, weshalb hier keine Tipps zum Finden gegeben werden sollen. Klar ist, dass kaum jemand seine Bandbreite verschenken will, damit andere Nutzer anonym MP3s downloaden können und SOCKS-Server im herkömmlichen Sinne nur einer kleinen Zahl von Nutzern dienlich sein können.

Leider weist Toadnode noch einige Speicher- und Rechenzeitlöcher auf, so dass das Program alles andere als stabil ist. Man kann aber angesichts der regelmäßigen Updates des Programms wohl davon ausgehen, dass diese bald gestopft werden.

Toadnode ist "Postcardware" (die Programmierer freuen sich über eine Postkarte) und wird nach Angaben der Entwickler auf absehbare Zeit closed-source bleiben.

Gnumm (Windows)

Gnumm ist eine Kombination aus Napster- und Gnutella-Client. Das Programm ist in Visual Basic geschrieben und daher recht speicherintensiv. Außerdem benötigt Gnumm einen installierten Internet Explorer 4. Auch die Oberfläche macht Kompatibilitätsprobleme und zeigt unter Umständen nicht alle Buttons an.

Das Programm leistet ansonsten das, was man von einem Napster- und einem Gnutella-Client erwarten kann (inkl. Hot-List für Napster und gemeinsamer "Medienbibliothek" zum Organisieren der Dateien). Die kombinierte Suche funktioniert tadellos und erlaubt im Falle von Napster auch den Zugriff auf OpenNap-Netze. Empfehlenswert für Nutzer, die häufig nach schwer zu findenden Dateien suchen.

Gnucleus (Windows)

Ähnlich wie Toadnode arbeitet Gnucleus mit einem MDI-Interface, d.h. viele kleine Fenster sind unter einem großen vereint. Das Programm rast regelrecht durch die Liste der verfügbaren Hosts und wählt nur die schnellsten von ihnen aus. So liefern die Suchen bei Gnucleus auch bei Netzverstopfung eher Treffer zurück als bei anderen Clients.

Kleine Macken plagen das Programm. Mit Push-Requests hat es noch so seine Probleme, und auch die Downloads wollen nicht immer funktionieren. Geschwindigkeit und Oberfläche können dagegen begeistern. Man kann beliebig viele Suchen starten, und sogar Mehrsprachfähigkeit ist vorhanden. Mit ein paar kleinen Korrekturen wäre das Programm eines der besten. Es kommt mitsamt dem Quellcode.

Gnewtella (Windows)

Gnewtella ist ein recht robuster Client, dessen Oberfläche stark an den originalen Nullsoft-Client erinnert. Dahinter verbergen sich aber einige nützliche Features. Such-Filter und Bandbreitenkontrolle kennt man bereits von Gnotella. Danben zeigt Gnewtella bei Suchen die gefundenen lokalen Treffer an, so dass man einen Überblick über die Beliebtheit der eigenen Dateien bekommt. Das Programm ist eines der stabilsten im Test und lässt kaum Wünsche offen. Der Quellcode ist verfügbar.

GnoLife (Windows)

Die Macher von Gnotella haben noch eins draufgesetzt und mit GnoLife ein kleines Tool entwickelt, das eine Verbindung zu einem Host-Cache herstellt oder eine existierende Host-Datei importiert und eine Gnutella- oder Gnutella-kompatible Datei mit den antwortenden Hosts erstellt. Auf diese Weise kann man sich bei einem Punkt ins GnutellaNet einklinken, bei dem man noch Chancen hat, die Netzverstopfung zu durchdringen. In der derzeitigen Situation ist die Verwendung von Gnolife sehr empfehlenswert.

Gnut (Unix, Windows)

Einer der ersten und nach wie vor einer der besten Gnutella-Clients ist Gnut. Das Programm wurde ursprünglich von Josh Pieper entwickelt, mittlerweile hat Robert Munafo die Entwicklung übernommen. Das ist deshalb wichtig, weil unterwegs der Windows-Port auf der Strecke geblieben ist. Alte Windows-Binaries findet man noch auf Josh Piepers Seite. Leider weisen diese einige Bugs auf, die vor allem bei Uploads Abstürze verursachen können.

Das Programm verfügt über keine grafische Benutzeroberfläche. Das mag zunächst wie ein Nachteil erscheinen, dem Power-User erschließen sich aber so sehr viele Möglichkeiten. So lässt sich Gnut mit Skripten steuern und verfügt über vielfältige Konfigurationsoptionen. Unter anderem verfügt der Client über einen integrierten Mini-Webserver, der einem anfragenden WWW-Browser eine Liste der Dateien in HTML zurückliefert. Auch private, passwortgeschützte Sub-Netze lassen sich bilden.

Gnut erfreut sich besonders häufiger Versions-Updates. Das Programm ist sehr schnell und ressourcenschonend. Eine gewisse Einarbeitungszeit benötigt es allerdings schon. Eine Windows-Version mit grafischer Oberfläche befindet sich in Entwicklung, ist aber derzeit noch nicht nutzbar. Wie alle folgenden Clients ist Gnut open-source.

Hagelslag (Unix)

Hagelslag ist ebenfalls eine nichtgrafische Gnutella-Implementierung. Neben der üblichen Client-Funktionalität kann man das Programm auch als Router und als Daemon starten. Als Router leitet es nur Pakete weiter und stellt Dateien bereit, als Daemon kann es z.B. per Telnet oder durch eine grafische Oberfläche ferngesteuert werden. Das Programm ist vor allem für Linux-Entwickler interessant.

Furi (Java)

Furi gehörte zu den ersten Gnutella-Clones und weist von allen vorgestellten Programmen die größte Funktionalität auf. Nach den Worten des Entwicklers ist dies vor allem aufgrund der einfachen TCP/IP-Programmierung unter Java so. Neben einem JAR-File (nur etwas für User mit Java-Erfahrung) gibt es auch ein Windows-Installationspaket.

Das Programm hat eine durchdachte grafische Benutzeroberfläche. Eingebaute Host-Caches erleichtern die erste Verbindung. Suchergebnisse können auf bestimmte Stichworte hin gefiltert werden. Neben dem obligatorischen Suchmonitor lassen sich auch eingehende Suchantworten nach bestimmten Stichwörtern durchsuchen. Diese so genannte "passive Suche" benötigt keine Bandbreite und kann bei sehr allgemeinen Anfragen durchaus sinnvoll sein.

Furi verfügt natürlich auch über Host- und Spam-Filter und detaillierte Bandbreitenkontrolle. Um die Suchgeschwindigkeit zu erhöhen kann die Verbindung zu langsamen Hosts automatisch getrennt werden (oder zu Hosts, die zu viele Pakete senden). Die freigeschalteten Dateien werden angezeigt, und bei jeder eingehenden Suche, die einer Datei entspricht, wird deren "Search Count" hochgezählt. Genauso gibt es einen Upload Count für jede Datei, der anzeigt, wie oft diese verschickt wurde. Es lassen sich private Subnetze mit Passwortschutz formen.

Als ob all dies nicht reichen würde, kann das Programm auch das GnutellaNet zum chatten nutzen. Dies ist natürlich eine sehr bandbreitenintensive Funktion, für die Furi viel kritisiert wurde. Als Ergebnis weisen neue Versionen außerdem einen eingebauten IRC-Client (!) auf. Jeder muss selbst entscheiden, ob er diese Feature-Manie für sinnvoll hält.

Sowohl wegen Java als auch wegen seines Feature-Umfangs ist Furi nicht gerade ressourcenschonend. Satte 30 MB Hauptspeicher saugt das Programm ab, und auch die CPU wird z.B. durch den Suchmonitor recht stark beansprucht. Stabil ist das Programm dennoch. Furi ist etwas für User mit entsprechend schnellen Rechnern (oder schnellen Java-Implementierungen), die werden durch die vielen Features auf ihre Kosten kommen. Der Quellcode ist verfügbar.

Eine Anleitung zur Installation für den Macintosh findet sich hier.

Mactella (Mac)

Mactella ist der einzige native Macintosh- Gnutella-Client. In der neuesten Version verfügt das Programm endlich über Upload-Fähigkeiten und ist damit ein vollwertiger Gnutella- Client (leider fehlt Firewall-Unterstützung).

MyGnut (BeOS)

Auch MyGnut unterstützt keine Uploads und wurde schon lange nicht mehr aktualisiert, ist aber unter BeOS neben Java-Clients alternativlos.

Zwischenbilanz

Insbesondere für Windows gibt es mittlerweile eine unüberschaubare Zahl von Gnutella-Clients. Nur wenige davon sind wirklich vollständig und stabil. Empfehlenswert sind Gnotella, Toadnode, Gnewtella und Gnucleus. Unix-User sollten sich in Gnut einarbeiten. Für die meisten anderen bleibt Furi als rechenintensive, aber enorm mächtige Alternative.

Schade ist, dass kaum einer der zahlreichen Entwickler bisher den Mut gehabt hat, vom mangelhaften Gnutella-Standard abzuweichen. Solange dies nicht geschieht, operiert das GnutellaNet an der Grenze der Nutzlosigkeit.

konspire

Viele der Probleme des Gnutella-Protokolls hat eine Gruppe von Cornell-Studenten, die sich bezeichnenderweise "Hardened Criminals" nennen, dazu motiviert, eine skalierbare Alternative zu entwickeln. konspire soll dabei zwar keine Anonymität ermöglichen, aber zumindest Verstopfungen wie im Gnutella-Netz verhindern.

konspire weist vom Design her Ähnlichkeiten mit OpenNap auf. Client und Server sind voneinander getrennte Programme. Dabei sollen Server vor allem auf Systemen mit schnellen Festverbindungen laufen (in der Anfangsphase tut's aber auch ein Dial-Up-Account). Client dagegen kann man selbst mit einem langsamen Modem sein.

Die Server bilden ein ringartiges Netz, das Nachrichten austauscht. Das sind vor allem die Dateilisten, die ein Client einem Server sendet, wenn er zu diesem eine Verbindung herstellt oder seine lokalen Dateien neu indexiert. Da die Listen weitergeleitet werden, sollte jeder Server über eine relativ komplette Liste aller Dateien im Netz verfügen. Relativ deshalb, weil die Server nicht gleichzeitig gestartet werden. Listen, die ein Server verpasst, bekommt er erst, wenn der entsprechende Client sich neu einloggt oder seine Dateien reindexiert. Sofern die Server die meiste Zeit laufen, führt dies nur zu minimalen Unterschieden.

Client und Server sind bereits in Java implementiert. Damit lässt sich konspire auf diversen Betriebssystemen testen. Da die Funktionalität des Programms gering ist (Upload, Download, Sharing) fällt Java als Geschwindigkeitsfaktor nicht ins Gewicht. Aus zwei Gründen wird das Programm jedoch noch kaum genutzt: Unter Windows ist das Ausführen eines Java-Programms verhältnismäßig umständlich, und das Programm hat bisher so gut wie keine Publicity bekommen.

Die Architektur ist OpenNap sehr ähnlich (wenige Server - viele Clients), wobei konspire keine Chat-Funktionen hat, im Unterschied zu OpenNap aber einen gemeinsamen Index statt einer verteilten Suche à la Gnutella verwendet und auf eine höhere Zahl von Servern ausgelegt ist (bei OpenNap müssen neue Server beidseitig freigeschaltet werden, einem konspire-Server-Netz kann jeder beitreten).

Die zentralisierte Architektur macht Sabotage schwieriger, bösartige Server dürften das einzige ernsthafte Problem darstellen. Diese lassen sich aber, wenn erkannt, relativ einfach permanent verbannen. Ein konspire-Netz ist zwar schwieriger unter Kontrolle zu bringen als ein total zentralisiertes System wie Napster, aber wegen des Ungleichgewichts zwischen Servern und Clients noch eher rechtlichen Attacken ausgesetzt als Gnutella. Im Prinzip hängt viel davon ab, wie viele User bereit sind, auch die Server-Software laufen zu lassen.

Das Konzept ist interessant, und wer über die notwendigen Kenntnisse zum Installieren und Starten von Java-Programmen verfügt, sollte einen Versuch wagen. Derzeit sind jedoch nur wenige Testfiles online.

Jungle Monkey

Wieder ein anderes Prinzip verfolgt Jungle Monkey, ein Projekt von Studenten der Universität Michigan. Das Protokoll weist gewisse Ähnlichkeiten mit Gnutella auf, obwohl das JM-Projekt bereits seit 1998 existiert, lange vor Gnutella. Jungle Monkey dürfte auch weitaus besser skalierbar sein.

JM unterteilt Tauschbörsen nämlich in "Channels", wie man sie z.B. auch vom IRC-Chat kennt. Um zu wissen, welche Channel existieren, muss man zunächst einen "Master Channel" kennen. Diesen "Initial Connection Point" gibt es in allen Protokollen, bei JM wird standardmäßig eine Verbindung zum Server junglemonkey.net hergestellt, der den Channel "Monkey Central" anbietet. In diesem Root Channel werden wiederum andere Channels und Chats angekündigt. Dateien können dort nicht angeboten werden. Jeder Benutzer kann auch selbst einen Root Channel anlegen, so dass die Bedeutung von Monkey Central als "Initial Connection Point" nicht so groß ist.

Der Austausch von Nachrichten geht bei JM ähnlich vonstatten wie bei Gnutella, allerdings ist die Netz-Topologie weitaus durchdachter. Anstatt einer Spinnennetz-Struktur macht JM pro Channel Gebrauch von einer Baumstruktur (mit Wurzel-Server und verschiedenen Ästen), die relativ schnell arbeitet, aber nicht zuviel Bandbreite pro Host benötigt. Außerdem ist es in einem Baum leichter, Partitionen zu entdecken, d.h. Aufspaltungen des Netzes in zwei oder mehr Teile (bei Gnutella ist die Vermeidung von Partitionen nicht möglich, es kann durchaus sein, dass man sich in einem vom Hauptnetz abgespalteten Subnetz befindet, ohne es zu wissen).

Über dieses Baum-Netz werden nun Nachrichten weitergeleitet. Dies können Ankündigungen für Dateien, für Chats oder für neue Channel sein. So kann man z.B. vom Channel "mp3" aus einen neuen Channel "Limp Bizkit" anlegen, den alle mp3-Mitglieder sehen. Diese selbstorganisierende Struktur vermeidet den Gnutella-Effekt, dass man, obwohl man vielleicht nur einige Textdateien anbietet, ständig Suchen nach Pornobildern, Filmen und MP3s empfangen und weiterleiten muss. Allerdings drohen natürlich gewisse Aufspaltungen in thematisch gleiche, aber sozial unterschiedliche Channels, die Dateien im Endeffekt auch schwerer zu finden machen können.

Auch aus juristischer Sicht ist die thematische Konzentration in Channels nicht unbedingt sinnvoll. Vergangene Klagen haben gezeigt, dass die Industrie wesentlich schneller gegen eine kleine relevante Gruppe von Usern agiert als gegen eine große, kaum unterscheidbare. Man kann jedoch auch private Channels erzeugen, die nirgendwo angekündigt werden und in die man einzelne Nutzer gezielt einladen muss. Das gleicht dann dem Katz- und Maus-Spiel, das Fahnder aus dem IRC kennen (mehr dazu im nächsten Teil der Serie).

Wird eine Datei angefordert, wird zunächst bei einem "Rendezvous-Server" angefragt, welche Hosts diese Datei gespeichert haben. Dateien, die man über JM herunterlädt, werden automatisch wieder zum Download angeboten, was dazu führt, dass beliebte Dateien in mehreren Teilen des Netzes angeboten werden und so die Netzlast besser verteilt wird. Auch ist es schwer, in einer solchen Struktur das erstmalige Einspielen einer Datei nachzuweisen.

Der Rendezvous-Server liefert Informationen darüber zurück, welcher Host dem eigenen am nächsten steht. Die Nähe wird durch Ping-Zeiten bestimmt, in Zukunft sollen Geschwindigkeitsunterschiede zwischen Hosts berücksichtigt werden und Internet Distance Maps zum Einsatz kommen. Der Server lässt sich jedoch nicht durchsuchen, dazu gibt es einen eigenen Search-Server, den man in Channels installieren kann.

Bisher gibt es nur eine Unix-Implementierung des Protokolls (die über eine sehr benutzerfreundliche Oberfläche verfügt), eine Windows-Portierung ist in Arbeit. Bis dahin bleibt das JM-Netz zwangsläufig recht klein, und die tatsächliche Skalierbarkeit lässt sich nicht so recht testen (obwohl diese wohl kein Problem darstellt, da man jederzeit neue Channels anlegen kann, die unabhängig voneinander skalieren.) Ein interessantes Konzept also, das wegen der mangelnden Verfügbarkeit noch keine öffentliche Relevanz hat. Echte Anonymität bietet Jungle Monkey aber nicht und will sie auch nicht bieten.

FreeNet

Ganz andere Ziele verfolgt FreeNet, ein Projekt, das auf ein im Juni 1999 veröffentlichtes Paper (PDF-Datei) des in Großbritannien lebenden Iren Ian Clarke zurückgeht. Der Student der Edinburgh University beschreibt darin ein zensurresistentes, anonymes, effizientes Netz zum Publizieren und Abfragen von Informationen. Vier Prinzipien sind dafür entscheidend: Denzentralisiertheit, Redundanz, Verschlüsselung und dynamisches Routing.

Es gibt einen interessanten Effekt, der bereits bei Systemen wie Napster und Gnutella zu beobachten ist und bei Jungle Monkey schon gezielt genutzt wird: Wenn eine Datei eine gewisse Beliebtheit erreicht hat, findet man sie auf vielen Hosts. Man hat nun keinen realistischen Weg festzustellen, welcher Host diese Datei zuerst ins Netz gestellt hat. Das bietet eine gewisse Anonymität und Rechtssicherheit. Gleichzeitig hat es einen weiteren Vorteil: Wenn das Offspring-MP3 bei Napster-User A nicht oder nur langsam verfügbar ist, kann man es ja vielleicht über B downloaden.

FreeNet optimiert dieses bei anderen Protokollen noch eher unfreiwillige Zwischenspeichern (Caching). Welche Informationen man auch bezieht, sie werden in einem Cache abgelegt, der optimalerweise eine Größe von mehreren Gigabytes haben sollte (bei den heutigen Festplattenkapazitäten kein Problem). Gleichzeitig werden Transfers durch mehrere Hosts geroutet, so dass eine weitere Replikation erreicht wird. Das geschieht innerhalb einer dezentralen Struktur à la Gnutella. Der Datenaustausch läuft allerdings völlig anders ab.

Suchen gibt es im derzeitigen FreeNet noch gar nicht, obwohl sie in späteren Protokollversionen implementiert werden sollen. Alle im System vorhandenen Daten werden mit so genannten Keys gespeichert, die an WWW-URLs erinnern. Ein Key kann zum Beispiel so aussehen:

/bilder/erotik/manuela01.jpg

Im Übrigen eine für den bisherigen Namespace eine bereits recht repräsentative Namensgebung. Nur wer diesen Klartext-Key kennt, kann die Information auch abfragen. Von dem Key wird eine Prüfsumme gebildet, z.B.:

S14X32B

Nehmen wir an, wir fordern das Bild von Manuela an. Wir schicken eine Anfrage zu unserem unmittelbaren Nachbarn. Dieser hat eine Tabelle mit den folgenden Einträgen:

FVO237H 172.16.12.21:42
R2D2AOL 10.0.0.33:31337
UXC28V2 192.168.77.5:23
MAZC3PO
SHX2V80

Die Einträge ohne IP-Adresse sind im Cache des Hosts vorhanden. Da unser Nachbar über die Datei S14X32B nicht verfügt, schickt er die Anfrage an den lexigraphisch nächsten Host weiter, das ist im Beispiel 10.0.0.33, der über R2D2AOL verfügt, das am nächsten an S14X32B ist.

Durch dieses Routing bilden sich lexigraphische Cluster, die zwar eine Selbstoptimierung des Netzes bewirken (das Routing zu den gewünschten Informationen wird immer effizienter, was Clarke in Simulationen beweisen konnte), aber keinesfalls eine thematische Nähe signalisieren. Im Gegenteil: Informationen werden über das gesamte Netz verstreut, so dass das Ausschalten einzelner Server wenig Sinn macht.

Unsere Anfrage nach dem Bild landet nun beim Host mit der Adresse 10.0.0.33, der im Beispiel ebenfalls nicht über die Datei verfügt. Er schickt die Anfrage an einen nahen Host aus seiner Liste weiter, der gleichermaßen verfährt, bis (1) die TTL abgelaufen ist, (2) die Datei gefunden wurde oder (3) keine weiteren Hosts auf diesem Weg des Netzes mehr vorhanden sind.

In Fall 1 wird die Suchabfrage mit einer Misserfolgsmeldung quittiert und abgebrochen. Der Suchende kann dann die TTL erhöhen und es noch einmal versuchen. In Fall 2 wird die Datei über den Weg, den die Anfrage genommen hat, zurückgeliefert und auf jeder Zwischenstation im Cache gespeichert (älteste Dateien werden gelöscht, wenn der Cache dadurch seiner Größe überschreitet). In Fall 3 wird, falls Fall 1 noch nicht eingetreten ist, der lexikographisch nächste Host ausgewählt, in unserem Beispiel 192.168.77.5.

Ein paar Kniffe sollen die statistische Analyse des Routings erschweren (was der Anonymität dienlich ist). So können Hosts auf dem Routweg sich plötzlich selbst als "Lieferanten" für die Information ausgeben, und die TTL wird, sobald sie 1 erreicht, nach dem Zufallsprinzip entweder noch um eine Runde verlängert oder nicht.

Damit ist es selbst mit großem Aufwand sehr schwierig, die ursprünglichen Absender von Informationen ausfindig zu machen, aber man könnte einen einzelnen Host dafür verantwortlich machen, dass er bestimmte Dateien zur Verfügung stellt und ihn dazu auffordern, Keys in bestimmten Bereichen (z.B. "/bilder/erotik/kinder") nicht zu speichern. Dem Konzept nach wird dies dadurch verhindert, dass der Host nicht weiß, welche Informationen er speichert: Die Keys existieren im lokalen Index nur in der Form von Prüfsummen, die nicht wieder in die ursprünglichen Keys zurückverwandelt werden können.

Die Dateien selbst werden vor dem Upload ins Netz mit ihrem Original-Key (/bilder..) verschlüsselt. Nur wer den exakten Key kennt, kann die Datei wieder entschlüsseln, die Prüfsumme ist dafür relativ nutzlos (obwohl sie in Brute Force Attacken mit den Prüfsummen von besonders kontroversen einzelnen Schlüsseln verglichen werden kann).

So hat der Betreiber eines Hosts keine realistische Möglichkeit herauszufinden, welche Dateien er speichert und kann diese auch nicht nach bestimmten Kriterien zensieren. Nur wenn er selbst z.B. die Datei manuela01.jpg explizit anfordert, weiß er, ob diese auf seinem eigenen Host überhaupt existiert.

Das Einfügen von Daten ins Netz funktioniert ähnlich wie das Anfordern: Man stellt eine Verbindung her und verschickt an einen Server den gewünschten Key (nur die Prüfsumme) mit einer TTL. Der leitet sie an die lexikographisch nächsten Hosts weiter, um das Routing zu optimieren. Gibt es Namenskollisionen, wird die Datei zurückgeliefert. Das soll nicht nur den Uploader informieren, sondern auch Zensur-Attacken verhindern: Versucht man eine existierende Datei durch eine andere zu ersetzen, trägt man nur dazu bei, dass sie weiter verbreitet wird, da sie ja auf dem Weg zurück immer wieder zwischengespeichert wird.

Gibt es den Key noch nicht, signalisiert der Nachbarhost Empfangsbereitschaft, und es folgt der eigentliche Upload zu allen Hosts innerhalb der TTL (wobei Uploads mit sehr hohen TTLs ignoriert werden können, um das Netz nicht über Gebühr zu belasten).

Sofern es keine Namenskollisionen gibt, tragen die Hosts den Key-Hash mit der IP-Adresse des Senders in ihre Routing-Tabelle ein, wobei die per Zufallsgenerator unter Umständen durch die eigene oder eine zufällige andere ersetzt wird, um die Anonymität zu gewährleisten.

FreeNet in der Praxis

Derzeit arbeiten die Männer und Frauen um Ian Clarke noch an dem Prototyp einer Implementierung von FreeNet. Dieser soll alle wesentlichen Elemente von Architektur und Protokoll beinhalten, legt aber keinen Wert auf Benutzerfreundlichkeit. Die Implementierung wird wegen der so erreichbaren Plattformunabhängigkeit in Java vorgenommen. Es gibt einen Server, der den Cache und das Routing übernimmt, und einen Client, mit dem man Dateien anfordern und einspielen kann. Abgesehen davon sind bereits erweiterte Clients entwickelt worden, die man hier aufgelistet findet (das Komfortabelste, was man unter Windows bisher erwarten kann, ist ein Java-GUI-Client).

Die Implementierung ist angesichts der Komplexität des Konzepts und der Tatsache, dass Clarkes erstes Paper im Juni 1999 erschienen ist, bereits erstaunlich weit fortgeschritten. Das liegt sicherlich auch an der intensiven Mediencoverage des Projekts, die ihm einen stetigen Zustrom an Programmierern beschert hat (an die 400 Mitglieder hat allein die Mailing-Liste für FreeNet-Entwickler). Davon stammen übrigens nur wenige aus Deutschland, CCC & Co. scheinen an einer derartigen Liberalisierung des Netzes nicht besonders interessiert zu sein.

Was fehlt

Ein Hauptproblem der derzeitigen Clients und Server ist die fehlende Möglichkeit des Suchens. Das ist nicht trivial, vor allem, wenn die Hosts gar nicht wissen, was sie speichern. Der bisherige Ansatz ist primitiv: Kex-Indizes (hier findet sich eine Liste) im WWW nehmen per Formular neue Key-Einsendungen an. Es gibt keine Prüfung, ob diese tatsächlich existieren, und die Anonymisierung ist Sache des Nutzers. Die Indizes lassen sich natürlich durchsuchen, und ihre Einrichtung ist so trivial, dass sie auf juristischem Wege kaum totzukriegen sein dürften. Es ist auch fraglich, ob die Speicherung einer Zeichenkette wie "/censored/DeCSS.zip" als illegal angesehen werden kann - wobei manche deutsche Anwälte hiermit wohl wenige Skrupel haben dürften.

Eine Zentralisierung ist jedoch problematisch, und ein dezentrales System ohne Synchronisierung führt nur dazu, dass es mit zunehmender Zahl der Indizes immer schwerer wird, sie zu durchsuchen. Vielleicht wäre ein Gnutella-ähnliches Meta-Netz hier die richtige Lösung.

Weitere Features sind in der Diskussion, zum Beispiel das Aktualisieren von Dateien durch den Uploader. Letzteres ist problematisch, wenn damit Dateien ersetzt und nicht ergänzt werden: Dann könnte per Gerichtsbefehl vom Urheber, so bekannt, das Überschreiben kontroverser Daten verlangt werden. Sinn machen würde das auch wenig, da alte Dateien automatisch irgendwann aus den Caches fliegen.

Richtig interessant wird es, wenn es um Themen wie Ratings und Micropayments geht. Mit Ratings ist es möglich, bestimmten Informationen und bestimmten Personen Bewertungen zuzuordnen. Kann man den Bewertern vertrauen, so kann man sich in Zukunft auf deren Ratings verlassen und interessante Informationen eher finden. Trivialfall: User X sagt: "/bilder/erotik/manuela01.jpg hat eine sehr niedrige Qualität". Es bildet sich mit dem Wachsen der Datenbank ein Vertrauensnetz, ein so genanntes "Web of Trust", in dem Ratings auch indirekte Wirkung haben ("Ich vertraue Person A, diese vertraut Person B, diese vertraut Person X" usw.), wobei der Wert des Ratings in der Regel mit seiner hierarchischen Tiefe abnimmt.

Damit das Web of Trust funktioniert, ist die zuverlässige Authentifizierung von Benutzern notwendig (wobei natürlich keine persönlichen Informationen verwendet werden dürfen).

Zeige mir Deine Signatur, und ich sage Dir, wer Du bist

Zentralisierte Systeme haben es mit der Authentifizierung von Benutzern leicht: Es gibt eine zentrale Benutzerdatenbank, die kaum manipuliert werden kann. Ganz anders ist es in dezentralen Netzen. Hier müssen digitale Signaturen eingesetzt werden. Dabei wird eine Prüfsumme von den zu unterschreibenden Informationen gebildet, die wiederum mit dem privaten Schlüssel des Autors verschlüsselt wird. Wer über den öffentlichen Schlüssel der Person verfügt, kann nun prüfen, ob die Nachricht authentisch ist. Stimmen die Prüfsummen nicht überein, wurde entweder die Signatur oder die Nachricht manipuliert. Dieses System ist fälschungssicher.

Es ermöglicht gleichzeitig die Erstellung von Pseudonymen. So kann Alice unter dem Pseudonym "Mad Martha" publizieren, und dieses ist eindeutig identifizierbar - sofern nicht ein anderer zuvor diesen Namen mit einem öffentlichen Schlüssel registriert hat. Und das ist wieder ein Problem für dezentralisierte Systeme, denn ein netzweiter Index ist wegen der Dynamik des Netzes und der Gefahr eines Floodings nur schwer realisierbar. Und um Flooding zu verhindern, sind digitale Signaturen wiederum ein wichtiges Werkzeug. Digitale Signaturen sind in FreeNet noch nicht implementiert.

Wer braucht's?

FreeNet fällt natürlich krass aus dem Rahmen der bisher vorgestellten Tools, die allesamt nichtanonym arbeiten. Das Protokoll ist hochinteressant und lässt sich auf so ziemlich alles anwenden, was bisher das Internet ausmacht. So gibt es zum Beispiel schon Minimal-Implementierungen von Usenet-ähnlichen Diskussionsforen über FreeNet. Ian Clarke selbst arbeitet derzeit an einem Projekt namens "Uprizer", das FreeNet als Infrastruktur für eine Implementierung des Street Performer Protocol einsetzen soll. Bei diesem Zahlungsmodell können Künstler profitieren, ohne ihre eigenen Werke per Urheberrecht zu zensieren.

Von allen hier vorgestellten Projekten ist FreeNet zweifellos das ambitionierteste: Es möchte gleich das ganze Internet ersetzen - obwohl es auf dessen Technik beruht, im Gegensatz zu z.B. Fling, das TCP, DNS und UDP durch anonyme Varianten ersetzen will. Sofern das System skalierbar ist, könnte das funktionieren. Problematisch sind langsame Hosts, die auf dem Mittelweg langer Routen liegen: Jede Kette hat ein schwächstes Glied. Diesbezüglich müssen Routing-Optimierungen vorgenommen werden. Bisher setzt man auf die Intelligenz der Nutzer. Besitzer langsamer Verbindungen sollen keine eigenen Nodes betreiben, sondern nur Daten einfügen oder abfragen. Wie ist es aber z.B. mit Besitzern asynchroner Verbindungen, wie z.B. bei T-DSL?

Probleme dürften dem Netz auch Dial-Up-User bereiten, die ihre Verbindungen nach relativ kurzer Zeit trennen: Viele Routen werden damit irrelevant, das Netz muss sich erst regenerieren.

Und ein weiteres Problem ist wie bei allen anderen Netzen der "Initial Connection Point", für den derzeit ein Host-Cache begrenzter Größe als PHP-Skript auf dem FreeNet-Webserver läuft. Das ist natürlich die zentralste denkbare Variante.

Wer Pioniergeist hat, sollte sich die aktuellen Implementierungen anschauen. Für MP3-Sauger ist das Programm derzeit sicher noch nicht interessant, da sich in den Key-Indizes vergleichsweise wenig von Interesse findet (und diese auch nicht dem realen Netz entsprechen, Dateien fliegen irgendwann aus dem Cache, wenn sie nicht mehr angefordert werden). Wer kontroversere Informationen tauschen will, für den ist FreeNet bereits jetzt nutzbar, auch wenn es noch einige Hürden zu überwinden hat.

Blocks

Ähnliche Ziele wie FreeNet verfolgt Blocks, das nur kurz angesprochen werden soll. Auch hier bilden die Hosts ein verteiltes Netz. Jeder Host teilt jedem anderen Host, mit dem er verbunden ist, einen zufällig ausgewählten Buchstaben zu. Jeder Host verfügt außerdem über einen Cache definierter Größe (ab 1 GB aufwärts). Er kann dort eigene Dateien einspielen (diese werden in verschlüsselte Blöcke à 64 KB gesplittet, deshalb der Name des Programms). Eine Liste der eingespielten Dateien wird an die Nachbarn versandt, wobei für jede Datei Name und Größe vermerkt sind.

Der Empfänger hängt an eine solche Ankündigung ("Advert") einen Buchstaben an, der der eingehenden Verbindung entspricht. Beim Download werden diese Buchstaben wieder zurückverfolgt. Bricht eine Route zusammen, wird geprüft, ob für diese Datei alternative Routen existieren. Dateien werden natürlich zwischengespeichert, und es nicht feststellbar, ob eine Anfrage den gesamten Routweg genommen hat oder aus dem Cache eines anderen beantwortet wurde. Die TTL ist derzeit auf 6 festgelegt.

Adverts für Dateien, die nicht vom Benutzer selbst stammen, werden in regelmäßigen Abständen neu angekündigt. Duplikate werden nicht weitergeleitet. So bewegen sich die Adverts zunehmend von ihrem Absender weg, und die Indizes der Netzteilnehmer werden immer vollständiger. Außerdem tauschen Server bei der Erstverbindung eine Liste der 1024 jüngsten Adverts aus. Es ist nicht festzustellen, ob ein Advert vom Anbieter einer Datei stammt oder nur von einem Empfänger des Adverts, zumal Routen auch um ungültige Buchstaben ergänzt werden können.

Suchen finden im lokalen Index statt, was zu keinerlei Zeitverzögerung oder mengenmäßigen Begrenzung bei der Suche führt. Die Datentransfers laufen verschlüsselt ab, allerdings weiß jeder Host, welche Dateien er speichert.

Besonderer Wert wurde auf die Nichtdetektierbarkeit des Systems gelegt. So soll verhindert werden, dass z.B. das Betreiben eines Blocks-Servers schlicht verboten wird, ganz unabhängig vom getauschten Inhalt. Der Datenstrom ist von anderen verschlüsselten Protokollen kaum zu unterscheiden (und diese sind für ECommerce unverzichtbar). Der "Listening Port", auf dem ein Server nach Verbindungen lauscht, ist zufällig. Über so genannte "Trap Ports" lässt sich ein Portscan verhindern: Dabei wird auf zufälligen Ports oder Nachbarports nach Verbindungen gelauscht, im Falle eines Verbindungseingangs werden weitere Verbindungsversuche von der betreffenden IP-Adresse am richtigen Port ignoriert.

Blocks ist wie FreeNet eher auf permanente Verbindungen ausgelegt. Nach dem Schließen des Servers brechen viele vormals gültige Routen zusammen. Auch wird der komplette Cache aus Sicherheitsgründen gelöscht. Das schließt derzeit auch eigene Dateien ein, die erst mühsam neu lokal hochgeladen werden müssen, was bei großen Sammlungen einige Zeit in Anspruch nimmt. In Zukunft soll es für Dateien eine "sticky" Eigenschaft geben, die das Verbleiben im Cache garantiert. Beim Routing über langsame Server hat Blocks die gleichen Probleme wie FreeNet.

Konzepte wie das schon bei FreeNet angesprochene "Web of Trust" mit Ratings für Personen und Dateien sind bereits im Protokoll vorgesehen, aber noch nicht implementiert. Der Fortschritt des Projekts, das vor allem auf einen einzigen anonymen Entwickler zurückgeht, ist rasant: Blocks existiert erst seit rund zwei Monaten.

Im Gegensatz zu FreeNet verfügt Blocks bereits über einen Windows-Client, der zwar mit ungewohnter Oberfläche daherkommt (weil die GUI plattformübergreifend ist), aber relativ unkompliziert zu bedienen ist. Natürlich ist Blocks open-source, und die weitere Entwicklung ist wohl für absehbare Zeit gesichert. Allerdings sind noch keine Skalierbarkeits-Simulationen durchgeführt worden, so dass noch unklar ist, wie groß ein "BlockNet" sein kann. Im Zweifelsfall lassen sich wie bei Gnutella Sub-Netze bilden, aber bei sehr kleinen Netzen ist natürlich keine echte Anonymität gegeben.

MojoNation

MojoNation befindet sich noch im frühen Beta-Stadium. Das Projekt will die Verteiltheit und die Anonymität von Netzen wie FreeNet und Blocks gleich mit Micropayment und einem Web of Trust koppeln, wobei die Firma MojoNation als Zentralbank fungiert. Es handelt sich um ein Projekt der Firma "Evil Geniuses for a Better Tomorrow" [http://www.mad-scientist.com], gegründet von 7 Cypherpunks (siehe auch Mojo Nation: Die ultimative Mischung aus Napster und eBay?).

Das System ist sehr komplex und bisher nur vage dokumentiert, deshalb ist es schwer, Aussagen über die Skalierbarkeit und Verletzbarkeit zu machen. Die folgenden Aussagen gehen auf persönliche Befragung der Entwickler und auf den Technical Overview zurück, der sich auf der MN-Website findet. Der komplette Quellcode soll auf einer speziellen Website frei verfügbar sein.

Die Netzarchitektur in MN ist verteilt, allerdings gibt es eine sehr viel stärkere Aufgabenverteilung als bei den anderen Systemen. Es gibt Autoren, Suchmaschinen, Anonymisierer, Speichersysteme, Anbieter von Rechenzeit, Konsumenten (also eine ähnliche verteilte Struktur wie im WWW) -- weitere "Agenten" können bei Bedarf dem Protokoll hinzugefügt werden. Wer eine Datei ins System einspielen will, muss mit den entsprechenden Rechnern in Kontakt treten (über die er vermutlich durch Ankündigungen innerhalb des Netzes oder durch einen zentralen Server erfährt). Dabei ist Anonymität offenbar optional, was sicherlich sinnvoll ist, da nicht alle Dienste Anonymität erfordern.

Dateien auf so genannten Block-Servern werden verschlüsselt und verteilt gespeichert, um die juristische Verantwortung der Server-Betreiber zu reduzieren. Nur mit einer Share-Tabelle lassen sich die einzelnen Teile wieder richtig zusammensetzen. Der Server selbst verfügt nicht über diese Tabelle und weiß wie bei FreeNet nicht, was er speichert. Außerdem stellt er nur einen kleinen Teil der gesamten Datei bereit.

Der Clou bei MN ist, dass jede Transaktion mit anderen Rechnern "Mojo" erfordert, eine virtuelle Währung, die für Micro- und Macro-Payments eingesetzt werden kann. Im Beta-Stadium bekommt jeder Anwender eine bestimmte Summe von Beta-Mojo zum Ausprobieren. Später soll es möglich sein, reales Geld in Mojo umzuwandeln und umgekehrt, auch das BetaMojo soll dann ausgezahlt werden, 100,000 Dollar hat die Firma dafür reserviert.

Wer wieviel zahlen muss, ist Verhandlungssache. Um informierte Entscheidungen zu treffen, gibt es ein Reputationssystem, mit dem man andere User bewerten kann. Ob nun der Autor einer Information Geld für die Erstveröffentlichung bezahlen muss, oder die Server ihm Geld bezahlen, um sein Werk zu speichern, hängt von seiner Bekanntheit und Beliebtheit ab. Wenn ein Server eine Datei anbietet, können natürlich andere diese kaufen und zu einem niedrigeren Preis anbieten. So ist sichergestellt, dass beliebte Dateien günstig verfügbar sind, während selteneres Material durchaus recht teuer sein kann.

Damit man ins Netz Daten auch finden kann, bieten die Suchmaschinen die Möglichkeit, umfangreiche Metadaten zu speichern (bei MP3-Dateien z.B. Informationen über Künstler und Qualität). Auch Suchen kosten Geld. Damit ist es den Servern nicht zumutbar, gezielt eine große Zahl von Trackern daraufhin zu überwachen, ob Teile von strafrechtlich relevanten Inhalten auf dem eigenen Rechner gespeichert sind.

Das virtuelle Geld (eine Art digitale Münzen, die nur für den bestimmten Empfänger gültig sind) soll anonym zugteilt werden. Man kann bei der Rückwandlung zwar feststellen, dass User Hans Maulwurf 3000 Dollar verdient hat (was wichtig für die Steuererklärung sein dürfte), weiß aber nicht, wie diese Einnahmen zustande gekommen sind.

Damit auch die Schöpfer kreativer Werke nicht leer ausgehen, gibt es eine Art Trinkgeld-System: Konsumenten können Autoren mit freiwilligen Zahlungen entlohnen. Auch das Street Performer Protocol lässt sich anwenden (man wartet mit der Veröffentlichung, bis genügend Interessenten zahlen, ist dies nicht der Fall, bekommen die Fans ihr Geld zurück). Copyright-Verletzungen lassen sich jedoch nicht effizient verfolgen.

Denial-of-Service-Angriffe gegen einzelne Hosts sind auf der Protokollebene von MN kaum möglich, da Transaktionen ja Geld kosten. Durch Anfragen- oder Sende-Flooding würde man seinem vermeintlichen Opfer also auch einen Geldsegen bescheren. Natürlich lassen sich gewöhnliche DoS-Strategien anwenden, wenn man die IP-Adresse seines Gegenübers kennt, aber angesichts der Verteiltheit des Systems macht das wenig Sinn.

Einen kaum vermeidbaren Schwachpunkt des Systems bildet die zentrale Bank. Diese ist natürlich auch essentiell für das Geschäftsmodell von MN, denn hier können die Entwickler Provisionen abzwacken (die sich aber durch Wettbewerb in vernünftigen Grenzen bewegen dürften -- den garantiert unter anderem die Open-Source-Verfügbarkeit der Programme). Neben DoS-Attacken gegen den oder die Banken-Server und Serverausfällen drohen rechtliche Schritte gegen die Hacker-Firma, wenn z.B. Massen-Piraterie mit kommerziellem Gewinn gekoppelt wird.

Ein wichtiger Verteidigungspunkt dürften die freiwilligen Kompensationen für Künstler sein. Ob dieses Modell erfolgreich ist, muss sich erst zeigen: PayLar$, ein Projekt zur Kompensation der Band Metallica für MP3-Piraterie, hat nur etwas mehr als 500$ eingespielt. Stephen Kings E-Book-Projekt The Plant, das zum Teil auf Zwang basiert ("Wenn Ihr nicht zahlt, gibt es keine Fortsetzung"), ist weitaus erfolgreicher: Bereits an die 100,000 Dollar hat der King kassiert, und es soll noch weitaus mehr werden.

Wie gesagt befindet sich die Software noch im Beta-Status, sie ist für Linux und Windows verfügbar. Man startet einen lokalen Proxy-Server, der über ein Web-Interface alle genannten Funktionen bereitstellt. Auch werden Anfragen nach speziell kodierten URLs vom Mojo-Proxy abgefangen, so dass man direkt auf Dateien im Mojo-Land verweisen kann. Insgesamt ein hochinteressantes Projekt, das jeder mit ein wenig Geduld ausprobieren kann.

Andere Projekte

Die hier vorgestellten Protokolle und Implementierungen beschäftigen sich mit der Frage des User-zu-User-Dateitausches, teilweise ergänzt um Anonymisierungs-Funktionalität. Wer sich für die isolierten Aspekte Anonymität und Zensurresistenz interessiert, sollte das Paper (PDF-Datei) der Entwickler von Publius lesen, ein Projekt zur anonymen und zensurresistenten Veröffentlichung von Informationen, das in Kürze startet. Dort werden auch viele andere vergleichbare Projekte in verständlicher Weise zusammengefasst.

Der Live-Test von Publius hat gerade begonnen: Das System erlaubt über "secret sharing" (die einzelnen Hosts wissen nicht, was sie speichern, die Schlüssel für die Daten sind aufgesplittet über das Netz verteilt, wobei eine geringe Zahl von Schlüsselteilen reicht, um den Gesamtschlüssel wiederherzustellen) anonyme und dank Redundanz zensurresistente Veröffentlichungen, wobei es vollständig auf existierender WWW-Architektur aufsetzt. Um Anonymität bei den Daten-Verbindungen kümmert sich Publius nicht, ebensowenig wie um die Durchsuchbarkeit des Content. Die Dateigröße ist auf 100 KB begrenzt, was Tauschen im Sinne von Napster & Co. weitestgehend unmöglich macht: Es geht um freie Rede, nicht um Freibier.

Von Interesse dürften auch die Artikel zum Thema Anonymität in c't 16/2000 ab S. 148 (im Netz: Anonymes Mailen) und der TP-Bericht über Publius sein.

Spannend ist auch David Madores Paper zur Verschlüsselung von Informationen mit Zufallsdateien und der anschließenden Verteilung der resultierenden "Pads" auf verschiedenen Servern, wobei diese Pads mathematisch nicht von Zufallsdaten unterscheidbar sind (und Pads für mehrere Dateien verwendet werden können). So kann Server A behaupten, er habe Pad M gespeichert, um die legitime Datei X zu entschlüsseln, während Server B behaupten kann, er brauche Pad N für die legitime Datei Y.

Beide Behauptungen können überprüfbar richtig sein, und es ist nicht feststellbar, wer von beiden das Pad für die illegitime Datei Z tatsächlich angelegt hat. Nach dem Prinzip "in dubio pro reo" sollten beide freigesprochen werden (wobei noch weitaus mehr Parteien involviert sein können).

Das System basiert allerdings wie Publius vollständig auf existierender Infrastruktur. Es hat natürlich auch die Eigenschaft, dass die Datenmenge mit zunehmendem Pad-Einsatz wächst. Solange Gerichte es nicht für illegal erklären, real zufällige Daten zu speichern, ist es aber wasserdicht.

Fazit

Im Bereich der verteilten Tausch-Systeme tut sich eine ganze Menge, und es ist schwer, noch den Überblick zu behalten. Es gibt anonyme Systeme, nichtanonyme und solche, bei denen die Anonymität optional ist. Netze, die sehr viel Wert auf Caching legen (wie FreeNet oder Blocks) eignen sich gut zur Verteilung großer Daten an viele Rezipienten, wenn man selbst dazu über unzureichende Bandbreite verfügt: Man muss einen Datenstrom nur einmal aussenden, und wenn er von Interesse ist, wird er von anderen Usern mehr und mehr repliziert.

Gnutella & Co. sind einfach implementierbar und mit ein paar Fixes auch recht gut skalierbar. Die Clients sind zumindest von der Oberfläche her schon recht ausgereift. Anonymität könnten sie über Zusatzlayer bieten, z.B. über ein verteiltes Anonymisierungs-System wie Crowds, das auf Wunsch auch Caching-Aufgaben erfüllen könnte. Dabei müsste man Bandbreite für Anonymität opfern, was wohl ein fairer Tausch ist. Ein einfacher Mausklick könnte dann den Client zwischen anonym und nichtanonym umschalten.

FreeNet, MojoNation und Blocks haben weitergehende Ambitionen. Sie könnten das Netz, wie wir es kennen, innerhalb vergleichsweise kurzer Zeit ablösen. Dabei würden sie auf dem Weg Konzepte von "geistigem Eigentum" weitgehend obsolet machen.

Wie kann die Industrie gegen solche Systeme vorgehen? Vielleicht wird man versuchen, die Programmierer zu verklagen, wie Damien Cave in einem Salon-Artikel befürchtet, vielleicht wird man das Betreiben von Hosts für illegal erklären und versuchen, die Betreiber aus der Netzgemeinschaft zu verbannen. Oder man bezahlt Cracker, um Fehler in den Protokollen für Attacken auszuspähen - insofern sind die Skript Kiddiez, die als erste solche Attacken durchführen, eine recht gute Vorbereitung auf den Ernstfall, wenn auch dennoch eine Plage für Entwickler und Nutzer. Auch wird man sicherlich versuchen, potentielle zentralisierte Elemente zu identifizieren und auszuschalten.

Vermutlich wird man alle Strategien zugleich anwenden. Wie sehr der Staat mitspielt, bleibt abzuwarten, selbst Napster, prinzipiell ein verwundbares System, ist ja nach wie vor in Betrieb.

MojoNation bietet besonders interessante Konzepte, und wer ein bisschen technisches Geschick aufweist, kann an der Beta-Phase teilnehmen (obwohl man abwarten muss, ob das BetaMojo auch in Deutschland in $ oder DM umgewandelt wird.) Auch FreeNet ist sehr vielversprechend und für anonyme Datenspeicherung ohne kommerziellen Hintergrund recht gut geeignet.

Klagen gegen individuelle Nutzer sind bei großen Systemen eher unwahrscheinlich, die Wahrscheinlichkeit steigt aber auch je nach Inhalt. Wer ein 10000 Mark teures CAD-Programm anbietet ist natürlich eher im Visier der Fahnder als jemand, der einem Freund "Master of Puppets" schickt. In ersterem Fall kann eine große Software-Firma auch schon mal mehrere 100,000 Dollar ausgeben, um Präzedenzfälle zu schaffen.

Die Verfolgung wird sicherlich mit der Bandbreite und der allgemeinen Verbreitung des Internet zunehmen. Wenn ein kompletter Film in wenigen Sekunden heruntergeladen werden kann (und das ist absehbar), wird nicht nur die MPAA noch einmal richtig aufdrehen. Massenverhaftungen sind nicht gänzlich unwahrscheinlich, besonders in den USA, wo nach Statistiken des Justice Policy Institute sowohl relativ als auch absolut mehr Menschen im Gefängnis sitzen als z.B. in China. Ein "War on Sharing" analog zum "War on Drugs" scheint besonders mit einem erzkonservativen, industriefreundlichen Präsidenten nicht undenkbar.

Der Kampf um die Informationsfreiheit ist also noch nicht entschieden. Aber wie fing eigentlich alles an? Im nächsten und letzten Teil der Serie sollen als Rückschau die ersten Internet-basierten File-Sharing-Systeme vorgestellt werden, die zwar für diesen Zweck nicht so ausgefeilt sind wie Napster und seine Freunde, aber nach wie vor beliebte Anlaufstellen bilden, insbesondere bei obskurerem Material.

Fortsetzung folgt

Vierter Teil: Die Klassiker: Usenet, IRC, FTP, WWW, Hotline

Teil 1: Napster und seine Freunde
Teil 2: Napsters Konkurenten - zentralisierte Tauschbörsen