tor-webwml.git

de/volunteer.wml        1) ## translation metadata

de/volunteer.wml        2) # Based-On-Revision: 18156

de/volunteer.wml        3) # Last-Translator: jens@kubieziel.de, peter@palfrader.org

de/volunteer.de.html    4) 

de/volunteer.wml        5) #include "head.wmi" TITLE="Tor: Mithelfen" CHARSET="UTF-8"

de/contribute.de.html   6) 
de/contribute.de.html   7) <div class="main-column">
de/contribute.de.html   8) 
de/contribute.de.html   9) <!-- PUT CONTENT AFTER THIS TAG -->
de/contribute.de.html  10) 

de/volunteer.wml       11) <h2>Einige Dinge, die jeder tun kann</h2>

de/contribute.de.html  12) 

de/volunteer.de.html   13) <ol>

de/volunteer.wml       14)   <li>Bitte überlege dir,

de/volunteer.wml       15)     einen <a href="<page docs/tor-doc-relay>">Server zu

de/volunteer.wml       16)     betreiben</a>, damit das Netzwerk weiter wächst.</li>
de/volunteer.wml       17)   <li>Erzähl es deinen Freunden! Bringe sie dazu, auch Server zu

de/volunteer.de.html   18)     betreiben.  Bringe sie dazu, auch versteckte Services zu
de/volunteer.de.html   19)     betreiben. Bringe sie dazu, es wieder ihren Freunden zu

de/volunteer.wml       20)     erzählen.</li>

de/volunteer.wml       21)   <li>Wenn du die Ziele von Tor magst, bitte nimm dir einen Moment

de/volunteer.wml       22)   Zeit, um für das <a href="<page donate>">Projekt zu spenden</a>. Wir

de/volunteer.wml       23)   sind auch auf der Suche nach weiteren Sponsoren — wenn du

de/volunteer.wml       24)   Firmen, NGOs oder andere Organisationen kennst, die Anonymität,
de/volunteer.wml       25)   Privatsphäre und die Sicherheit der Kommunikation schätzen, dann

de/volunteer.wml       26)   lass sie von uns wissen.</li>
de/volunteer.wml       27)   <li>Wir suchen nach weiteren <a href="<page torusers>">guten

de/volunteer.wml       28)   Beispielen für Nutzer von Tor oder von Anwendungsfällen</a>. Falls
de/volunteer.wml       29)   du Tor für ein bestimmtes Szenario verwendest und uns davon erzählen
de/volunteer.wml       30)   möchtest, freuen wir uns, darüber zu hören.</li>

de/volunteer.wml       31)   </ol>
de/volunteer.wml       32) 

de/volunteer.wml       33) <a id="Usability"></a>

de/volunteer.wml       34) <h2><a class="anchor" href="#Usability">unterstützende Anwendungen</a></h2>

de/volunteer.de.html   35) 
de/volunteer.de.html   36) <ol>

de/volunteer.wml       37)   <li>Wir brauchen gute Methoden, um DNS-Abfragen abzufangen, damit diese

de/volunteer.wml       38)   nicht an einen lokalen Beobachter dringen, während wir versuchen, anonym zu

de/volunteer.wml       39)   bleiben. (Dies passiert, weil die Anwendung selbst DNS-Anfragen

de/volunteer.wml       40)   stellt, anstatt diese über Tor zu leiten.).

de/volunteer.wml       41)   <ul>

de/volunteer.wml       42)     <li>Wir müssen <a

de/volunteer.wml       43)     href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">all

de/volunteer.wml       44)     unsere Patches für tsocks</a> einspielen und einen Fork
de/volunteer.wml       45)     betreuen. Wir würden diesen auch auf unserem Server mit anbieten, wenn
de/volunteer.wml       46)     du möchtest.</li>

de/volunteer.wml       47)     <li>Wir sollten das Programm dsocks von Dug Song patchen, so dass es
de/volunteer.wml       48)     das Kommando <code>mapaddress</code> von der Controllerschnittstelle
de/volunteer.wml       49)     nutzt. Somit verschwenden wir nicht einen gesamten Round-trip

de/volunteer.wml       50)     innerhalb von Tor, um die Auflösung vor der Verbindung zu

de/volunteer.wml       51)     machen.</li>

de/volunteer.wml       52)     <li>Wir müssen unser <kbd>torify</kbd>-Skript so umgestalten, dass

de/volunteer.wml       53)     es erkennt, welches tsocks oder dsocks installiert ist und dieses
de/volunteer.wml       54)     dann richtig aufruft. Das bedeutet wahrscheinlich, dass deren

de/volunteer.wml       55)     Schnittstellen vereinheitlicht werden müssen und führt wahrscheinlich

de/volunteer.wml       56)     dazu, dass Code zwischen beiden geteilt werden muss oder dass eines
de/volunteer.wml       57)     komplett nicht mehr benutzt wird.</li>
de/volunteer.wml       58)   </ul></li>

de/volunteer.de.html   59)   <li>Leute, die einen Server betreiben, teilen uns immer wieder mit,

de/volunteer.wml       60)     dass sie <var>BandwidthRate</var> in Abhängigkeit von der Uhrzeit setzen

de/volunteer.wml       61)     wollen. Anstatt das

de/volunteer.de.html   62)     direkt in Tor zu implementieren, sollten wir lieber ein kleines

de/volunteer.wml       63)     Skript haben, das über die <a href="<page gui/index>">Torschnittstelle</a>
de/volunteer.wml       64)     spricht und ein <code>setconf</code> macht, um die Änderungen
de/volunteer.wml       65)     herbeizuführen. Natürlich würde es durch Cron ausgeführt oder es
de/volunteer.wml       66)     schläft eine bestimmte Zeit und macht dann die Änderungen. Kann
de/volunteer.wml       67)     das jemand für uns schreiben und wir packen das dann
de/volunteer.wml       68)     nach <a href="<svnsandbox>contrib/">contrib</a>? Das wäre
de/volunteer.wml       69)   eine gute Möglichkeit für den <a href="<page gui/index>">Tor GUI

de/volunteer.wml       70)   Wettbewerb</a>.</li>

de/volunteer.de.html   71)   <li>Wir haben eine Vielzahl von Wegen, um
de/volunteer.de.html   72)     das <a

de/volunteer.wml       73)     href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">Tornetzwerk

de/volunteer.de.html   74)     in einem bestimmten Land zu verlassen</a>. Aber all diese Wege

de/volunteer.wml       75)     brauchen den Namen eines speziellen Torservers. Es wäre schön,

de/volunteer.de.html   76)     wenn man nur ein Land angeben muss und automatisch wird ein

de/volunteer.wml       77)     Server ausgewählt. Der beste Weg ist wahrscheinlich, Blossoms

de/volunteer.wml       78)   Verzeichnis herunterzuladen und einen lokalen Blossomclient laufen

de/volunteer.wml       79)   zu lassen, der die Verzeichnisse sicher lädt, die

de/volunteer.wml       80)   <code>.country.blossom</code>-Hostnamen mitschneidet und dann das
de/volunteer.wml       81)   richtige tut.</li>

de/volunteer.wml       82)   <li>Wenn wir gerade bei Geolocation sind, wäre es schön, wenn

de/volunteer.de.html   83)     jemand eine Karte anfertigt, die die Standorte der Torserver

de/volunteer.wml       84)     anzeigt. Bonuspunkte gibt es, wenn es sich bei Änderungen am

de/volunteer.wml       85)     Netzwerk auf den neuesten Stand bringt. Der leichteste Weg, um

de/volunteer.wml       86)   dies zu erreichen, wäre alle Daten zu Google zu schicken und diese
de/volunteer.wml       87)   machen dann die Karte für uns. Wie sehr beeinflusst dies die
de/volunteer.wml       88)   Privatsphäre und haben wir noch andere gute Optionen?</li>

de/volunteer.de.html   89)   <li>Tor bietet anonyme Verbindungen. Wenn du jedoch verschiedene

de/volunteer.wml       90)     Pseudonyme haben möchtest (z.B. rufst du desöfteren zwei Webseiten
de/volunteer.wml       91)     auf und wenn das jemand weiß, kann er auf dich schliessen.),
de/volunteer.wml       92)     unterstützen wir das nicht sehr gut.  Wir sollten einen guten

de/volunteer.de.html   93)     Ansatz und eine Schnittstelle zur Handhabung von pseudonymen
de/volunteer.de.html   94)     Profilen finden. Schaue dir
de/volunteer.de.html   95)     den <a
de/volunteer.de.html   96)     href="http://archives.seul.org/or/talk/Dec-2004/msg00086.html">Beitrag
de/volunteer.de.html   97)     </a> und den <a
de/volunteer.de.html   98)     href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html">Followup</a>

de/volunteer.wml       99)     für mehr Details an.</li>

de/volunteer.de.html  100) </ol>
de/volunteer.de.html  101) 

de/volunteer.wml      102) <a id="Documentation"></a>
de/volunteer.wml      103) <h2><a class="anchor" href="#Documentation">Dokumentation</a></h2>

