projects/de/lowbandwidth.wml (2a9aaa802) - tor-webwml.git

lowbandwidth.wml

## translation metadata
# Based-On-Revision: 18524
# Last-Translator: mail %a_t% oliverknapp.de

#include "head.wmi" TITLE="NLnet Projekt: Tor für Clients mit wenig Bandbreite" CHARSET="UTF-8"

<h2>NLnet Projekt: Tor für Clients mit wenig Bandbreite</h2>
<hr />

Tor ist momentan nur von Benutzern mit einer breitbandigen
Internetverbindung nutzbar. Beim Start von Tor wird eine große Datei mit
Informationen über alle Server heruntergeladen. Diese Datei ist das sogenannte
Tor-Verzeichnis und ermöglicht dem Client Tor-Server für eine Route durch das
Netzwerk auszuwählen. Das aktuelle Tor-Protokoll benötigt dafür das gesamte
Verzeichnis. Die Datei ist allerdings viel zu groß für Nutzer mit Modem oder
mobilen Datendiensten wie GPRS, da dieser initiale Download der bei jedem
Torstart nötig ist, bei solch einer langsamen Leitung zwischen 10 und 30
Minuten dauert. Daraus folgt, dass Tor für Benutzer die mit Modem oder via
GPRS surfen, nicht benutzbar ist. Eines der Hauptziele von Tor ist es, Menschen
in Diktaturen oder repressiven Staaten einen sicheren, anonymen Internetzugang
zu bieten. Diese Menschen haben aber oft eine sehr langsame Internetverbindung,
 sei es, weil sie ein Modem nutzen müssen, oder weil die Länder nur
schmalbandig an das Internet angeschlossen sind. Wenn man diesen Menschen den
Zugang zu Tor ermöglicht, ist dies ein großer Fortschritt für die Freiheit
dieser Länder./p>

Um Tor auch für Nutzer mit schmalbandigen Verbindungen benutzbar zu machen,
benötigen wir eine neue Version des Torprotokolls, was die anfängliche
Downloadmenge reduziert. Diese neue Protokollversion soll die Art und Weise
verändern, in der ein Client die Informationen für die initiale
Verbindungsherstellung empfängt, damit der Download auch über ein 14,4 kbps
Modem innerhalb von 3 Minuten geschieht. Die Arbeit, die an diesem Vorschlag
gemacht wird, hat als Endziel, dass diese Protokollveränderung innerhalb von
12 Monaten umgesetzt ist und an die Endnutzer verteilt werden kann. Die aus
dem Projekt entstehende Software wird unter der 3-Clause BSD Lizenz
veröffentlicht, wie auch der Rest des Tor Codes. Alle Zwischenstände werden
öffentlich sein.

Dieses Projekt wird großzügigerweise gesponsert von:

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Projekt</big></th>
<th><big>Fälligkeit</big></th>
</tr>
</thead>

<tr bgcolor="#e5e5e5"> <td> Etappe A: Design und Überprüfung der
Protokollveränderung. Diese Etappe enthält das detaillierte
Design und eine simulationsbasierte Überprüfung der notwendigen Veränderungen
und Modifikationen am aktuellen Torprotokoll. Die Veränderungen am Protokoll
sind recht tiefgehend und müssen daher genaustens auf mögliche Gefahren für
die Sicherheit und Anonymität des Tor-Netzes überprüft werden. Für diese
Etappe sind 2 Monate eingeplant, die von einem intensiven, externen
Überprüfung abgeschlossenn wird. Ein Teil von Etappe A wird es auch sein, eine
Zielsetzung für die Geschwindigkeitssteigerung in der Implementierungsphase zu
definieren. Das Designziel ist es, dass Tor-Verzeichnis welches initial
runtergeladen werden muss auf etwa 300 Kilobytes zu verkleinern, was einem
User mit einer 14,4 Kbps Leitung erlauben würde, es in etwa 3 Minuten
runterzuladen. Sollte es für die Sicherheit oder Anonymität notwendig sein,
können von diesem Ziel Abstriche gemacht werden, allerdings ist es das Ziel,
auf das wir hinarbeiten. </td> <td> 15. Juli 2008 </td> </tr>

