tor-webwml.git

@@ -0,0 +1,318 @@

+## translation metadata

+# Based-On-Revision: 18017

+# Last-Translator: mail %a_t% oliverknapp.de

+

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

+

+<div class="main-column">

+

+<!-- PUT CONTENT AFTER THIS TAG -->

+

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

+<hr />

+

+<p>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>

+

+<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.</p>

+

+<p>

+Dieses Projekt wird großzügigerweise gesponsert von:

+</p>

+

+<p>

+<a href="http://www.nlnet.nl/news/2008/20080514-awards.html">

+<img src="$(IMGROOT)/nlnet-160x60.png" alt="Der NLnet Stiftung" /></a>

+</p>

+

+<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> <b>Etappe A:</b> Design und Überprüfung der

+Protokollveränderung.<br /> <small><em>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. </em></small> </td> <td> 15. Juli 2008 </td> </tr>

+

+<tr> <td> <b>Etappe B:</b>Umsetzung der Protokollveränderung<br /> <small><em>

+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. </em> </small> </td>

+<td> 15. Oktober 2008 </td> </tr>

+

+<tr bgcolor="#e5e5e5"> <td> <b>Etappe C:</b>Tests<br /> <small><em>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.

+</em></small> </td> <td> 15. Januar 2009 </td> </tr>

+

+<tr> <td> <b>Etappe D:</b>Veröffentlichung<br /> <small><em>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. </em></small> </td> <td> 15. April

+2009 </td> </tr> </table>

+

+<br />

+

+<a id="Reports"></a> < h2><a class="anchor" href="#Reports">Monatliche

+Statusberichte</a></h2> <p>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. </p>

+

+<table width="100%" border="0" cellspacing="0" cellpadding="3">

+<thead>

+<tr>

+<th><big>Monat,</big></th>

+<th><big>Statusbericht</big></th>

+</tr>

+</thead>

+

+<tr bgcolor="#e5e5e5">

+  <td>

+    <a id="Jun08"></a>

+    <a class="anchor" href="#Jun08">Juni 08</a>

+  </td>

+

+<td> <small><em>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).</em></small> <br />

+

+<small><em><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.</em></small> <br />

+

+<small><em><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.</em></small> <br />

+

+<small><em>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.</em></small> </td> </tr>

+

+<tr>

+  <td>

+    <a id="Jul08"></a>

+    <a class="anchor" href="#Jul08">Juli 08</a>

+  </td>

+  

+<td> <small><em>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.</em></small> <br />

+

+<small><em>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.</em></small> </td> </tr>

+

+<tr bgcolor="#e5e5e5">

+  <td>

+    <a id="Aug08"></a>

+    <a class="anchor" href="#Aug08">Aug. 08</a>

+  </td>

+  

+<td> <small><em>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. </em></small> </td> </tr>

+

+<tr>

+  <td>

+    <a id="Sep08"></a>

+    <a class="anchor" href="#Sep08">Sept. 08</a>

+  </td>

+  <td>

+<small><em>Leider keine neuen Informationen im September</em></small>

+  </td>

+</tr>

+

+<tr bgcolor="#e5e5e5">

+  <td>

+    <a id="Oct08"></a>

+    <a class="anchor" href="#Oct08">Okt. 08</a>

+  </td>

+  

+<td> <small><em><p>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.</p>

+

+<p>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.</p>

+

+<p>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.</p>

+

+<p>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!</p></em></small> </td> </tr>

+

+<tr>

+  <td>

+    <a id="Nov08"></a>

+    <a class="anchor" href="#Nov08">Nov. 08</a>

+  </td>

+

+<td> <small><em><p>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.</p>

+

+<p> 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>.</p>

+

+<p>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>.</p>

+

+<p>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..</p>

+

+<p>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.</p></em></small> </td> </tr>

+

+<tr bgcolor="#e5e5e5">

+  <td>

+    Dez 08

+  </td>

+  <td>

+  </td>

+</tr>

+

+<tr>

+  <td>

+    Jan 09

+  </td>

+  <td>

+  </td>

+</tr>

+</table>

+

+<br />

+

+<!-- Do we want a people section? If so, would it make sense to write what

+these people will be doing? And what exactly are these people going to

+do? :)

+<a id="People"></a>

+<h2><a class="anchor" href="#People">People</a></h2>

+<ul>

+<li><a href="<page people>#Core">Peter Palfrader</a></li>

+</ul>

+-->

+

+<!-- In the future, put links to proposal, preliminary results, etc. here -->

+

+</div><!-- #main -->

+

+#include <foot.wmi>

\ No newline at end of file