de/volunteer.de.html  104) 
de/volunteer.de.html  105) <ol>

de/volunteer.wml      106)   <li>Bitte hilf Matt Edman mit der Dokumentation und HOWTOs für

de/volunteer.wml      107)   seinen <a href="http://vidalia-project.net/">Vidalia</a>.</li>

de/volunteer.wml      108)   <li>Kommentiere und dokumentiere unsere <a

de/volunteer.wml      109)     href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">Liste

de/volunteer.wml      110)     von Programmen, die durch Tor geroutet werden können</a>.</li>
de/volunteer.wml      111)   <li>Wir brauchen bessere Dokumentation für Programme, die dynamisch
de/volunteer.wml      112)     in Verbindungen eingreifen und diese durch Tor schicken. Für Linux

de/volunteer.wml      113)     und Windows scheinen tsocks (Linux), dsocks (BSD), und freecap gute Kandidaten.</li>

de/volunteer.de.html  114)   <li>Wir haben eine riesige

de/volunteer.wml      115)     Liste <a href="<page support>">potentiell nützlicher Programme,

de/volunteer.de.html  116)     die eine Schnittstelle zu Tor haben</a>. Welche sind in welchen
de/volunteer.de.html  117)     Situationen gut? Bitte hilf uns, diese zu testen und dokumentiere

de/volunteer.wml      118)     die Ergebnisse.</li>
de/volunteer.wml      119)   <li>Hilf, die Webseite und die Dokumentation in andere Sprachen zu

de/volunteer.wml      120)   übersetzen. Schaue dir die <a href="<page translation>">Richtlinien
de/volunteer.wml      121)   zur Übersetzung</a> an, wenn du gern helfen möchtest. Wir brauchen
de/volunteer.wml      122)   auch Leute, um die Seiten in Arabisch oder Farsi zu übersetzen. Einen
de/volunteer.wml      123)   Überblick gibt

de/volunteer.wml      124)   es bei der <a href="<page translation-status>">Statusseite der

de/volunteer.wml      125)   Übersetzungen</a>.</li>

de/volunteer.de.html  126)   </ol>
de/volunteer.de.html  127) 

de/volunteer.wml      128) <a id="Coding"></a>

de/volunteer.wml      129)   <p>Die untenstehenden Angaben wurden in der Originalsprache

de/volunteer.wml      130)   belassen. Da diese sich ausschließlich auf englischsprachige

de/volunteer.wml      131)   Bewerber beziehen.</p>
de/volunteer.wml      132) 
de/volunteer.wml      133)   <a id="Summer"></a>
de/volunteer.wml      134) <a id="Projects"></a>
de/volunteer.wml      135) <h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>
de/volunteer.wml      136) 
de/volunteer.wml      137) <p>

de/volunteer.wml      138) Here is a list of ideas that were proposed for the <a href="<page gsoc>">Google Summer of Code 2008</a>
de/volunteer.wml      139) but have not been put into practice. Some of the <a href="<svnsandbox>doc/spec/proposals/">current proposals</a> 
de/volunteer.wml      140) might also be short on developers. If you think you can help out, <a href="<page contact>"> let us know!</a> 

de/volunteer.wml      141) </p>
de/volunteer.wml      142) 
de/volunteer.wml      143) <ol>
de/volunteer.wml      144) 
de/volunteer.wml      145) <li>
de/volunteer.wml      146) <b>Tor Node Scanner improvements</b>
de/volunteer.wml      147) <br />

de/volunteer.wml      148) Similar to the SoaT exit scanner (or perhaps even during exit scanning),

de/volunteer.wml      149) statistics can be gathered about the reliability of nodes. Nodes that
de/volunteer.wml      150) fail too high a percentage of their circuits should not be given
de/volunteer.wml      151) Guard status. Perhaps they should have their reported bandwidth
de/volunteer.wml      152) penalized by some ratio as well, or just get marked as Invalid. In
de/volunteer.wml      153) addition, nodes that exhibit a very low average stream capacity but
de/volunteer.wml      154) advertise a very high node bandwidth can also be marked as Invalid.
de/volunteer.wml      155) Much of this statistics gathering is already done, it just needs to be
de/volunteer.wml      156) transformed into something that can be reported to the Directory
de/volunteer.wml      157) Authorities to blacklist/penalize nodes in such a way that clients
de/volunteer.wml      158) will listen.
de/volunteer.wml      159) <br />
de/volunteer.wml      160) In addition, these same statistics can be gathered about the traffic
de/volunteer.wml      161) through a node. Events can be added to the <a

de/volunteer.wml      162) href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Tor Control

de/volunteer.wml      163) Protocol</a> to
de/volunteer.wml      164) report if a circuit extend attempt through the node succeeds or fails, and
de/volunteer.wml      165) passive statistics can be gathered on both bandwidth and reliability
de/volunteer.wml      166) of other nodes via a node-based monitor using these events. Such a
de/volunteer.wml      167) scanner would also report information on oddly-behaving nodes to
de/volunteer.wml      168) the Directory Authorities, but a communication channel for this
de/volunteer.wml      169) currently does not exist and would need to be developed as well.
de/volunteer.wml      170) </li>
de/volunteer.wml      171) 
de/volunteer.wml      172) <li>
de/volunteer.wml      173) <b>Help track the overall Tor Network status</b>
de/volunteer.wml      174) <br />
de/volunteer.wml      175) It would be great to set up an automated system for tracking network
de/volunteer.wml      176) health over time, graphing it, etc. Part of this project would involve
de/volunteer.wml      177) inventing better metrics for assessing network health and growth. Is the
de/volunteer.wml      178) average uptime of the network increasing? How many relays are qualifying
de/volunteer.wml      179) for Guard status this month compared to last month? What's the turnover
de/volunteer.wml      180) in terms of new relays showing up and relays shutting off? Periodically
de/volunteer.wml      181) people collect brief snapshots, but where it gets really interesting is
de/volunteer.wml      182) when we start tracking data points over time.
de/volunteer.wml      183) <br />
de/volunteer.wml      184) Data could be collected from the "Tor Node Scanner" item above, from
de/volunteer.wml      185) the server descriptors that each relay publishes, and from other
de/volunteer.wml      186) sources. Results over time could be integrated into one of the <a
de/volunteer.wml      187) href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be
de/volunteer.wml      188) kept separate. Speaking of the Tor Status pages, take a look at Roger's
de/volunteer.wml      189) <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
de/volunteer.wml      190) Status wish list</a>.
de/volunteer.wml      191) </li>
de/volunteer.wml      192) 
de/volunteer.wml      193) <li>
de/volunteer.wml      194) <b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
de/volunteer.wml      195) <br />
de/volunteer.wml      196) Vidalia currently doesn't play nicely on Debian and Ubuntu with the
de/volunteer.wml      197) default Tor packages. The current Tor packages automatically start Tor
de/volunteer.wml      198) as a daemon running as the debian-tor user and (sensibly) do not have a
de/volunteer.wml      199) <a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
de/volunteer.wml      200) in the default torrc. Consequently, Vidalia will try
de/volunteer.wml      201) to start its own Tor process since it could not connect to the existing
de/volunteer.wml      202) Tor, and Vidalia's Tor process will then exit with an error message
de/volunteer.wml      203) the user likely doesn't understand since Tor cannot bind its listening
de/volunteer.wml      204) ports &mdash; they're already in use by the original Tor daemon.
de/volunteer.wml      205) <br />
de/volunteer.wml      206) The current solution involves either telling the user to stop the
de/volunteer.wml      207) existing Tor daemon and let Vidalia start its own Tor process, or
de/volunteer.wml      208) explaining to the user how to set a control port and password in their
de/volunteer.wml      209) torrc. A better solution on Debian would be to use Tor's ControlSocket,
de/volunteer.wml      210) which allows Vidalia to talk to Tor via a Unix domain socket, and could
de/volunteer.wml      211) possibly be enabled by default in Tor's Debian packages. Vidalia can
de/volunteer.wml      212) then authenticate to Tor using filesystem-based (cookie) authentication
de/volunteer.wml      213) if the user running Vidalia is also in the debian-tor group.
de/volunteer.wml      214) <br />
de/volunteer.wml      215) This project will first involve adding support for Tor's ControlSocket
de/volunteer.wml      216) to Vidalia. The student will then develop and test Debian and Ubuntu
de/volunteer.wml      217) packages for Vidalia that conform to Debian's packaging standards and
de/volunteer.wml      218) make sure they work well with the existing Tor packages. We can also
de/volunteer.wml      219) set up an apt repository to host the new Vidalia packages.
de/volunteer.wml      220) <br />
de/volunteer.wml      221) The next challenge would be to find an intuitive usable way for Vidalia
de/volunteer.wml      222) to be able to change Tor's configuration (torrc) even though it is
de/volunteer.wml      223) located in <code>/etc/tor/torrc</code> and thus immutable. The best
de/volunteer.wml      224) idea we've come up with so far is to feed Tor a new configuration via
de/volunteer.wml      225) the ControlSocket when Vidalia starts, but that's bad because Tor starts
de/volunteer.wml      226) each boot with a different configuration than the user wants. The second
de/volunteer.wml      227) best idea
de/volunteer.wml      228) we've come up with is for Vidalia to write out a temporary torrc file
de/volunteer.wml      229) and ask the user to manually move it to <code>/etc/tor/torrc</code>,
de/volunteer.wml      230) but that's bad because users shouldn't have to mess with files directly.
de/volunteer.wml      231) <br />