<tr> <td> Etappe B:Umsetzung der Protokollveränderung 
Nach Design, Überprüfung und externer Kontrolle müssen die Veränderungen
umgesetzt und in die aktuelle Torcodebasis eingepflegt werden. Die eigentliche
Umsetzung der Veränderungen wird etwa 3 Monate dauern. </td>
<td> 15. Oktober 2008 </td> </tr>

<tr bgcolor="#e5e5e5"> <td> Etappe C:Tests Da die
Veränderung hochkritisch für die Sicherheit und Anonymität des Tornetzwerks
ist, erfordert sie umfangreiche Überprüfung und Fehlersuche unter Labor- und
Realbedingungen. Eine Dauer von 3 Monaten ist für die Tesphase vorgesehen, in
der der verantwortliche Entwickler einen Drittel seiner Zeit mit Testen
verbringt. Ein Teil der Testphase wird auch ein öffentlicher Betatest sein.
 </td> <td> 15. Januar 2009 </td> </tr>

<tr> <td> Etappe D:Veröffentlichung Die eigentliche
Veröffentlichung wird mit dem normalen Veröffentlichungsplan von Tor
abgestimmt. Da dieses Projekt von mehreren externen Faktoren, wie der
Fertigstellung anderer Softwareprojekten, die in die gleiche Version eingebaut
werden sollen, abhängt, kann die Zeit zwischen Veröffentlichung und die Zeit
bis die Veränderung von den meisten Serverbetreibern installiert wurde,
abweichen. Die Veröffentlichung wird innerhalb des normalern
Veröffentlichungsplans von Tor stattfinden. Dabei handelt es sich um eine
stetige Arbeit, die von vielen Freiwilligen und Personal das von anderen
Sponsoren bezahlt wird, durchgeführt wird. </td> <td> 15. April
2009 </td> </tr> </table>

<a id="Reports"></a> < h2><a class="anchor" href="#Reports">Monatliche
Statusberichte</a></h2> Es wird insgesamt 8 monatliche Statusberichte
geben. Beginnend mit der ersten Etappe am 15. Juli 2008, endend mit dem
Abschluss der Umsetzung und der Tests am 15. Januar 2009.

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Monat,</big></th>
<th><big>Statusbericht</big></th>
</tr>
</thead>

<td> Wir haben einige anfängliche Messungen von Tor-Clients beim
Starten gemacht. Die Ergebnisse sind nicht unbedingt überraschend: Ein Client
holt sich etwa 10 KB Zertifikate, einen unterschriebenen Netzwerkstatuss mit
140 KB (jetzt nur noch 90 KB, siehe nächster Abschnitt) und etwa 1,5 MB
Serverbeschreibungen (nach der Hälfte davon beginnt er mit dem
Pfadaufbau).

<a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">
Vorschlag 138</a> verkleinert den Netzwerkstatus um etwa 30-40% und wurde bereits
umgesetzt und in die Spezifikationen übernommen. Die Umsetzung ist Teil der
0.2.1.x-alpha Versionen und wird Effekt zeigen, sobald mehr als zwei Drittel
der Verzeichnisauthoritäten (also 5 von 6) auf diese Version gewechselt
haben.

<a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">
Vorschlag 140</a> hängt nicht direkt mit der anfänglich zu downloadenden Menge
zusammen, sondern versucht die folgenden Downloads für weitere
Netzwerkstatusdokumente ein paar Byte kleiner zu machen. Der Vorschlag wurde
bereits aufgeschrieben und an <a
href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">or-dev
geschickt</a>. Es gibt ein paar Fragen, die erst von anderen Torentwicklern
beantwortet werden müssen, aber ich denke der Vorschlag könnte umgesetzt
werden.

