- translated volunteer page (removed many resolved issues)
Jens Kubieziel

Jens Kubieziel commited on 2008-03-04 12:39:24
Zeige 1 geänderte Dateien mit 13 Einfügungen und 57 Löschungen.

... ...
@@ -1,5 +1,5 @@
1 1
 ## translation metadata
2
-# Based-On-Revision: 11649
2
+# Based-On-Revision: 13843
3 3
 # Last-Translator: jens@kubieziel.de, peter@palfrader.org
4 4
 
5 5
 #include "head.wmi" TITLE="Mithelfen" 
... ...
@@ -99,13 +99,6 @@
99 99
 <h2><a class="anchor" href="#Documentation">Dokumentation</a></h2>
100 100
 
101 101
 <ol>
102
-  <li>Wir h�ren, dass Tornutzer diversen
103
-  Attacken von Javascript, Java, ActiveX, Flash etc. zu Opfer
104
-  fallen. Gibt es da drau�en gute Plugins (wie NoScript f�r den
105
-  Firefox), die es den Nutzern erleichtern, diese Risiken zu meistern?
106
-  Was ist exakt das Risiko?</li>
107
-  <li>Gibt es eine komplette Seite mit Plugins, welche die komplette
108
-  Funktionalit�t von Privoxy f�r Firefox 1.5+ ersetzen?</li>
109 102
   <li>Bitte hilf Matt Edman mit der Dokumentation und HOWTOs f�r
110 103
   seinen <a href="http://vidalia-project.net/">Vidalia</a>.</li>
111 104
   <li>Kommentiere und dokumentiere unsere <a
... ...
@@ -136,38 +129,15 @@
136 129
   verwenden auf Windows den standardm��igen <code>select</code>-Systemaufruf.
137 130
   Dies bereitet gerade auf mittelgro�en Servern <a
138 131
   href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">Probleme</a>.
139
-  Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine L�sung ist,
140
-  <a href="http://www.monkey.org/~provos/libevent/">libevent</a> beizubringen, Overlapped I/O statt <code>select()</code> zu w�hlen
141
-  und Tor dann an die neue libevent-Schnittstelle anzupassen.</li>
142
-  <li>Weil die Torserver jede Zelle speichern und weitergeben m�ssen,
143
-    brauchen die Torserver mit hoher Bandbreite Dutzende Megabyte an
144
-    Speicher. Wir ben�tigen bessere Heuristiken, wenn die Buffer zu
145
-    verkleinern/vergr��ern sind. Wahrscheinlich sollte dies nach dem
146
-    Bufferdesign des Linuxkernels modelliert werden. Dort gibt es
147
-    kleinere Buffer, die sich gegenseitig verbinden.</li>
148
-  <li>Wir brauchen eine offizielle zentrale Seite, die die Frage "Ist das die
149
-  Adresse eines Torservers" beantwortet. Es sollte diverse Schnittstelle, wie
150
-  ein Webformular und DNSBL-�hnliche Abfrage, bieten. Es kann aktuelle
151
-  Informationen bieten, indem es einen lokalen Spiegel der
152
-  Verzeichnisinformationen anlegt. Du bekommst Bonuspunkte, wenn es aktiv
153
-  die Exitserver testet, wie die IP-Adresse ist.  Der schwierige Punkt ist, das
154
-  die Eigenschaft, Exitserver zu sein, nicht einfach mit ja oder nein zu
155
-  beantworten ist. Daher ist die Frage eher: "Ist diese IP-Adresse ein
156
-  Exiterver, der mich zur IP-Adresse:Port weitergibt?". Die DNSBL-Schnittstelle
157
-  wird wahrscheinlich Hunderte von Anfragen pro Minute bekommen. Daher sind hier
158
-  intelligente Algorithmen gefragt. <a
159
-  href="<svnsandbox>doc/contrib/torbl-design.txt">Hier</a> kannst du mehr dazu
160
-  lesen.</li>
161
-  <li>Manchmal st�rzen Torserver ab oder die Computer, auf denen das Programm
162
-  l�uft, verschwinden vom Netz. Manche Betreiber von Tor haben Interesse
163
-  ge�u�ert, an einem Service teilzunehmen, der in regelm��igen Abst�nden pr�ft,
164
-  ob der jeweilige Torserver noch l�uft und Mails versendet, falls das nicht der
165
-  Fall ist. Eventuell m�chte jemand ein paar CGI-Skripte und Webseiten schreiben
166
-  and einen wget-hack oder etwas komplexeres wie <a
167
-  href="http://nagios.org/">Nagios</a> f�r das Monitoring machen? Die erste
168
-  Version sollte nur den Directoryport pr�fen. Beispielsweise k�nnte das
169
-  Programm durch die Netzwerkstatusseite nach der richtigen IP-Adresse sowie
170
-  Port schauen und dann nach der "/tor/server/authority"-Seite.</li>
132
+  Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine L�sung
133
+  w�re, <a href="http://www.monkey.org/~provos/libevent/">libevent</a>
134
+  beizubringen, Overlapped I/O statt <code>select()</code> zu w�hlen. Tor muss
135
+  dann an die neue libevent-Schnittstelle angepasst werden. Christian King hat
136
+  <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">einen guten
137
+  Anfang</a> gemacht.</li>
138
+  <li>Wie k�nnen wir die <a
139
+  href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> leichter
140
+  zu warten, verbessern und zu dokumentieren machen?</li>
171 141
   <li>Wir brauchen ein verteiltes Testger�st. Bisher haben wir Unittests. Es