de/volunteer.wml      232) A person undertaking this project should have prior knowledge of

de/volunteer.wml      233) Debian package management and some C++ development experience. Previous
de/volunteer.wml      234) experience with Qt is helpful, but not required.
de/volunteer.wml      235) </li>
de/volunteer.wml      236) 
de/volunteer.wml      237) <li>
de/volunteer.wml      238) <b>Improving Tor's ability to resist censorship</b>
de/volunteer.wml      239) <br />
de/volunteer.wml      240) The Tor 0.2.0.x series makes <a
de/volunteer.wml      241) href="<svnsandbox>doc/design-paper/blocking.html">significant
de/volunteer.wml      242) improvements</a> in resisting national and organizational censorship.
de/volunteer.wml      243) But Tor still needs better mechanisms for some parts of its
de/volunteer.wml      244) anti-censorship design.  For example, current Tors can only listen on a
de/volunteer.wml      245) single address/port combination at a time.  There's
de/volunteer.wml      246) <a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
de/volunteer.wml      247) proposal to address this limitation</a> and allow clients to connect
de/volunteer.wml      248) to any given Tor on multiple addresses and ports, but it needs more
de/volunteer.wml      249) work.  Another anti-censorship project (far more difficult) is to try
de/volunteer.wml      250) to make Tor more scanning-resistant.  Right now, an adversary can identify
de/volunteer.wml      251) <a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
de/volunteer.wml      252) just by trying to connect to them, following the Tor protocol, and
de/volunteer.wml      253) seeing if they respond.  To solve this, bridges could
de/volunteer.wml      254) <a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
de/volunteer.wml      255) webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
de/volunteer.wml      256) and not act like bridges until the user provides a bridge-specific key.
de/volunteer.wml      257) <br />
de/volunteer.wml      258) This project involves a lot of research and design. One of the big
de/volunteer.wml      259) challenges will be identifying and crafting approaches that can still
de/volunteer.wml      260) resist an adversary even after the adversary knows the design, and
de/volunteer.wml      261) then trading off censorship resistance with usability and robustness.
de/volunteer.wml      262) </li>
de/volunteer.wml      263) 
de/volunteer.wml      264) <li>
de/volunteer.wml      265) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
de/volunteer.wml      266) <br />
de/volunteer.wml      267) We're in need of a good authenticated-update framework.
de/volunteer.wml      268) Vidalia already has the ability to notice when the user is running an
de/volunteer.wml      269) outdated or unrecommended version of Tor, using signed statements inside
de/volunteer.wml      270) the Tor directory information. Currently, Vidalia simply pops
de/volunteer.wml      271) up a little message box that lets the user know they should manually
de/volunteer.wml      272) upgrade. The goal of this project would be to extend Vidalia with the
de/volunteer.wml      273) ability to also fetch and install the updated Tor software for the
de/volunteer.wml      274) user. We should do the fetches via Tor when possible, but also fall back
de/volunteer.wml      275) to direct fetches in a smart way. Time permitting, we would also like
de/volunteer.wml      276) to be able to update other
de/volunteer.wml      277) applications included in the bundled installers, such as Polipo and
de/volunteer.wml      278) Vidalia itself.
de/volunteer.wml      279) <br />
de/volunteer.wml      280) To complete this project, the student will first need to first investigate
de/volunteer.wml      281) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
de/volunteer.wml      282) their strengths, weaknesses, security properties, and ability to be
de/volunteer.wml      283) integrated into Vidalia. If none are found to be suitable, the student
de/volunteer.wml      284) will design their own auto-update framework, document the design, and
de/volunteer.wml      285) then discuss the design with other developers to assess any security
de/volunteer.wml      286) issues. The student will then implement their framework (or integrate
de/volunteer.wml      287) an existing one) and test it.
de/volunteer.wml      288) <br />

de/volunteer.wml      289) A person undertaking this project should have good C++ development
de/volunteer.wml      290) experience. Previous experience with Qt is helpful, but not required. One
de/volunteer.wml      291) should also have a good understanding of common security

de/volunteer.wml      292) practices, such as package signature verification. Good writing ability
de/volunteer.wml      293) is also important for this project, since a vital step of the project

de/volunteer.wml      294) will be producing a design document to review and discuss
de/volunteer.wml      295) with others prior to implementation.

de/volunteer.wml      296) </li>
de/volunteer.wml      297) 
de/volunteer.wml      298) <li>
de/volunteer.wml      299) <b>An Improved and More Usable Network Map in Vidalia</b>
de/volunteer.wml      300) <br />
de/volunteer.wml      301) One of Vidalia's existing features is a network map that shows the user
de/volunteer.wml      302) the approximate geographic location of relays in the Tor network and
de/volunteer.wml      303) plots the paths the user's traffic takes as it is tunneled through the
de/volunteer.wml      304) Tor network. The map is currently not very interactive and has rather
de/volunteer.wml      305) poor graphics. Instead, we would like to leverage KDE's Marble widget
de/volunteer.wml      306) that gives us a better quality map and enables improved interactivity,
de/volunteer.wml      307) such as allowing the user to click on individual relays or circuits to
de/volunteer.wml      308) display additional information. We might also consider adding the ability
de/volunteer.wml      309) for users to click on a particular relay or a country containing one or
de/volunteer.wml      310) more Tor exit relays and say, "I want my connections to foo.com to exit
de/volunteer.wml      311) from here."
de/volunteer.wml      312) <br />

de/volunteer.wml      313) This project will first involve getting familiar with Vidalia
de/volunteer.wml      314) and the Marble widget's API. One will then integrate the widget

de/volunteer.wml      315) into Vidalia and customize Marble to be better suited for our application,
de/volunteer.wml      316) such as making circuits clickable, storing cached map data in Vidalia's
de/volunteer.wml      317) own data directory, and customizing some of the widget's dialogs.
de/volunteer.wml      318) <br />

de/volunteer.wml      319) A person undertaking this project should have good C++ development

de/volunteer.wml      320) experience. Previous experience with Qt and CMake is helpful, but not
de/volunteer.wml      321) required.
de/volunteer.wml      322) </li>
de/volunteer.wml      323) 
de/volunteer.wml      324) <li>
de/volunteer.wml      325) <b>Tor Controller Status Event Interface</b>
de/volunteer.wml      326) <br />
de/volunteer.wml      327) There are a number of status changes inside Tor of which the user may need
de/volunteer.wml      328) to be informed. For example, if the user is trying to set up his Tor as a
de/volunteer.wml      329) relay and Tor decides that its ports are not reachable from outside
de/volunteer.wml      330) the user's network, we should alert the user. Currently, all the user
de/volunteer.wml      331) gets is a couple log messages in Vidalia's 'message log' window, which they
de/volunteer.wml      332) likely never see since they don't receive a notification that something
de/volunteer.wml      333) has gone wrong. Even if the user does actually look at the message log,
de/volunteer.wml      334) most of the messages make little sense to the novice user.
de/volunteer.wml      335) <br />
de/volunteer.wml      336) Tor has the ability to inform Vidalia of many such status changes, and
de/volunteer.wml      337) we recently implemented support for a couple of these events. Still,
de/volunteer.wml      338) there are many more status events the user should be informed of and we
de/volunteer.wml      339) need a better UI for actually displaying them to the user.
de/volunteer.wml      340) <br />
de/volunteer.wml      341) The goal of this project then is to design and implement a UI for
de/volunteer.wml      342) displaying Tor status events to the user. For example, we might put a
de/volunteer.wml      343) little badge on Vidalia's tray icon that alerts the user to new status
de/volunteer.wml      344) events they should look at. Double-clicking the icon could bring up a
de/volunteer.wml      345) dialog that summarizes recent status events in simple terms and maybe
de/volunteer.wml      346) suggests a remedy for any negative events if they can be corrected by

de/volunteer.wml      347) the user. Of course, this is just an example and one is free to

de/volunteer.wml      348) suggest another approach.
de/volunteer.wml      349) <br />

de/volunteer.wml      350) A person undertaking this project should have good UI design and layout