Der interessante Punkt wäre aber, dass die Clients nicht mehr 1,5
MB an Serverbeschreibungen runterladen. <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">
Vorschlag 141</a> wurde an <a
href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">or-dev
geschickt</a>. Es gibt vor allem 3 Sachen zu machen, so weit ich momentan
sehen kann: wir brauchen Lastverteilungsinformationen im Netzwerkstatus
(sollte nicht so schwer sein), wir müssen etwas einbauen, damit Tor-Clients
Serverbeschreibungen bei Bedarf von den Servern im Pfad beziehen können,
während Sie diesen aufbauen und wir müssen uns um die Wahl des Exits kümmern.
Wir entwickeln immer noch Ideen für den letzten Teil; ein paar Vorschläge
stehen bereits im Vorschlag. </td> </tr>

<tr>
 <td>
 <a id="Jul08"></a>
 <a class="anchor" href="#Jul08">Juli 08</a>
 </td>
 
<td> Die Arbeit an <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">
Vorschlag 141</a> geht weiter: Es gibt 2 grundlegende Ideen, wie man
Lastverteilungsinformationen in den Netzwerkstatus reinbekommt: Die eine ist,
dass die Authoritäten die Gewichte generieren, die die Clients benutzen sollen
und das in den Status reinpacken, der andere Ansatz ist, einfach nur
Bandbreiteninformationen aus den Serverbeschreibungen dort reinzutun. Der
zweite Ansatz ist wahrscheinlich besser, wenn man auch <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">
Vorschlag 140</a> mitbetrachtet, da es verhindern würde, dass sich die Nummern
im Netzwerkstatus sehr oft ändern.

Für den Umgang mit Exitregeln schlägt <a
href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">eine Nachricht
auf der or-dev Mailingliste</a> vor, dass ein Hash der die Exitregeln eines
Servers beschreibt zum Netzwerkstatus hinzugefügt wird. Das Einfügen von
weiteren, unvorhersehbaren 160 Bits pro Knoten in den Netzwerkstatus könnte
problematisch sein, aber da viele Exitregeln ähnlich sind, denken wir, dass
der Status gut komprimiert werden kann. Messungen müssen noch durchgeführt
werden. </td> </tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Aug08"></a>
 <a class="anchor" href="#Aug08">Aug. 08</a>
 </td>
 
<td> Die Daten der Verzeichnisautoritäten und der Algorithmus wie
daraus der Netzwerkstatus gebildet wird, wurden dahingehend geändert, dass sie
Bandbreiteninformationen und Exitregeln beinhalten, wie das in Vorschlag 141
dokumentiert ist. Sobald 5 von 6 Authoritäten auf eine Version die dies
enthält (ab Revision 16554) geupgraded haben, wird der Netzwerkstatus diese
Informationen enthalten. </td> </tr>

<tr>
 <td>
 <a id="Sep08"></a>
 <a class="anchor" href="#Sep08">Sept. 08</a>
 </td>
 <td>
Leider keine neuen Informationen im September
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Oct08"></a>
 <a class="anchor" href="#Oct08">Okt. 08</a>
 </td>
 
<td> Wir haben unseren "Fertig mit der Umsetzung" Meilenstein
diesen Monat nicht erreicht, da der Entwickler der dieses Projekt leitet, zu
viel um die Ohren hat. Die gute Nachricht ist, dass wir einen großen Teil der
Umsetzungsarbeit fertig haben und dieser Teil schon seit mehreren Monaten
(genauer seit August) in Tor ist und daher schon intensiv getestet wurde. Die
noch fehlenden Schritte sind, dass wir Clients beibringen müssen, mit Anfragen
nach Serverbeschreibungsdateien innerhalb eines Pfades umzugehen (wofür wir
wahrscheinlich einen neuen Zellentyp nutzen wollen, um einen ganzen Roundtrip
zu sparen) und dann den Clients beizubringen, das auch zu machen, wenn der
Server den sie nutzen eine Version verwendet, die aktuell genug ist. Diese
beiden Schritte sind etwas detaillierter unter <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">
Abschnitt 3.2 von Vorschlag 141</a> beschrieben.