172 142
   w�re gro�artig, ein Skript zu haben, welches ein Tornetzwerk startet und dort
173 143
   f�r einige Zeit testet, ob die Erneuerungen funktionieren.</li>
... ...
@@ -178,23 +148,6 @@ r href="https://www.torproject.org/svn/torflow/">TorFlow</a>-Bibliothek (<a
178 148
   href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Controller Protokoll
179 149
   </a> nutzt, um mit Tor eine Vielzahl von Verbindungen zu schaffen, diese zu
180 150
   messen und Anomalien festzustellen.</li>
181
-  <li>Wir brauchen eine Messung von <a
182
-  href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> und <a
183
-  href="http://www.privoxy.org/">Privoxy</a>. Ist Polipo wirklich schneller,
184
-  wenn man die Verlangsamung durch Tor mit einrechnet? Behandelt Polipo die
185
-  Webseiten korrekter als Privoxy? Gibt es Probleme mit der Stabilit�t bei den
186
-  h�ufig genutzten Plattformen?</li>
187
-  <li>Es w�re gro�artig, wenn es eine Live-CD mit den aktuellsten Versionen von
188
-  Tor, Polipo oder Privoxy, Firefox, Pidgin+OTR usw. g�be. Es gibt hier zwei
189
-  Herausforderungen: Zum einen muss das System dokumentiert werden und zum
190
-  anderen m�ssen wir herausfinden, wie das leicht zu pflegen ist. Es sollte
191
-  nicht so schnell obsolet werden, wie AnonymOS. Bonuspunkte gibt es, wenn die
192
-  CD auf eine kleine CD (50MB) passt.</li>
193
-  <li>In Bezug auf das CD-Image sollten wir auch an einer sicheren und gut
194
-  dokumentierten USB-Variante f�r Tor und unterst�tzete Anwendungen arbeiten.
195
-  Der schwierige Teil ist zu entscheiden, welche Konfigurationen sicher sind,
196
-  diese Entscheidungen zu dokumentieren und etwas zu schaffen, das leicht zu
197
-  pflegen ist.</li>
198 151
   <li>Wir sollten damit anfangen unser <a href="<page
199 152
   documentation>#DesignDoc">gegen Blockierungen gesch�tztes Design</a> zu
200 153
   implementieren. Dies beinhaltet die Ausarbeitung des Designs, die
... ...
@@ -245,6 +198,9 @@ r href="https://www.torproject.org/svn/torflow/">TorFlow</a>-Bibliothek (<a
245 198
   <li>Wir sind nicht weit davon entfernt, Unterst�tzung f�r IPv6 bei
246 199
     Exitknoten zu haben. Falls du dich stark um IPv6 k�mmerst, ist
247 200
     das wahrscheinlich der Platz, um zu starten.</li>
201
+  <li>Du magst keinen von den obigen Punkten? Schaue dir die <a
202
+  href="<svnsandbox>doc/design-paper/roadmap-future.pdf">weiteren Pl�ne</a> f�r
203
+  weitere Ideen an.</li>
248 204
 </ol>
249 205
 
250 206
 <a id="Research"></a>
251 207