de/volunteer.wml      351) and some C++ development experience. Previous experience with Qt and
de/volunteer.wml      352) Qt's Designer will be very helpful, but are not required. Some
de/volunteer.wml      353) English writing ability will also be useful, since this project will
de/volunteer.wml      354) likely involve writing small amounts of help documentation that should
de/volunteer.wml      355) be understandable by non-technical users. Bonus points for some graphic
de/volunteer.wml      356) design/Photoshop fu, since we might want/need some shiny new icons too.
de/volunteer.wml      357) </li>
de/volunteer.wml      358) 
de/volunteer.wml      359) <li>
de/volunteer.wml      360) <b>Improvements on our active browser configuration tester</b> -
de/volunteer.wml      361) <a href="https://check.torproject.org/">https://check.torproject.org/</a>
de/volunteer.wml      362) <br />
de/volunteer.wml      363) We currently have a functional web page to detect if Tor is working. It
de/volunteer.wml      364) has a few places where it falls short. It requires improvements with
de/volunteer.wml      365) regard to default languages and functionality. It currently only responds
de/volunteer.wml      366) in English. In addition, it is a hack of a perl script that should have
de/volunteer.wml      367) never seen the light of day. It should probably be rewritten in python
de/volunteer.wml      368) with multi-lingual support in mind. It currently uses the <a
de/volunteer.wml      369) href="http://exitlist.torproject.org/">Tor DNS exit list</a>
de/volunteer.wml      370) and should continue to do so in the future. It currently result in certain
de/volunteer.wml      371) false positives and these should be discovered, documented, and fixed
de/volunteer.wml      372) where possible. Anyone working on this project should be interested in
de/volunteer.wml      373) DNS, basic perl or preferably python programming skills, and will have
de/volunteer.wml      374) to interact minimally with Tor to test their code.
de/volunteer.wml      375) <br />
de/volunteer.wml      376) If you want to make the project more exciting
de/volunteer.wml      377) and involve more design and coding, take a look at <a
de/volunteer.wml      378) href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
de/volunteer.wml      379) 131-verify-tor-usage.txt</a>.
de/volunteer.wml      380) </li>
de/volunteer.wml      381) 
de/volunteer.wml      382) <li>
de/volunteer.wml      383) <b>Improvements on our DNS Exit List service</b> -
de/volunteer.wml      384) <a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
de/volunteer.wml      385) <br />
de/volunteer.wml      386) The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
de/volunteer.wml      387) is written by our fabulous anonymous
de/volunteer.wml      388) contributer Tup. It's a DNS server written in Haskell that supports part of our <a

de/volunteer.wml      389) href="https://<svnsandbox>doc/contrib/torel-design.txt">exitlist

de/volunteer.wml      390) design document</a>. Currently, it is functional and it is used by
de/volunteer.wml      391) check.torproject.org and other users. The issues that are outstanding
de/volunteer.wml      392) are mostly aesthetic. This wonderful service could use a much better
de/volunteer.wml      393) website using the common Tor theme. It would be best served with better
de/volunteer.wml      394) documentation for common services that use an RBL. It could use more
de/volunteer.wml      395) publicity. A person working on this project should be interested in DNS,
de/volunteer.wml      396) basic RBL configuration for popular services, and writing documentation.
de/volunteer.wml      397) The person would require minimal Tor interaction &mdash; testing their
de/volunteer.wml      398) own documentation at the very least. Furthermore, it would be useful
de/volunteer.wml      399) if they were interested in Haskell and wanted to implement more of the
de/volunteer.wml      400) torel-design.txt suggestions.
de/volunteer.wml      401) </li>
de/volunteer.wml      402) 
de/volunteer.wml      403) <li>
de/volunteer.wml      404) <b>Testing integration of Tor with web browsers for our end users</b>
de/volunteer.wml      405) <br />
de/volunteer.wml      406) The Tor project currently lacks a solid test suite to ensure that a
de/volunteer.wml      407) user has a properly and safely configured web browser. It should test for as
de/volunteer.wml      408) many known issues as possible. It should attempt to decloak the
de/volunteer.wml      409) user in any way possible. Two current webpages that track these
de/volunteer.wml      410) kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
de/volunteer.wml      411) href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
de/volunteer.wml      412) with their proof of concept code, bug issues, etc</a>. HD Moore runs
de/volunteer.wml      413) the <a href="http://metasploit.com/research/projects/decloak/">metasploit

de/volunteer.wml      414) decloak website</a>. A person interested in defending Tor could start

de/volunteer.wml      415) by collecting as many workable and known methods for decloaking a
de/volunteer.wml      416) Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may

de/volunteer.wml      417) be helpful as a start.) One should be familiar with the common pitfalls but

de/volunteer.wml      418) possibly have new methods in mind for implementing decloaking issues. The
de/volunteer.wml      419) website should ensure that it tells a user what their problem is. It
de/volunteer.wml      420) should help them to fix the problem or direct them to the proper support

de/volunteer.wml      421) channels. The person should also be closely familiar with using Tor and how

de/volunteer.wml      422) to prevent Tor information leakage.
de/volunteer.wml      423) </li>
de/volunteer.wml      424) 
de/volunteer.wml      425) <li>
de/volunteer.wml      426) <b>Libevent and Tor integration improvements</b>
de/volunteer.wml      427) <br />
de/volunteer.wml      428) Tor should make better use of the more recent features of Niels
de/volunteer.wml      429) Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
de/volunteer.wml      430) library.  Tor already uses Libevent for its low-level asynchronous IO
de/volunteer.wml      431) calls, and could also use Libevent's increasingly good implementations
de/volunteer.wml      432) of network buffers and of HTTP.  This wouldn't be simply a matter of
de/volunteer.wml      433) replacing Tor's internal calls with calls to Libevent: instead, we'll
de/volunteer.wml      434) need to refactor Tor to use Libevent calls that do not follow the
de/volunteer.wml      435) same models as Tor's existing backends. Also, we'll need to add
de/volunteer.wml      436) missing functionality to Libevent as needed &mdash; most difficult likely
de/volunteer.wml      437) will be adding OpenSSL support on top of Libevent's buffer abstraction.
de/volunteer.wml      438) Also tricky will be adding rate-limiting to Libevent.
de/volunteer.wml      439) </li>
de/volunteer.wml      440) 
de/volunteer.wml      441) <li>
de/volunteer.wml      442) <b>Tuneup Tor!</b>
de/volunteer.wml      443) <br />
de/volunteer.wml      444) Right now, Tor relays measure and report their own bandwidth, and Tor
de/volunteer.wml      445) clients choose which relays to use in part based on that bandwidth.
de/volunteer.wml      446) This approach is vulnerable to
de/volunteer.wml      447) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
de/volunteer.wml      448) relays lie about their bandwidth</a>;
de/volunteer.wml      449) to address this, Tor currently caps the maximum bandwidth
de/volunteer.wml      450) it's willing to believe any relay provides.  This is a limited fix, and
de/volunteer.wml      451) a waste of bandwidth capacity to boot.  Instead,
de/volunteer.wml      452) Tor should possibly measure bandwidth in a more distributed way, perhaps
de/volunteer.wml      453) as described in the
de/volunteer.wml      454) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
de/volunteer.wml      455) Tor"</a> paper

de/volunteer.wml      456) by Snader and Borisov. One could use current testing code to