Unser neues Ziel ist es, diese beiden Teile bis Mitte November fertig zu
haben, wenn das nicht mehr wahrscheinlich ist, werden wir unseren Zeitplan
komplett überarbeiten und vielleicht unser Design überdenken.

Es gibt noch viele weitere Komponenten, um die wir uns nach diesem kümmern
wollen -- eine, über die wir uns aktuelle viele Gedanken machen, ist das
Herunterladen von "Unterschieden" zum letzten Netzwerkstatus: <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">
140-consensus-diffs.txt</a>. Dies könnte zum Einen Bandbreite sparen, was
immer schön ist, wenn man das mit der Anzahl der Nutzer multipliziert, aber es
bedeutet auch, dass wir diese eingesparte Bandbreite nutzen können, diese
Unterschiede öfter als "alle 3 bis 4 Stunden" zu laden. Wenn die Nutzer öfter
als jetzt aktuelle Verzeichnisinformationen haben, können sie schnellere Pfade
bauen, da sie bessere Informationen über die Bandbreite der Server haben (was
mit dem ersten NLnet Projekt weiter oben zusammenhängt), aber die neue
Hauptidee ist, dass wir Server die nur kurz online sind besser nutzen können:
Momentan muss ein Server mindestens 3 bis 4 Stunden online sein, bis er
irgendwelche Nutzer bekommt, was eine Menge Freiwillige ausschliest, die einen
Server betrieben wollen, aber diesen nur wenige Stunden am Stück betrieben
können.

Der nächste Schritt ist, dass wir die Umsetzung von Vorschlag 141 fertig
bekommen, so dass wir ihn schnell an die Nutzer zum Testen geben können. Wir
hoffen, das passiert bald! </td> </tr>

<td> Es scheint, als ob unser ursprüngliche Plan für das letzte
Entwicklungsstück sowohl a) deutlich schwerer war als wir gehofft hatten und b)
 hoffentlich viel zu viel war für das was wir eigentlich brauchen.

Roger hat die Designdiskussion auf or-dev neugestartet: <a
href="http://archives.seul.org/or/dev/Nov-2008/threads.html">
http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.

Ich glaube wir haben jetzt einen besseren Zugang zu den Optionen und
Einschränkungen: <a
href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">
http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.

Nick wurde mit anderen Entwicklungsprojekten begraben (hoffentlich beginnt
er damit, dass monatlich zusammenzufassen) und ich will seine Meinung über das
weitere Vorgehen; Ich hoffe, wir suchen uns eine der einfacheren
Vorgehensweise aus..

Wie auch immer, die wirklich einfachen Ideen können nicht so gut skaliert
werden. Aber ich denke sie sind gute Lückenfüller bis später -- und wer weiß.
was sich alles bis "später" noch geändert hat. </td> </tr>

Ich habe eine etwas genauere Version von unserer neuen
Designidee als <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt">
 Vorschlag #158</a> aufgeschrieben und die Diskussion ist bereits losgegangen:
<a href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html">
http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.

Ich denke das ist endlich die Idee! (Also wenn ich alle Kommentare
eingebaut habe.)

Einer der Gründe, warum dieses Projekt nicht mehr im Zeitplan ist, ist das
wir durch das <a href="<page projects/hidserv>">NLnet Projekt über die
Geschwindigkeit versteckter Dienste von Karsten</a> wissen, dass die
Pfadverlängerung das Hauptproblem ist. Dieses Projekt würde deutlich mehr
Komplexität in genau diesen Schritt bringen. Daher brauchen wir einen besseren
Plan um das eigentliche Ziel zu erreichen ohne die Leistung noch mehr
einzuschränken.

Wir haben die vorgeschlagene Designänderung in den letzten Wochen nochmal
betrachtet und Ich denke wir können bald mit der Umsetzung beginnen. Da wir
bereits eine Menge von Entwicklungsprojekten Mitte Februar fertig haben wollen,
 ist es sehr wahrscheinlich, dass die Umsetzung erst Ende Februar oder im März
was wird. Diesmal aber sicher!

</div>

#include <foot.wmi>

tor-webwml.git

first cut of the new, shiny tor website as wml.