de/volunteer.wml      457) double-check this paper's findings and verify the extent to which they
de/volunteer.wml      458) dovetail with Tor as deployed in the wild, and determine good ways to
de/volunteer.wml      459) incorporate them into their suggestions Tor network without adding too
de/volunteer.wml      460) much communications overhead between relays and directory
de/volunteer.wml      461) authorities.
de/volunteer.wml      462) </li>
de/volunteer.wml      463) 
de/volunteer.wml      464) <!--
de/volunteer.wml      465) <li>
de/volunteer.wml      466) <b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
de/volunteer.wml      467) <br />
de/volunteer.wml      468) It would be useful to have automated build processes for Windows and
de/volunteer.wml      469) probably other platforms. The purpose of having a continuous integration
de/volunteer.wml      470) build environment is to ensure that Windows isn't left behind for any of
de/volunteer.wml      471) the software projects used in the Tor project or its accompanying.<br />
de/volunteer.wml      472) Buildbot may be a good choice for this as it appears to support all of
de/volunteer.wml      473) the platforms Tor does. See the
de/volunteer.wml      474) <a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
de/volunteer.wml      475) buildbot</a>.<br />
de/volunteer.wml      476) There may be better options and the person undertaking this task should
de/volunteer.wml      477) evaluate other options. Any person working on this automatic build
de/volunteer.wml      478) process should have experience or be willing to learn how to build all
de/volunteer.wml      479) of the respective Tor related code bases from scratch. Furthermore, the
de/volunteer.wml      480) person should have some experience building software in Windows
de/volunteer.wml      481) environments as this is the target audience we want to ensure we do not
de/volunteer.wml      482) leave behind. It would require close work with the Tor source code but
de/volunteer.wml      483) probably only in the form of building, not authoring.<br />
de/volunteer.wml      484) Additionally, we need to automate our performance testing for all platforms.
de/volunteer.wml      485) We've got buildbot (except on Windows &mdash; as noted above) to automate
de/volunteer.wml      486) our regular integration and compile testing already,
de/volunteer.wml      487) but we need to get our network simulation tests (as built in torflow)
de/volunteer.wml      488) updated for more recent versions of Tor, and designed to launch a test
de/volunteer.wml      489) network either on a single machine, or across several, so we can test
de/volunteer.wml      490) changes in performance on machines in different roles automatically.
de/volunteer.wml      491) </li>
de/volunteer.wml      492) -->
de/volunteer.wml      493) 
de/volunteer.wml      494) <li>
de/volunteer.wml      495) <b>Improve our unit testing process</b>
de/volunteer.wml      496) <br />
de/volunteer.wml      497) Tor needs to be far more tested. This is a multi-part effort. To start
de/volunteer.wml      498) with, our unit test coverage should rise substantially, especially in
de/volunteer.wml      499) the areas outside the utility functions. This will require significant
de/volunteer.wml      500) refactoring of some parts of Tor, in order to dissociate as much logic
de/volunteer.wml      501) as possible from globals.
de/volunteer.wml      502) <br />
de/volunteer.wml      503) Additionally, we need to automate our performance testing. We've got
de/volunteer.wml      504) buildbot to automate our regular integration and compile testing already
de/volunteer.wml      505) (though we need somebody to set it up on Windows),
de/volunteer.wml      506) but we need to get our network simulation tests (as built in TorFlow: see
de/volunteer.wml      507) the "Tor Node Scanner improvements" item)
de/volunteer.wml      508) updated for more recent versions of Tor, and designed to launch a test
de/volunteer.wml      509) network either on a single machine, or across several, so we can test
de/volunteer.wml      510) changes in performance on machines in different roles automatically.
de/volunteer.wml      511) </li>
de/volunteer.wml      512) 
de/volunteer.wml      513) <li>
de/volunteer.wml      514) <b>Help revive an independent Tor client implementation</b>
de/volunteer.wml      515) <br />
de/volunteer.wml      516) Reanimate one of the approaches to implement a Tor client in Java,
de/volunteer.wml      517) e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
de/volunteer.wml      518) project</a>, and make it run on <a
de/volunteer.wml      519) href="http://code.google.com/android/">Android</a>. The first step
de/volunteer.wml      520) would be to port the existing code and execute it in an Android
de/volunteer.wml      521) environment. Next, the code should be updated to support the newer Tor
de/volunteer.wml      522) protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
de/volunteer.wml      523) directory protocol</a>. Further, support for requesting or even
de/volunteer.wml      524) providing Tor hidden services would be neat, but not required.
de/volunteer.wml      525) <br />

de/volunteer.wml      526) A perspective developer should be able to understand and write new Java code, including

de/volunteer.wml      527) a Java cryptography API. Being able to read C code would be helpful,

de/volunteer.wml      528) too. One should be willing to read the existing documentation,

de/volunteer.wml      529) implement code based on it, and refine the documentation
de/volunteer.wml      530) when things are underdocumented. This project is mostly about coding and
de/volunteer.wml      531) to a small degree about design.
de/volunteer.wml      532) </li>
de/volunteer.wml      533) 
de/volunteer.wml      534) <li>
de/volunteer.wml      535) <b>Bring moniTor to life</b>
de/volunteer.wml      536) <br />
de/volunteer.wml      537) Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
de/volunteer.wml      538) management tool for Tor relays. The purpose of such a tool would be
de/volunteer.wml      539) to monitor a local Tor relay via its control port and include useful
de/volunteer.wml      540) system information of the underlying machine. When running this tool, it
de/volunteer.wml      541) would dynamically update its content like top does for Linux processes.
de/volunteer.wml      542) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
de/volunteer.wml      543) or-dev post</a> might be a good first read.
de/volunteer.wml      544) <br />

de/volunteer.wml      545) A person interested in this should be familiar

de/volunteer.wml      546) with or willing to learn about administering a Tor relay and configuring
de/volunteer.wml      547) it via its control port. As an initial prototype is written in Python,
de/volunteer.wml      548) some knowledge about writing Python code would be helpful, too. This
de/volunteer.wml      549) project is one part about identifying requirements to such a
de/volunteer.wml      550) tool and designing its interface, and one part lots of coding.
de/volunteer.wml      551) </li>
de/volunteer.wml      552) 
de/volunteer.wml      553) <li>
de/volunteer.wml      554) <b>Torbutton improvements</b>
de/volunteer.wml      555) <br />
de/volunteer.wml      556) Torbutton has a number of improvements that can be made in the post-1.2
de/volunteer.wml      557) timeframe. Most of these are documented as feature requests in the <a
de/volunteer.wml      558) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">Torbutton
de/volunteer.wml      559) flyspray section</a>. Good examples include: stripping off node.exit on http
de/volunteer.wml      560) headers, more fine-grained control over formfill blocking, improved referrer
de/volunteer.wml      561) spoofing based on the domain of the site (a-la <a
de/volunteer.wml      562) href="https://addons.mozilla.org/en-US/firefox/addon/953">refcontrol extension</a>),
de/volunteer.wml      563) tighter integration with Vidalia for reporting Tor status, a New Identity
de/volunteer.wml      564) button with Tor integration and multiple identity management, and anything
de/volunteer.wml      565) else you might think of.
de/volunteer.wml      566) <br />
de/volunteer.wml      567) This work would be independent coding in Javascript and the fun world of <a
de/volunteer.wml      568) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
de/volunteer.wml      569) with not too much involvement in the Tor internals.
de/volunteer.wml      570) </li>
de/volunteer.wml      571) 
de/volunteer.wml      572) <li>
de/volunteer.wml      573) <b>Porting Polipo to Windows</b>
de/volunteer.wml      574) <br />
de/volunteer.wml      575) Help port <a
de/volunteer.wml      576) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
de/volunteer.wml      577) Windows. Example topics to tackle include:
de/volunteer.wml      578) 1) handle spaces in path names and understand the filesystem
de/volunteer.wml      579) namespace &mdash; that is, where application data, personal data,
de/volunteer.wml      580) and program data typically reside in various versions of Windows. 2) the
de/volunteer.wml      581) ability to handle ipv6 communications. 3) the ability to asynchronously
de/volunteer.wml      582) query name servers, find the system nameservers, and manage netbios
de/volunteer.wml      583) and dns queries. 4) use native regex capabilities of Windows, rather
de/volunteer.wml      584) than using 3rd party GNU regex libraries. 5) manage events and buffers
de/volunteer.wml      585) natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
de/volunteer.wml      586) Windows it's whatever the config specifies). 6) some sort of GUI config
de/volunteer.wml      587) and reporting tool, bonus if it has a systray icon with right clickable
de/volunteer.wml      588) menu options. Double bonus if it's cross-platform compatible.
de/volunteer.wml      589) </li>
de/volunteer.wml      590) 
de/volunteer.wml      591) <li>
de/volunteer.wml      592) <b>Make our diagrams beautiful and automated</b>
de/volunteer.wml      593) <br />
de/volunteer.wml      594) We need a way to generate the website diagrams (for example, the "How
de/volunteer.wml      595) Tor Works" pictures on the <a href="<page overview>">overview page</a>
de/volunteer.wml      596) from source, so we can translate them as UTF-8 text rather than edit
de/volunteer.wml      597) them by hand with Gimp. We might want to
de/volunteer.wml      598) integrate this as an wml file so translations are easy and images are

de/volunteer.wml      599) generated in multiple languages whenever we build the website. 

de/volunteer.wml      600) </li>
de/volunteer.wml      601) 
de/volunteer.wml      602) <li>
de/volunteer.wml      603) <b>Improve the LiveCD offerings for the Tor community</b>
de/volunteer.wml      604) <br />
de/volunteer.wml      605) How can we make the <a
de/volunteer.wml      606) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
de/volunteer.wml      607) easier to maintain, improve, and document?
de/volunteer.wml      608) </li>
de/volunteer.wml      609) 
de/volunteer.wml      610) <li>
de/volunteer.wml      611) <b>Rework and extend Blossom</b>
de/volunteer.wml      612) <br />
de/volunteer.wml      613) Rework and extend Blossom (a tool for monitoring and
de/volunteer.wml      614) selecting appropriate Tor circuits based upon exit node requirements
de/volunteer.wml      615) specified by the user) to gather data in a self-contained way, with
de/volunteer.wml      616) parameters easily configurable by the user.  Blossom is presently
de/volunteer.wml      617) implemented as a single Python script that interfaces with Tor using the
de/volunteer.wml      618) Controller interface and depends upon metadata about Tor nodes obtained
de/volunteer.wml      619) via external processes, such as a webpage indicating status of the nodes
de/volunteer.wml      620) plus publically available data from DNS, whois, etc.  This project has
de/volunteer.wml      621) two parts: (1) Determine which additional metadata may be useful and
de/volunteer.wml      622) rework Blossom so that it cleanly obtains the metadata on its own rather
de/volunteer.wml      623) than depend upon external scripts (this may, for example, involve
de/volunteer.wml      624) additional threads or inter-process communication), and (2) develop a
de/volunteer.wml      625) means by which the user can easily configure Blossom, starting with a
de/volunteer.wml      626) configuration file and possibly working up to a web configuration engine.
de/volunteer.wml      627) Knowledge of Tor and Python are important; knowledge of
de/volunteer.wml      628) TCP, interprocess communication, and Perl will also be helpful.  An
de/volunteer.wml      629) interest in network neutrality is important as well, since the
de/volunteer.wml      630) principles of evaluating and understanding internet inconsistency are at
de/volunteer.wml      631) the core of the Blossom effort.
de/volunteer.wml      632) </li>
de/volunteer.wml      633) 
de/volunteer.wml      634) <li>
de/volunteer.wml      635) <b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
de/volunteer.wml      636) <br />
de/volunteer.wml      637) Develop and implement a means of affording Blossom
de/volunteer.wml      638) users the ability to qualitatively describe the exit node that they
de/volunteer.wml      639) want.  The Internet is an inconsistent place: some Tor exit nodes see
de/volunteer.wml      640) the world differently than others.  As presently implemented, Blossom (a
de/volunteer.wml      641) tool for monitoring and selecting appropriate Tor circuits based upon
de/volunteer.wml      642) exit node requirements specified by the user) lacks a sufficiently rich
de/volunteer.wml      643) language to describe how the different vantage points are different.
de/volunteer.wml      644) For example, some exit nodes may have an upstream network that filters
de/volunteer.wml      645) certain kinds of traffic or certain websites.  Other exit nodes may
de/volunteer.wml      646) provide access to special content as a result of their location, perhaps
de/volunteer.wml      647) as a result of discrimination on the part of the content providers
de/volunteer.wml      648) themselves.  This project has two parts: (1) develop a language for
de/volunteer.wml      649) describing characteristics of networks in which exit nodes reside, and
de/volunteer.wml      650) (2) incorporate this language into Blossom so that users can select Tor
de/volunteer.wml      651) paths based upon the description.
de/volunteer.wml      652) Knowledge of Tor and Python are important; knowledge of
de/volunteer.wml      653) TCP, interprocess communication, and Perl will also be helpful.  An
de/volunteer.wml      654) interest in network neutrality is important as well, since the
de/volunteer.wml      655) principles of evaluating and understanding internet inconsistency are at
de/volunteer.wml      656) the core of the Blossom effort.
de/volunteer.wml      657) </li>
de/volunteer.wml      658) 
de/volunteer.wml      659) <li>
de/volunteer.wml      660) <b>Bring up new ideas!</b>
de/volunteer.wml      661) <br />
de/volunteer.wml      662) Don't like any of these? Look at the <a

de/volunteer.wml      663) href="<svnsandbox>doc/roadmap/2008-12-19-roadmap-full.pdf">Tor development

de/volunteer.wml      664) roadmap</a> for more ideas.
de/volunteer.wml      665) </li>
de/volunteer.wml      666) 
de/volunteer.wml      667) </ol>
de/volunteer.wml      668) 

de/volunteer.wml      669) <a id="OtherCoding"></a>
de/volunteer.wml      670) 

de/volunteer.wml      671) <h2><a class="anchor" href="#Coding">Andere Ideen zu Programmierung und Design</a></h2>

de/volunteer.de.html  672) 
de/volunteer.de.html  673) <ol>

de/volunteer.wml      674)   <li>Torserver funktionieren unter Windows XP nicht sehr gut. Wir

de/volunteer.wml      675)   verwenden auf Windows den standardmäßigen <code>select</code>-Systemaufruf.
de/volunteer.wml      676)   Dies bereitet gerade auf mittelgroßen Servern <a

de/volunteer.wml      677)   href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">Probleme</a>.

de/volunteer.wml      678)   Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine Lösung
de/volunteer.wml      679)   wäre, <a href="http://www.monkey.org/~provos/libevent/">libevent</a>
de/volunteer.wml      680)   beizubringen, Overlapped I/O statt <code>select()</code> zu wählen. Tor muss

de/volunteer.wml      681)   dann an die neue libevent-Schnittstelle angepasst werden. Christian
de/volunteer.wml      682)   King hat
de/volunteer.wml      683)   <a href="https://svn.torproject.org/svn/libevent-urz/trunk/">einen guten

de/volunteer.wml      684)   Anfang</a> gemacht.</li>

de/volunteer.wml      685)   <li>Wie können wir die <a

de/volunteer.wml      686)   href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> leichter
de/volunteer.wml      687)   zu warten, verbessern und zu dokumentieren machen?</li>

de/volunteer.wml      688)   <li>Wir sollten damit anfangen unser <a href="<page

de/volunteer.wml      689)   documentation>#DesignDoc">gegen Blockierungen geschütztes Design</a> zu

de/volunteer.wml      690)   implementieren. Dies beinhaltet die Ausarbeitung des Designs, die
de/volunteer.wml      691)   Modifizierung diverser Teile von Tor, die Arbeit an einer <a
de/volunteer.wml      692)   href="http://vidalia-project.net/">GUI</a>, die intuitiv ist und die Planung

de/volunteer.wml      693)   für den Einsatz.</li>
de/volunteer.wml      694)   <li>Wir brauchen ein flexibles Gerüst, um Ende-zu-Ende Attacken des

de/volunteer.wml      695)   Netzverkehrs zu simulieren. Viele Forscher haben Simulatoren geschaffen, die

de/volunteer.wml      696)   ihre Intuition, ob ein Angriff oder Verteidigung funktioniert, unterstützt.
de/volunteer.wml      697)   Können wir einen Simulator bauen, der offen und gut dokumentiert ist? Dies

de/volunteer.wml      698)   wird eine Menge neuer Forschung anregen. Schaue auch auf den <a

de/volunteer.wml      699)   href="#Research">Eintrag unten</a>, um Details zu dieser Aufgabe zu entdecken.

de/volunteer.wml      700)   Wenn es fertig ist, könntest du helfen, eine Veröffentlichung  dazu zu schreiben.</li>

de/volunteer.wml      701)   <li>Momentan werden die Deskriptoren der versteckten Services nur
de/volunteer.wml      702)   auf einigen wenigen Verzeichnisservern gespeichert. Dies ist

de/volunteer.wml      703)   schlecht für die Privatsphäre und die Robustheit. Um mehr Robustheit

de/volunteer.wml      704)   zu erlangen, sollten wir die privaten Daten aus den Deskriptoren

de/volunteer.wml      705)   entfernen, um diese auf verschiedenen Plätzen spiegeln zu
de/volunteer.wml      706)   können. Idealerweise hätten wir gern ein Speicher-/Backupsystem, das

de/volunteer.wml      707)   verschieden zu den Verzeichnisservern ist. Das erste Problem ist,

de/volunteer.wml      708)   das wir Format für die versteckten Services schaffen müssen, welches
de/volunteer.wml      709)   a) ASCII statt binär ist, b) die Liste der Introductionpoints
de/volunteer.wml      710)   verschlüsselt, solange man nicht die <tt>.onion</tt>-Adresse kennt

de/volunteer.wml      711)   und c) den Verzeichnissen erlaubt, den Zeitstempel und die Signatur
de/volunteer.wml      712)   eines Deskriptors zu verifizieren, so dass diese nicht mit falschen

de/volunteer.wml      713)   überrumpelt werden. Zweitens wird es jedes verteilte Speichersystem

de/volunteer.wml      714)   tun, solange es authentifizierte Updates erlaubt.</li>

de/volunteer.wml      715)   <li>Torversionen ab 0.1.1.x unterstützen Cryptohardwarebeschleuniger
de/volunteer.wml      716)     via OpenSSL. Bisher hat das niemand getestet. Möchte jemand gern

de/volunteer.de.html  717)     eine Karte haben und schauen, ob das funktioniert?</li>
de/volunteer.de.html  718)   <li>Eine Sicherheitsanalyse mit
de/volunteer.de.html  719)     "<a href="http://en.wikipedia.org/wiki/Fuzz_testing">Fuzz</a>"

de/volunteer.wml      720)     machen.  Herausfinden, ob es da draußen gute Bibliotheken dafür

de/volunteer.de.html  721)     gibt. Gewinne Ruhm und Ehre, wenn wir nur wegen dir ein neues
de/volunteer.de.html  722)     Release herausbringen!</li>

de/volunteer.wml      723)   <li>Tor nutzt TCP für den Transport und TLS für die Verschlüsselung

de/volunteer.de.html  724)     der Verbindungen. Dies ist einfach. Es bedeutet aber auch, dass

de/volunteer.wml      725)     alle Zellen Verspätungen erfahren, wenn nur ein Paket verworfen
de/volunteer.wml      726)     wird. Daher können wir nur bedingt TCP-Streams unterstützen. Es

de/volunteer.de.html  727)     gibt eine <a

de/volunteer.wml      728)     href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">Liste

de/volunteer.wml      729)     von Gründen</a>, warum wir nicht zu Transport per UDP gewechselt
de/volunteer.wml      730)     sind. Es wäre schön, wenn diese Liste kürzer werden würde. Wir

de/volunteer.wml      731)   haben auch eine <a

de/volunteer.wml      732)   href="<svnsandbox>doc/100-tor-spec-udp.txt">Spezifikation für Tor

de/volunteer.wml      733)   und UDP</a> &mdash; bitte lass uns wissen, wenn damit etwas nicht
de/volunteer.wml      734)   stimmt.</li>

de/volunteer.wml      735)   <li>Wir sind nicht weit davon entfernt, Unterstützung für IPv6 bei
de/volunteer.wml      736)     Exitknoten zu haben. Falls du dich stark um IPv6 kümmerst, ist

de/volunteer.de.html  737)     das wahrscheinlich der Platz, um zu starten.</li>

de/volunteer.wml      738)   <li>Du magst keinen von den obigen Punkten? Schaue dir die <a

de/volunteer.wml      739)   href="<svnsandbox>doc/design-paper/roadmap-future.pdf">weiteren Pläne</a> für

de/volunteer.wml      740)   weitere Ideen an.</li>

de/volunteer.de.html  741) </ol>

de/contribute.de.html 742) 

de/volunteer.wml      743) <a id="Research"></a>
de/volunteer.wml      744) <h2><a class="anchor" href="#Research">Forschung</a></h2>

de/volunteer.de.html  745) 

de/volunteer.de.html  746) <ol>
de/volunteer.de.html  747)   <li>Die Fingerprintattacken gegen Webseiten machen eine Liste von

de/volunteer.wml      748)     einigen wenigen populären Webseiten, laden die Inhalte herunter
de/volunteer.wml      749)     und machen einen Satz von Signaturen für jede Seite. Danach
de/volunteer.wml      750)     beobachten sie den Verkehr des Torclients. Währenddessen gelangen sie

de/volunteer.de.html  751)     schnell zu einer Vermutung, welche Seite gerade besucht wird. Wie

de/volunteer.wml      752)     effektiv ist dieser Angriff bezüglich der aktuellen Codebasis von
de/volunteer.wml      753)     Tor? Beginne danach Verteidigungsmöglichkeiten auszuloten. Wir
de/volunteer.wml      754)     könnten beispielsweise die Zellgröße von 512 Bytes auf 1024 Bytes

de/volunteer.de.html  755)     anheben und Techniken wie <a
de/volunteer.de.html  756)     href="http://freehaven.net/anonbib/#timing-fc2004">defensives

de/volunteer.wml      757)     Verwerfen</a> anwenden. Wir könnten auch künstliche Verspätungen
de/volunteer.wml      758)     einarbeiten. Welchen Einfluss haben diese Massnahmen und wie groß

de/volunteer.de.html  759)     ist der Einfluss auf die Benutzbarkeit?</li>

de/volunteer.wml      760)   <li>Eine weitere Angriffsmöglichkeit (end-to-end traffic

de/volunteer.wml      761)     confirmation attack) basiert darauf, dass der Verkehr zwischen

de/volunteer.de.html  762)     Alice und Bob beobachtet wird. Durch den <a
de/volunteer.de.html  763)     href="http://freehaven.net/anonbib/#danezis:pet2004">Vergleich
de/volunteer.de.html  764)     der Signaturen des Netzverkehrs kann man herausfinden, on man
de/volunteer.de.html  765)     denselben Stream verfolgt</a>. Bis jetzt akzeptiert Tor dies als

de/volunteer.wml      766)     Fakt und nimmt an, dass dies in allen Fällen trivial ist. Ist das

de/volunteer.de.html  767)     wahr? Wieviel Verkehr von welcher Sorte braucht man, um sicher zu
de/volunteer.de.html  768)     sicher, dass es funktioniert? Gibt es Szenarien, die die Attacke
de/volunteer.de.html  769)     ausbremsen? Funktioniert Padding besser als anderes?</li>

de/volunteer.wml      770)     <li>Eine verwandte Frage: Bringt der Betrieb eines Relays oder

de/volunteer.wml      771)   eines Brückenservers zusätzlichen Schutz gegen Timingangriffe? Kann
de/volunteer.wml      772)   ein externer Angreifer individuelle Ströme erkennen, obwohl er nicht
de/volunteer.wml      773)   in die TLS-Ströme sehen kann? Hat die Höhe des durchgeleiteten
de/volunteer.wml      774)   Verkehrs Einfluss? Was wäre, wenn der Client anderen Verkehr

de/volunteer.wml      775)   verlangsamt, um es so aussehen zu lassen, dass er auch

de/volunteer.wml      776)   weitergeleitet wird? Die selbe Queue könnte auch zur Maskierung der

de/volunteer.wml      777)   Timings mit Techniken von <a
de/volunteer.wml      778)   href="http://www.freehaven.net/anonbib/#ShWa-Timing06" >adaptivem

de/volunteer.wml      779)   Padding</a> genutzt werden, aber ohne zusätzlich Traffic zu
de/volunteer.wml      780)   erzeugen. Würde das das Timing für externe Angreifer verschleiern?
de/volunteer.wml      781)   Müssten die Strategien für assymetrische Knoten angepasst werden?
de/volunteer.wml      782)   Wäre es dort beispielsweise möglich, den Clienttraffic von anderem
de/volunteer.wml      783)   zu unterscheiden? Oder ist das vielleicht für symmetrische

de/volunteer.wml      784)   Verbindungen leichter?</li>
de/volunteer.wml      785)   <li>Wiederhole die <a
de/volunteer.wml      786)   href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta"
de/volunteer.wml      787)   >Angriffe von Murdoch und Danezis von der Oakland 05</a> im
de/volunteer.wml      788)   aktuellen Tor-Netzwerk. Schaue, ob du herausfinden kannst, warum das
de/volunteer.wml      789)   bei einigen gut und bei anderen schlecht funktioniert. (Meine

de/volunteer.wml      790)   Theorie ist, dass schnelle Knoten mit Restkapazität dem Angriff

de/volunteer.wml      791)   besser widerstehen.) Wenn das wahr ist, experimentiere mit
de/volunteer.wml      792)   <var>RelayBandwidthRate</var> und
de/volunteer.wml      793)   <var>RelayBandwidthBurst</var>. Dabei betreibst du ein Relay,
de/volunteer.wml      794)   welches als Client genutzt wird, um den Verkehr des Angreifers

de/volunteer.wml      795)   weiterzuleiten. Was ist das richtige Verhältnis von
de/volunteer.wml      796)   <var>RelayBandwidthRate</var> zu aktueller Kapazität? Gibt es
de/volunteer.wml      797)   überhaupt ein Verhältnis? Wenn wir dabei sind, erhöht eine große

de/volunteer.wml      798)   Zahl von Relays die Fehlerrate des Angriffs? (Das Tor-Netzwerk ist

de/volunteer.wml      799)   nun fast zwei Größenordnungen gewachsen, seit die Veröffentlichung

de/volunteer.wml      800)   geschrieben wurde.) Lies auf jeden Fall auch <a
de/volunteer.wml      801)   href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the
de/volunteer.wml      802)   Queue</a>.</li>

de/volunteer.de.html  803)   <li>Die Attacke auf die Routingzonen ist der Netzpfad zwischen
de/volunteer.de.html  804)     Alice und dem Eingangsknoten (bzw. zwischen dem Exitknoten und
de/volunteer.de.html  805)     Bob). In der Literatur wird dies als einfache Verbindung auf
de/volunteer.de.html  806)     einem Graph dargestellt. In der Praxis durchquert der Pfad viele

de/volunteer.wml      807)     autonome Systeme. Es ist nicht ungewöhnlich, dass dasselbe

de/volunteer.de.html  808)     <a href="http://freehaven.net/anonbib/#feamster:wpes2004">autonome
de/volunteer.de.html  809)     System sowohl beim Eingangs- wie auch beim Ausgangspfad
de/volunteer.de.html  810)     erscheint</a>. Um nun herauszufinden, ob ein spezielles Alice-,

de/volunteer.wml      811)     Eingangs-, Ausgangs-, Bobviereck gefährlich ist, müssten wir die

de/volunteer.wml      812)     gesamte Routingzone des Internet herunterladen und Operationen

de/volunteer.wml      813)     darauf ausführen. Gibt es praktische Abschätzungen, die die
de/volunteer.wml      814)     Arbeit erleichtern können?</li>

de/volunteer.wml      815)     <li>Andere Fragen in der Forschung, die die geografische
de/volunteer.wml      816)     Verteilung betreffen, betrachten einen Kompromiss zwischen der Wahl

de/volunteer.wml      817)     einer effizienten Route und einer zufälligen Route. Wirf einen Blick

de/volunteer.wml      818)     auf das <a
de/volunteer.wml      819)     href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">Positionspapier</a>
de/volunteer.wml      820)     von Stephen Rollyson. Es diskutiert, wie man langsame Leitungen

de/volunteer.wml      821)     auschalten kann, ohne die Anonymität zu stark einzuschränken. Die
de/volunteer.wml      822)     Begründungen machen einen guten Eindruck, brauchen aber noch mehr

de/volunteer.wml      823)     Arbeit.</li>

de/volunteer.de.html  824)   <li>Tor funktioniert nicht sehr gut, wenn Server eine asymmetrische
de/volunteer.de.html  825)     Bandbreite (Kabel oder DSL) haben. Tor hat separate
de/volunteer.de.html  826)     TCP-Verbindungen zwischen jedem Hop. Wenn nun die einkommenden
de/volunteer.de.html  827)     Pakete gut ankommen und die ausgehenden alle verworfen werden,

de/volunteer.wml      828)     übertragen die die TCP-Pushback-Mechanismen diese Informationen

de/volunteer.de.html  829)     nicht gut hin zu den eingehenden Verbindungen. Eventuell sollte
de/volunteer.de.html  830)     Tor feststellen, wenn eine Menge an ausgehenden Verbindungen
de/volunteer.de.html  831)     verworfen werden und dann die eigehenden Verbindungen selbst

de/volunteer.wml      832)     herunterregeln? Ich könnte mir ein Schema vorstellen, wo wir ein
de/volunteer.wml      833)     konservatives Ratelimit suchen und das langsam vergrößern, bis

de/volunteer.de.html  834)     Pakete verworfen werden. Wir brauchen jemanden, der sich gut mit

de/volunteer.wml      835)     Netzwerken auskennt, um dies zu simulieren und eine Lösung zu
de/volunteer.wml      836)     finden. Wir müssen die Erosion in der Performance verstehen und
de/volunteer.wml      837)     das als Motivation für Transport per UDP verstehen.</li>
de/volunteer.wml      838)   <li>Ein verwandtes Thema ist die Kontrolle bei Netzüberlastung. Ist

de/volunteer.de.html  839)     unser Design ausreichend, um hohe Netzlast auszuhalten?

de/volunteer.wml      840)     Vielleicht sollten wir mit Fenstern von variabler Größe

de/volunteer.de.html  841)     experimentieren? Das schien im <a
de/volunteer.de.html  842)     href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">Experiment

de/volunteer.wml      843)     mit dem SSH-Durchsatz</a> gut zu funktionieren. Wir müssen das
de/volunteer.wml      844)     messen und verbessern und bei guten Resultaten Tor überholen.</li>
de/volunteer.wml      845)   <li>Unsere Ziele zum Schutz vor Zensur schließen ein, dass ein

de/volunteer.wml      846)     Angreifer Tor-Verkehr von <a

de/volunteer.wml      847)     href="<svnsandbox>doc/design-paper/blocking.html#sec:network-fingerprint">normalem

de/volunteer.wml      848)     SSL-Verkehr unterscheiden</a> kann. Offensichtlich können wir keine

de/volunteer.wml      849)     perfekte Steganographie erreichen und dabei benutzbar bleiben. Aber

de/volunteer.wml      850)     wir möchten gern Angriffen, die nur wenige Pakete betrachten,
de/volunteer.wml      851)     überwinden. Eine der verbliebenen Angriffe, die wir nicht sehr geprüft
de/volunteer.wml      852)     haben, ist das Verhältnis von der Größe der Tor-Zellen (512 Byte)

de/volunteer.wml      853)     zum restlichen Verkehr. Wieviel erkennt man davon, haben die

de/volunteer.wml      854)     Leerungsmechanismen der Buffer einen Einfluss, könnte Padding helfen?</li>

de/volunteer.wml      855)   <li>Tor-Verbindungen werden schrittweise aufgebaut, ein Knoten nach

de/volunteer.wml      856)     dem anderen.  Also haben wir theoretisch die Möglichkeit, manche
de/volunteer.wml      857)     Ströme schon nach dem zweiten Knoten die Tor-Wolke verlassen zu

de/volunteer.wml      858)     lassen, andere nach dem dritten Knoten, und so weiter.  Dies erscheint

de/volunteer.wml      859)     nett, weil es die Menge der austretenden Ströme, welcher ein bestimmter

de/volunteer.wml      860)     Server sieht, begrenzt.  Wenn wir diesen Strom jedoch sicher haben wollen,

de/volunteer.wml      861)     dann, laut unserer aktuellen Logik,  sollte der kürzeste Pfad mindestens 3
de/volunteer.wml      862)     Knoten lang sein.  Das heisst, die anderen Ströme wären noch länger.  Wir
de/volunteer.wml      863)     müssen diese Performance/Sicherheitsabwägung untersuchen.</li>

de/volunteer.wml      864)    <li>Es ist nicht schwer, DoS Angriffe auf Tor-Server oder

de/volunteer.wml      865)     Tor-Verzeischnisserver erfolgreich durchzuführen.  Sind Client-Puzzles die

de/volunteer.wml      866)     richtige Anwort?  Welche anderen praktischen Herangehensweisen gibt es?

de/volunteer.wml      867)     Bonuspunkte, wenn diese mit dem aktuellen Tor-Protokoll abwärtskompatibel

de/volunteer.wml      868)     sind.</li>

de/volunteer.wml      869)   <li>Programme, wie <a

de/volunteer.wml      870)     href="<page torbutton/index>">Torbutton</a>,

de/volunteer.wml      871)     versuchen den User-Agent des Browsers zu verstecken, indem sie

de/volunteer.wml      872)     diesen durch eine gewöhnliche Angabe ersetzen. Dadurch kann ein

de/volunteer.wml      873)     Angreifer Tor-Nutzer nicht durch einen Blick auf die

de/volunteer.wml      874)     Nachrichtenköpfe erkennen. Die Software versucht einen, allgemein

de/volunteer.wml      875)     genutzten Wert zu nehmen. Frage 1: Wie sehr schaden wir uns, wenn
de/volunteer.wml      876)     wir die Firefox-Version periodisch anpassen? Wenn wir zu oft
de/volunteer.wml      877)     updaten, kann man es unterscheiden. Machen wir es nicht, findet man
de/volunteer.wml      878)     Tor-Nutzer heraus, da sie sehr alte Versionen nutzen. Die Antwort

de/volunteer.wml      879)     hängt wahrscheinlich von den Firefox-Versionen, die es gibt,

de/volunteer.wml      880)     ab. Frage 2: Die Leute fragen immer wieder, zwischen n verschiedenen
de/volunteer.wml      881)     User-Agents zu wechseln. Hilft der Ansatz oder macht das keinen
de/volunteer.wml      882)     Unterschied? Betrachte dabei Cookies und Tor-Nutzer, die periodisch

de/volunteer.wml      883)     den User-Agent wechseln. Bösartige Webseiten greifen nur bestimmte

de/volunteer.wml      884)     Browser an. Wie beeinflussen die Antworten auf diese Fragen diese
de/volunteer.wml      885)     Antwort.</li>
de/volunteer.wml      886)   <li>Momentan benutzen Tor-Clients eine aufgebaute Verbindungsstrecke

de/volunteer.wml      887)     für zehn Minuten, nachdem diese aufgebaut wurde. Das Ziel hierfür

de/volunteer.wml      888)     ist, das Netzwerk nicht mit Nachrichten zum Verbindungsaufbau zu

de/volunteer.wml      889)     überlasten. Außerdem kann der Austrittsknoten dadurch kein Profil
de/volunteer.wml      890)     über den Nutzer bilden. Es hat sich herausgestellt, dass zehn

de/volunteer.wml      891)     Minuten zu lang sind. Insbesondere dann, wenn Verbindungen von
de/volunteer.wml      892)     verschiedenen Protokollen (IM und HTTP) benutzt werden. Wenn wir
de/volunteer.wml      893)     die Gesamtzahl an Erweiterungen der Verbindungsstrecke beibehalten,
de/volunteer.wml      894)     gibt es effizientere/sichere Wege, Streams zu den

de/volunteer.wml      895)     Verbindungsstrecken zu alloziieren oder präemptiv Strecken
de/volunteer.wml      896)     aufzubauen? Natürlich muss dieser Punkt damit beginnen, dass

de/volunteer.wml      897)     erforscht wird, welche Verbindungen die Programme typischerweise
de/volunteer.wml      898)     benutzen. Damit hast du dann einen realistischen Ansatz, den du
de/volunteer.wml      899)     optimierst.</li>

de/volunteer.wml      900)   <li>Wie viele Brückenserver benötigt man, um die Verfügbarkeit zu
de/volunteer.wml      901)     garantieren? Wir sollten die Abwanderung unseren Brückenservern messen.
de/volunteer.wml      902)     Wenn es viel davon gibt, gibt es Möglichkeiten, dass die Nutzer
de/volunteer.wml      903)     länger verbunden bleiben?</li>

de/volunteer.de.html  904)   </ol>

de/contribute.de.html 905) 

de/volunteer.wml      906) <p><a href="<page contact>">Lass uns wissen</a>, wenn du bei einem
de/volunteer.wml      907)   dieser Punkte Fortschritte gemacht hast.</p>

de/contribute.de.html 908) 
de/contribute.de.html 909) </div><!-- #main -->