tor-webwml.git

de/volunteer.wml         1) ## translation metadata

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

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="Mithelfen" 

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>Drei Sachen, die jeder tun kann</h2>

de/contribute.de.html   12) 

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

de/volunteer.de.html    14)   <li>Bitte �berlege dir,

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

de/volunteer.de.html    16)     betreiben</a>, damit das Netzwerk weiter w�chst.</li>
de/volunteer.de.html    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.de.html    20)     erz�hlen.</li>

de/volunteer.wml        21)   <li>Wir suchen nach Sponsoren und Geldgebern. Wenn du die Ziele von Tor magst
de/volunteer.wml        22)     und es n�tzlich findest, <a href="<page donate>">nimm dir einen Moment Zeit
de/volunteer.wml        23)     und spende, um die weitere Entwicklung zu unterst�tzen</a>. Wenn du Firmen,

de/volunteer.wml        24)     <abbr title="Non-Governmental Organisations">NGO</abbr>s oder andere

de/volunteer.wml        25)     Organisationen, die Sicherheit in ihrer Kommunikation ben�tigen, kennst,
de/volunteer.wml        26)     lasse sie �ber uns wissen.</li>
de/volunteer.wml        27)   </ol>
de/volunteer.wml        28) 

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

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

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

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

de/volunteer.wml        34)   nicht an einen lokalen Beobachter dringen, w�hrend wir versuchen, anonym zu
de/volunteer.wml        35)   bleiben. (Dies passiert, weil die Anwendung selbst DNS-Anfragen
de/volunteer.wml        36)   stellt, anstatt diese �ber Tor zu leiten.).
de/volunteer.wml        37)   <ul>
de/volunteer.wml        38)     <li>Wir m�ssen <a

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

de/volunteer.wml        40)     unsere Patches f�r tsocks</a> einspielen und einen Fork

de/volunteer.wml        41)     betreuen. Wir w�rden diesen auch auf unserem Server mit anbieten, wenn
de/volunteer.wml        42)     du m�chtest.</li>

de/volunteer.wml        43)     <li>Wir sollten das Programm dsocks von Dug Song patchen, so dass es
de/volunteer.wml        44)     das Kommando <code>mapaddress</code> von der Controllerschnittstelle
de/volunteer.wml        45)     nutzt. Somit verschwenden wir nicht einen gesamten Round-trip
de/volunteer.wml        46)     innerhalb von Tor, um die Aufl�sung vor der Verbindung zu
de/volunteer.wml        47)     machen.</li>
de/volunteer.wml        48)     <li>Wir m�ssen unser <kbd>torify</kbd>-Skript so umgestalten, dass
de/volunteer.wml        49)     es erkennt, welches tsocks oder dsocks installiert ist und dieses
de/volunteer.wml        50)     dann richtig aufruft. Das bedeutet wahrscheinlich, dass deren

de/volunteer.wml        51)     Schnittstellen vereinheitlicht werden m�ssen und f�hrt wahrscheinlich

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

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

de/volunteer.wml        56)     dass sie <var>BandwidthRate</var> in Abh�ngigkeit von der Uhrzeit setzen
de/volunteer.wml        57)     wollen. Anstatt das

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

de/volunteer.wml        59)     Skript haben, das �ber die <a href="<page gui/index>">Torschnittstelle</a>

de/volunteer.wml        60)     spricht und ein <code>setconf</code> macht, um die �nderungen

de/volunteer.de.html    61)     herbeizuf�hren. Nat�rlich w�rde es durch Cron ausgef�hrt oder es
de/volunteer.de.html    62)     schl�ft eine bestimmte Zeit und macht dann die �nderungen. Kann
de/volunteer.de.html    63)     das jemand f�r uns schreiben und wir packen das dann

de/volunteer.wml        64)     nach <a href="<svnsandbox>contrib/">contrib</a>? Das w�re

de/volunteer.wml        65)   eine gute M�glichkeit f�r den <a href="<page gui/index>">Tor GUI
de/volunteer.wml        66)   Wettbewerb</a>.</li>

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

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

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

de/volunteer.wml        71)     brauchen den Namen eines speziellen Torservers. Es w�re sch�n,

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

de/volunteer.wml        73)     Server ausgew�hlt. Der beste Weg ist wahrscheinlich, Blossoms
de/volunteer.wml        74)   Verzeichnis herunterzuladen und einen lokalen Blossomclient laufen

de/volunteer.wml        75)   zu lassen, der die Verzeichnisse sicher l�dt, die

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

de/volunteer.de.html    78)   <li>Wenn wir gerade bei Geolocation sind, w�re es sch�n, wenn
de/volunteer.de.html    79)     jemand eine Karte anfertigt, die die Standorte der Torserver
de/volunteer.de.html    80)     anzeigt. Bonuspunkte gibt es, wenn es sich bei �nderungen am

de/volunteer.wml        81)     Netzwerk auf den neuesten Stand bringt. Der leichteste Weg, um
de/volunteer.wml        82)   dies zu erreichen, w�re alle Daten zu Google zu schicken und diese
de/volunteer.wml        83)   machen dann die Karte f�r uns. Wie sehr beeinflusst dies die
de/volunteer.wml        84)   Privatsph�re und haben wir noch andere gute Optionen?</li>

de/volunteer.de.html    85)   <li>Tor bietet anonyme Verbindungen. Wenn du jedoch verschiedene
de/volunteer.de.html    86)     Pseudonyme haben m�chtest (z.B. rufst du des�fteren zwei Webseiten
de/volunteer.de.html    87)     auf und wenn das jemand wei�, kann er auf dich schliessen.),
de/volunteer.de.html    88)     unterst�tzen wir das nicht sehr gut.  Wir sollten einen guten
de/volunteer.de.html    89)     Ansatz und eine Schnittstelle zur Handhabung von pseudonymen
de/volunteer.de.html    90)     Profilen finden. Schaue dir
de/volunteer.de.html    91)     den <a
de/volunteer.de.html    92)     href="http://archives.seul.org/or/talk/Dec-2004/msg00086.html">Beitrag
de/volunteer.de.html    93)     </a> und den <a
de/volunteer.de.html    94)     href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html">Followup</a>
de/volunteer.de.html    95)     f�r mehr Details an.</li>
de/volunteer.de.html    96) </ol>
de/volunteer.de.html    97) 

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

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

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

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

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

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

de/volunteer.wml       106)     von Programmen, die durch Tor geroutet werden k�nnen</a>.</li>

de/volunteer.de.html   107)   <li>Wir brauchen bessere Dokumentation f�r Programme, die dynamisch
de/volunteer.de.html   108)     in Verbindungen eingreifen und diese durch Tor schicken. F�r Linux

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

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

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

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

de/volunteer.wml       114)     die Ergebnisse.</li>
de/volunteer.wml       115)   <li>Hilf, die Webseite und die Dokumentation in andere Sprachen zu
de/volunteer.wml       116)   �bersetzen. Schaue dir die <a href="<page translation>">Richtlinien
de/volunteer.wml       117)   zur �bersetzung</a> an, wenn du gern helfen m�chtest. Wir brauchen

de/volunteer.wml       118)   auch Leute, um die Seiten in Arabisch oder Farsi zu �bersetzen. Einen
de/volunteer.wml       119)   �berblick gibt

de/volunteer.wml       120)   es bei der <a href="<page translation-status>">Statusseite der
de/volunteer.wml       121)   �bersetzungen</a>.</li>

de/volunteer.de.html   122)   </ol>
de/volunteer.de.html   123) 

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

de/volunteer.wml       125)   <p>Die untenstehenden Angaben wurden in der Originalsprache
de/volunteer.wml       126)   belassen. Da diese sich ausschlie�lich auf englischsprachige
de/volunteer.wml       127)   Bewerber beziehen.</p>
de/volunteer.wml       128) 
de/volunteer.wml       129)   <a id="Summer"></a>
de/volunteer.wml       130) <a id="Projects"></a>
de/volunteer.wml       131) <h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>
de/volunteer.wml       132) 
de/volunteer.wml       133) <p>
de/volunteer.wml       134) You may find some of these projects to be good <a href="<page
de/volunteer.wml       135) gsoc>">Google Summer of Code 2008</a> ideas. We have labelled each idea
de/volunteer.wml       136) with how useful it would be to the overall Tor project
de/volunteer.wml       137) (priority), how much work we expect it would be (effort level), how much
de/volunteer.wml       138) clue you should start with (skill level), and which of our <a href="<page
de/volunteer.wml       139) people>#Core">core developers</a> would be good mentors. There are plenty
de/volunteer.wml       140) of other good ideas to work on too &mdash; see for example the <a
de/volunteer.wml       141) href="<svnsandbox>doc/spec/proposals/">current proposals</a> list, or
de/volunteer.wml       142) just make up your own ideas.
de/volunteer.wml       143) </p>
de/volunteer.wml       144) 
de/volunteer.wml       145) <ol>
de/volunteer.wml       146) 
de/volunteer.wml       147) <li>
de/volunteer.wml       148) <b>Tor Exit Scanner improvements</b>
de/volunteer.wml       149) <br />
de/volunteer.wml       150) Priority: <i>High</i>
de/volunteer.wml       151) <br />
de/volunteer.wml       152) Effort Level: <i>High</i>
de/volunteer.wml       153) <br />
de/volunteer.wml       154) Skill Level: <i>High</i>
de/volunteer.wml       155) <br />
de/volunteer.wml       156) Likely Mentors: <i>Mike</i>
de/volunteer.wml       157) <br />
de/volunteer.wml       158) Applications as of 1 Apr 00:00 UTC: <i>5</i>
de/volunteer.wml       159) <br />
de/volunteer.wml       160) The Tor exit node scanner 'SoaT', part of the <a
de/volunteer.wml       161) href="<svnsandbox>torflow/">Torflow project</a>, makes connections out
de/volunteer.wml       162) of each Tor exit node and compares the content it gets back with what it
de/volunteer.wml       163) "should" get back. The goal is to notice misconfigured, broken, and even
de/volunteer.wml       164) malicious exit relays. Alas, the code is
de/volunteer.wml       165) currently written in rather rickety perl and relies on MD5sums of
de/volunteer.wml       166) entire documents in order to determine if exit nodes are modifying
de/volunteer.wml       167) content. The problem with this is threefold: 1) Perl sucks at life.
de/volunteer.wml       168) 2) The scanner can't verify pages that are dynamic, and attackers can
de/volunteer.wml       169) focus malicious content injection on only those dynamic pages. 3)
de/volunteer.wml       170) Pages change after a while (or based on GeoIP) and begin generating
de/volunteer.wml       171) false positives.
de/volunteer.wml       172) <br />
de/volunteer.wml       173) Ideally, soat.pl would be reimplemented in a sane language with a
de/volunteer.wml       174) robust html parser library (since the rest of Torflow is in Python
de/volunteer.wml       175) that would be nice, but it is not required), and calculate signatures only for
de/volunteer.wml       176) tags and content likely to be targeted by a malicious attacker (script
de/volunteer.wml       177) tags, object links, images, css). It should also be robust in the face of
de/volunteer.wml       178) changes to content outside of Tor, and ultimately even GeoIP localized
de/volunteer.wml       179) content.
de/volunteer.wml       180) <br />
de/volunteer.wml       181) This scanner would likely be run by the Directory Authorities and
de/volunteer.wml       182) report its results to the control port via the AuthDirBadExit config
de/volunteer.wml       183) setting.
de/volunteer.wml       184) <br />
de/volunteer.wml       185) </li>
de/volunteer.wml       186) 
de/volunteer.wml       187) <li>
de/volunteer.wml       188) <b>Tor Node Scanner improvements</b>
de/volunteer.wml       189) <br />
de/volunteer.wml       190) Priority: <i>High</i>
de/volunteer.wml       191) <br />
de/volunteer.wml       192) Effort Level: <i>Medium to High</i>
de/volunteer.wml       193) <br />
de/volunteer.wml       194) Skill Level: <i>Medium to High</i>
de/volunteer.wml       195) <br />
de/volunteer.wml       196) Likely Mentors: <i>Mike</i>
de/volunteer.wml       197) <br />
de/volunteer.wml       198) Applications as of 1 Apr 00:00 UTC: <i>1</i>
de/volunteer.wml       199) <br />
de/volunteer.wml       200) Similar to the exit scanner (or perhaps even during exit scanning),
de/volunteer.wml       201) statistics can be gathered about the reliability of nodes. Nodes that
de/volunteer.wml       202) fail too high a percentage of their circuits should not be given
de/volunteer.wml       203) Guard status. Perhaps they should have their reported bandwidth
de/volunteer.wml       204) penalized by some ratio as well, or just get marked as Invalid. In
de/volunteer.wml       205) addition, nodes that exhibit a very low average stream capacity but
de/volunteer.wml       206) advertise a very high node bandwidth can also be marked as Invalid.
de/volunteer.wml       207) Much of this statistics gathering is already done, it just needs to be
de/volunteer.wml       208) transformed into something that can be reported to the Directory
de/volunteer.wml       209) Authorities to blacklist/penalize nodes in such a way that clients
de/volunteer.wml       210) will listen.
de/volunteer.wml       211) <br />
de/volunteer.wml       212) In addition, these same statistics can be gathered about the traffic
de/volunteer.wml       213) through a node. Events can be added to the <a
de/volunteer.wml       214) href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control
de/volunteer.wml       215) Protocol</a> to
de/volunteer.wml       216) report if a circuit extend attempt through the node succeeds or fails, and
de/volunteer.wml       217) passive statistics can be gathered on both bandwidth and reliability
de/volunteer.wml       218) of other nodes via a node-based monitor using these events. Such a
de/volunteer.wml       219) scanner would also report information on oddly-behaving nodes to
de/volunteer.wml       220) the Directory Authorities, but a communication channel for this
de/volunteer.wml       221) currently does not exist and would need to be developed as well.
de/volunteer.wml       222) </li>
de/volunteer.wml       223) 
de/volunteer.wml       224) <li>
de/volunteer.wml       225) <b>Help track the overall Tor Network status</b>
de/volunteer.wml       226) <br />
de/volunteer.wml       227) Priority: <i>High</i>
de/volunteer.wml       228) <br />
de/volunteer.wml       229) Effort Level: <i>Medium</i>
de/volunteer.wml       230) <br />
de/volunteer.wml       231) Skill Level: <i>Medium</i>
de/volunteer.wml       232) <br />
de/volunteer.wml       233) Likely Mentors: <i>Roger, Nick, Mike</i>
de/volunteer.wml       234) <br />
de/volunteer.wml       235) It would be great to set up an automated system for tracking network
de/volunteer.wml       236) health over time, graphing it, etc. Part of this project would involve
de/volunteer.wml       237) inventing better metrics for assessing network health and growth. Is the
de/volunteer.wml       238) average uptime of the network increasing? How many relays are qualifying
de/volunteer.wml       239) for Guard status this month compared to last month? What's the turnover
de/volunteer.wml       240) in terms of new relays showing up and relays shutting off? Periodically
de/volunteer.wml       241) people collect brief snapshots, but where it gets really interesting is
de/volunteer.wml       242) when we start tracking data points over time.
de/volunteer.wml       243) <br />
de/volunteer.wml       244) Data could be collected from the "Tor Node Scanner" item above, from
de/volunteer.wml       245) the server descriptors that each relay publishes, and from other
de/volunteer.wml       246) sources. Results over time could be integrated into one of the <a
de/volunteer.wml       247) href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be
de/volunteer.wml       248) kept separate. Speaking of the Tor Status pages, take a look at Roger's
de/volunteer.wml       249) <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
de/volunteer.wml       250) Status wish list</a>.
de/volunteer.wml       251) </li>
de/volunteer.wml       252) 
de/volunteer.wml       253) <li>
de/volunteer.wml       254) <b>Tor path selection improvements</b>
de/volunteer.wml       255) <br />
de/volunteer.wml       256) Priority: <i>High</i>
de/volunteer.wml       257) <br />
de/volunteer.wml       258) Effort Level: <i>Low to Medium</i>
de/volunteer.wml       259) <br />
de/volunteer.wml       260) Skill Level: <i>High</i>
de/volunteer.wml       261) <br />
de/volunteer.wml       262) Likely Mentors: <i>Roger, Nick, Mike</i>
de/volunteer.wml       263) <br />
de/volunteer.wml       264) Applications as of 1 Apr 00:00 UTC: <i>3</i>
de/volunteer.wml       265) <br />
de/volunteer.wml       266) Some simple improvements can be made to Tor's path selection to vastly
de/volunteer.wml       267) improve Tor speed. For instance, some of the (unofficial) <a
de/volunteer.wml       268) href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
de/volunteer.wml       269) Performance Recommendations</a> on the wiki are to increase the number of
de/volunteer.wml       270) guards and decrease the CircuitBuildTimeout. Ideally, the client would
de/volunteer.wml       271) <a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn
de/volunteer.wml       272) these values by gathering statistics on circuit construction
de/volunteer.wml       273) time</a> (and/or using values gained from Torflow), and set the timeouts
de/volunteer.wml       274) low enough such that some high percentile (75%, 90%, 1-stddev?) of
de/volunteer.wml       275) circuits succeed, yet extremely slow nodes are avoided. This would
de/volunteer.wml       276) involve some statistics gathering+basic research, and some changes to
de/volunteer.wml       277) Tor path selection code.
de/volunteer.wml       278) <br />
de/volunteer.wml       279) In addition, to improve path security, some elements from the <a
de/volunteer.wml       280) href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
de/volunteer.wml       281) Hop Paths proposal</a> could be done as part of this (since it will
de/volunteer.wml       282) likely touch the same code anyways), regardless of the adoption of
de/volunteer.wml       283) that proposal. In particular, clients probably should avoid guards that
de/volunteer.wml       284) seem to fail an excessive percentage of their circuits through them,
de/volunteer.wml       285) and non-firewalled clients should issue a warning if they are only able
de/volunteer.wml       286) to connect to a limited set of guard nodes. See also
de/volunteer.wml       287) <a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this
de/volunteer.wml       288) or-dev post</a>.
de/volunteer.wml       289) </li>
de/volunteer.wml       290) 
de/volunteer.wml       291) <li>
de/volunteer.wml       292) <b>Translation Wiki</b>
de/volunteer.wml       293) <br />
de/volunteer.wml       294) Priority: <i>High</i>
de/volunteer.wml       295) <br />
de/volunteer.wml       296) Effort Level: <i>Medium</i>
de/volunteer.wml       297) <br />
de/volunteer.wml       298) Skill Level: <i>Medium</i>
de/volunteer.wml       299) <br />
de/volunteer.wml       300) Likely Mentors: <i>Jacob</i>
de/volunteer.wml       301) <br />
de/volunteer.wml       302) We need a way to edit and translate sections of the website. Currently
de/volunteer.wml       303) the website is made up of a bunch of <a href="<svnwebsite>en/">wml
de/volunteer.wml       304) files</a>, and <a href="<page translation>">translators</a> fetch these
de/volunteer.wml       305) wml files, translate them in an editor, and either send us the translation
de/volunteer.wml       306) or use svn to commit them back. The current "cost" of publication of
de/volunteer.wml       307) website changes is quite high even for English language users. For a
de/volunteer.wml       308) single word change or any type of
de/volunteer.wml       309) minor change, the page may never be corrected or translated. It would
de/volunteer.wml       310) be nice to have a wiki that was specifically geared towards translation
de/volunteer.wml       311) and would somehow track the upstream (English) versions to indicate when
de/volunteer.wml       312) a fresh translation is needed, like our current
de/volunteer.wml       313) <a href="<page translation-status>">translation status page</a>. This
de/volunteer.wml       314) seems mostly like a job for a wiki
de/volunteer.wml       315) integrator or wiki software author. Certainly the person would need to
de/volunteer.wml       316) be interested in human languages and translation. They should at least
de/volunteer.wml       317) be minimally familiar with what Tor is; but they would not have to interact
de/volunteer.wml       318) with the software, only the documentation and the website.
de/volunteer.wml       319) </li>
de/volunteer.wml       320) 
de/volunteer.wml       321) <li>
de/volunteer.wml       322) <b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
de/volunteer.wml       323) <br />
de/volunteer.wml       324) Priority: <i>High</i>
de/volunteer.wml       325) <br />
de/volunteer.wml       326) Effort Level: <i>Medium</i>
de/volunteer.wml       327) <br />
de/volunteer.wml       328) Skill Level: <i>Medium</i>
de/volunteer.wml       329) <br />
de/volunteer.wml       330) Likely Mentors: <i>Peter, Matt</i>
de/volunteer.wml       331) <br />
de/volunteer.wml       332) Applications as of 1 Apr 00:00 UTC: <i>1</i>
de/volunteer.wml       333) <br />
de/volunteer.wml       334) Vidalia currently doesn't play nicely on Debian and Ubuntu with the
de/volunteer.wml       335) default Tor packages. The current Tor packages automatically start Tor
de/volunteer.wml       336) as a daemon running as the debian-tor user and (sensibly) do not have a
de/volunteer.wml       337) <a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
de/volunteer.wml       338) in the default torrc. Consequently, Vidalia will try
de/volunteer.wml       339) to start its own Tor process since it could not connect to the existing
de/volunteer.wml       340) Tor, and Vidalia's Tor process will then exit with an error message
de/volunteer.wml       341) the user likely doesn't understand since Tor cannot bind its listening
de/volunteer.wml       342) ports &mdash; they're already in use by the original Tor daemon.
de/volunteer.wml       343) <br />
de/volunteer.wml       344) The current solution involves either telling the user to stop the
de/volunteer.wml       345) existing Tor daemon and let Vidalia start its own Tor process, or
de/volunteer.wml       346) explaining to the user how to set a control port and password in their
de/volunteer.wml       347) torrc. A better solution on Debian would be to use Tor's ControlSocket,
de/volunteer.wml       348) which allows Vidalia to talk to Tor via a Unix domain socket, and could
de/volunteer.wml       349) possibly be enabled by default in Tor's Debian packages. Vidalia can
de/volunteer.wml       350) then authenticate to Tor using filesystem-based (cookie) authentication
de/volunteer.wml       351) if the user running Vidalia is also in the debian-tor group.
de/volunteer.wml       352) <br />
de/volunteer.wml       353) This project will first involve adding support for Tor's ControlSocket
de/volunteer.wml       354) to Vidalia. The student will then develop and test Debian and Ubuntu
de/volunteer.wml       355) packages for Vidalia that conform to Debian's packaging standards and
de/volunteer.wml       356) make sure they work well with the existing Tor packages. We can also
de/volunteer.wml       357) set up an apt repository to host the new Vidalia packages.
de/volunteer.wml       358) <br />
de/volunteer.wml       359) The next challenge would be to find an intuitive usable way for Vidalia
de/volunteer.wml       360) to be able to change Tor's configuration (torrc) even though it is
de/volunteer.wml       361) located in <code>/etc/tor/torrc</code> and thus immutable. The best
de/volunteer.wml       362) idea we've come up with so far is to feed Tor a new configuration via
de/volunteer.wml       363) the ControlSocket when Vidalia starts, but that's bad because Tor starts
de/volunteer.wml       364) each boot with a different configuration than the user wants. The second
de/volunteer.wml       365) best idea
de/volunteer.wml       366) we've come up with is for Vidalia to write out a temporary torrc file
de/volunteer.wml       367) and ask the user to manually move it to <code>/etc/tor/torrc</code>,
de/volunteer.wml       368) but that's bad because users shouldn't have to mess with files directly.
de/volunteer.wml       369) <br />
de/volunteer.wml       370) A student undertaking this project should have prior knowledge of
de/volunteer.wml       371) Debian package management and some C++ development experience. Previous
de/volunteer.wml       372) experience with Qt is helpful, but not required.
de/volunteer.wml       373) </li>
de/volunteer.wml       374) 
de/volunteer.wml       375) <li>
de/volunteer.wml       376) <b>Improving Tor's ability to resist censorship</b>
de/volunteer.wml       377) <br />
de/volunteer.wml       378) Priority: <i>High</i>
de/volunteer.wml       379) <br />
de/volunteer.wml       380) Effort Level: <i>High</i>
de/volunteer.wml       381) <br />
de/volunteer.wml       382) Skill Level: <i>High</i>
de/volunteer.wml       383) <br />
de/volunteer.wml       384) Likely Mentors: <i>Nick</i>
de/volunteer.wml       385) <br />
de/volunteer.wml       386) The Tor 0.2.0.x series makes <a
de/volunteer.wml       387) href="<svnsandbox>doc/design-paper/blocking.html">significant
de/volunteer.wml       388) improvements</a> in resisting national and organizational censorship.
de/volunteer.wml       389) But Tor still needs better mechanisms for some parts of its
de/volunteer.wml       390) anti-censorship design.  For example, current Tors can only listen on a
de/volunteer.wml       391) single address/port combination at a time.  There's
de/volunteer.wml       392) <a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
de/volunteer.wml       393) proposal to address this limitation</a> and allow clients to connect
de/volunteer.wml       394) to any given Tor on multiple addresses and ports, but it needs more
de/volunteer.wml       395) work.  Another anti-censorship project (far more difficult) is to try
de/volunteer.wml       396) to make Tor more scanning-resistant.  Right now, an adversary can identify
de/volunteer.wml       397) <a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
de/volunteer.wml       398) just by trying to connect to them, following the Tor protocol, and
de/volunteer.wml       399) seeing if they respond.  To solve this, bridges could
de/volunteer.wml       400) <a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
de/volunteer.wml       401) webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
de/volunteer.wml       402) and not act like bridges until the user provides a bridge-specific key.
de/volunteer.wml       403) <br />
de/volunteer.wml       404) This project involves a lot of research and design. One of the big
de/volunteer.wml       405) challenges will be identifying and crafting approaches that can still
de/volunteer.wml       406) resist an adversary even after the adversary knows the design, and
de/volunteer.wml       407) then trading off censorship resistance with usability and robustness.
de/volunteer.wml       408) </li>
de/volunteer.wml       409) 
de/volunteer.wml       410) <li>
de/volunteer.wml       411) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
de/volunteer.wml       412) <br />
de/volunteer.wml       413) Priority: <i>Medium</i>
de/volunteer.wml       414) <br />
de/volunteer.wml       415) Effort Level: <i>High</i>
de/volunteer.wml       416) <br />
de/volunteer.wml       417) Skill Level: <i>High</i>
de/volunteer.wml       418) <br />
de/volunteer.wml       419) Likely Mentors: <i>Matt, Jacob</i>
de/volunteer.wml       420) <br />
de/volunteer.wml       421) We're in need of a good authenticated-update framework.
de/volunteer.wml       422) Vidalia already has the ability to notice when the user is running an
de/volunteer.wml       423) outdated or unrecommended version of Tor, using signed statements inside
de/volunteer.wml       424) the Tor directory information. Currently, Vidalia simply pops
de/volunteer.wml       425) up a little message box that lets the user know they should manually
de/volunteer.wml       426) upgrade. The goal of this project would be to extend Vidalia with the
de/volunteer.wml       427) ability to also fetch and install the updated Tor software for the
de/volunteer.wml       428) user. We should do the fetches via Tor when possible, but also fall back
de/volunteer.wml       429) to direct fetches in a smart way. Time permitting, we would also like
de/volunteer.wml       430) to be able to update other
de/volunteer.wml       431) applications included in the bundled installers, such as Polipo and
de/volunteer.wml       432) Vidalia itself.
de/volunteer.wml       433) <br />
de/volunteer.wml       434) To complete this project, the student will first need to first investigate
de/volunteer.wml       435) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
de/volunteer.wml       436) their strengths, weaknesses, security properties, and ability to be
de/volunteer.wml       437) integrated into Vidalia. If none are found to be suitable, the student
de/volunteer.wml       438) will design their own auto-update framework, document the design, and
de/volunteer.wml       439) then discuss the design with other developers to assess any security
de/volunteer.wml       440) issues. The student will then implement their framework (or integrate
de/volunteer.wml       441) an existing one) and test it.
de/volunteer.wml       442) <br />
de/volunteer.wml       443) A student undertaking this project should have good C++ development
de/volunteer.wml       444) experience. Previous experience with Qt is helpful, but not required. The
de/volunteer.wml       445) student should also have a good understanding of common security
de/volunteer.wml       446) practices, such as package signature verification. Good writing ability
de/volunteer.wml       447) is also important for this project, since a vital step of the project
de/volunteer.wml       448) will be producing a design document for others to review and discuss
de/volunteer.wml       449) with the student prior to implementation.
de/volunteer.wml       450) </li>
de/volunteer.wml       451) 
de/volunteer.wml       452) <li>
de/volunteer.wml       453) <b>An Improved and More Usable Network Map in Vidalia</b>
de/volunteer.wml       454) <br />
de/volunteer.wml       455) Priority: <i>Medium</i>
de/volunteer.wml       456) <br />
de/volunteer.wml       457) Effort Level: <i>Medium</i>
de/volunteer.wml       458) <br />
de/volunteer.wml       459) Skill Level: <i>Medium to High</i>
de/volunteer.wml       460) <br />
de/volunteer.wml       461) Likely Mentors: <i>Matt</i>
de/volunteer.wml       462) <br />
de/volunteer.wml       463) One of Vidalia's existing features is a network map that shows the user
de/volunteer.wml       464) the approximate geographic location of relays in the Tor network and
de/volunteer.wml       465) plots the paths the user's traffic takes as it is tunneled through the
de/volunteer.wml       466) Tor network. The map is currently not very interactive and has rather
de/volunteer.wml       467) poor graphics. Instead, we would like to leverage KDE's Marble widget
de/volunteer.wml       468) that gives us a better quality map and enables improved interactivity,
de/volunteer.wml       469) such as allowing the user to click on individual relays or circuits to
de/volunteer.wml       470) display additional information. We might also consider adding the ability
de/volunteer.wml       471) for users to click on a particular relay or a country containing one or
de/volunteer.wml       472) more Tor exit relays and say, "I want my connections to foo.com to exit
de/volunteer.wml       473) from here."
de/volunteer.wml       474) <br />
de/volunteer.wml       475) This project will first involve the student getting familiar with Vidalia
de/volunteer.wml       476) and the Marble widget's API. The student will then integrate the widget
de/volunteer.wml       477) into Vidalia and customize Marble to be better suited for our application,
de/volunteer.wml       478) such as making circuits clickable, storing cached map data in Vidalia's
de/volunteer.wml       479) own data directory, and customizing some of the widget's dialogs.
de/volunteer.wml       480) <br />
de/volunteer.wml       481) A student undertaking this project should have good C++ development
de/volunteer.wml       482) experience. Previous experience with Qt and CMake is helpful, but not
de/volunteer.wml       483) required.
de/volunteer.wml       484) </li>
de/volunteer.wml       485) 
de/volunteer.wml       486) <li>
de/volunteer.wml       487) <b>Tor Controller Status Event Interface</b>
de/volunteer.wml       488) <br />
de/volunteer.wml       489) Priority: <i>Medium</i>
de/volunteer.wml       490) <br />
de/volunteer.wml       491) Effort Level: <i>Medium</i>
de/volunteer.wml       492) <br />
de/volunteer.wml       493) Skill Level: <i>Medium</i>
de/volunteer.wml       494) <br />
de/volunteer.wml       495) Likely Mentors: <i>Matt, Roger</i>
de/volunteer.wml       496) <br />
de/volunteer.wml       497) There are a number of status changes inside Tor of which the user may need
de/volunteer.wml       498) to be informed. For example, if the user is trying to set up his Tor as a
de/volunteer.wml       499) relay and Tor decides that its ports are not reachable from outside
de/volunteer.wml       500) the user's network, we should alert the user. Currently, all the user
de/volunteer.wml       501) gets is a couple log messages in Vidalia's 'message log' window, which they
de/volunteer.wml       502) likely never see since they don't receive a notification that something
de/volunteer.wml       503) has gone wrong. Even if the user does actually look at the message log,
de/volunteer.wml       504) most of the messages make little sense to the novice user.
de/volunteer.wml       505) <br />
de/volunteer.wml       506) Tor has the ability to inform Vidalia of many such status changes, and
de/volunteer.wml       507) we recently implemented support for a couple of these events. Still,
de/volunteer.wml       508) there are many more status events the user should be informed of and we
de/volunteer.wml       509) need a better UI for actually displaying them to the user.
de/volunteer.wml       510) <br />
de/volunteer.wml       511) The goal of this project then is to design and implement a UI for
de/volunteer.wml       512) displaying Tor status events to the user. For example, we might put a
de/volunteer.wml       513) little badge on Vidalia's tray icon that alerts the user to new status
de/volunteer.wml       514) events they should look at. Double-clicking the icon could bring up a
de/volunteer.wml       515) dialog that summarizes recent status events in simple terms and maybe
de/volunteer.wml       516) suggests a remedy for any negative events if they can be corrected by
de/volunteer.wml       517) the user. Of course, this is just an example and the student is free to
de/volunteer.wml       518) suggest another approach.
de/volunteer.wml       519) <br />
de/volunteer.wml       520) A student undertaking this project should have good UI design and layout
de/volunteer.wml       521) and some C++ development experience. Previous experience with Qt and
de/volunteer.wml       522) Qt's Designer will be very helpful, but are not required. Some
de/volunteer.wml       523) English writing ability will also be useful, since this project will
de/volunteer.wml       524) likely involve writing small amounts of help documentation that should
de/volunteer.wml       525) be understandable by non-technical users. Bonus points for some graphic
de/volunteer.wml       526) design/Photoshop fu, since we might want/need some shiny new icons too.
de/volunteer.wml       527) </li>
de/volunteer.wml       528) 
de/volunteer.wml       529) <li>
de/volunteer.wml       530) <b>Improvements on our active browser configuration tester</b> -
de/volunteer.wml       531) <a href="https://check.torproject.org/">https://check.torproject.org/</a>
de/volunteer.wml       532) <br />
de/volunteer.wml       533) Priority: <i>Medium</i>
de/volunteer.wml       534) <br />
de/volunteer.wml       535) Effort Level: <i>Low</i>
de/volunteer.wml       536) <br />
de/volunteer.wml       537) Skill Level: <i>Low to Medium</i>
de/volunteer.wml       538) <br />
de/volunteer.wml       539) Likely Mentors: <i>Jacob, Steven</i>
de/volunteer.wml       540) <br />
de/volunteer.wml       541) Applications as of 1 Apr 00:00 UTC: <i>1</i>
de/volunteer.wml       542) <br />
de/volunteer.wml       543) We currently have a functional web page to detect if Tor is working. It
de/volunteer.wml       544) has a few places where it falls short. It requires improvements with
de/volunteer.wml       545) regard to default languages and functionality. It currently only responds
de/volunteer.wml       546) in English. In addition, it is a hack of a perl script that should have
de/volunteer.wml       547) never seen the light of day. It should probably be rewritten in python
de/volunteer.wml       548) with multi-lingual support in mind. It currently uses the <a
de/volunteer.wml       549) href="http://exitlist.torproject.org/">Tor DNS exit list</a>
de/volunteer.wml       550) and should continue to do so in the future. It currently result in certain
de/volunteer.wml       551) false positives and these should be discovered, documented, and fixed
de/volunteer.wml       552) where possible. Anyone working on this project should be interested in
de/volunteer.wml       553) DNS, basic perl or preferably python programming skills, and will have
de/volunteer.wml       554) to interact minimally with Tor to test their code.
de/volunteer.wml       555) <br />
de/volunteer.wml       556) If you want to make the project more exciting
de/volunteer.wml       557) and involve more design and coding, take a look at <a
de/volunteer.wml       558) href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
de/volunteer.wml       559) 131-verify-tor-usage.txt</a>.
de/volunteer.wml       560) </li>
de/volunteer.wml       561) 
de/volunteer.wml       562) <li>
de/volunteer.wml       563) <b>Improvements on our DNS Exit List service</b> -
de/volunteer.wml       564) <a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
de/volunteer.wml       565) <br />
de/volunteer.wml       566) Priority: <i>Medium</i>
de/volunteer.wml       567) <br />
de/volunteer.wml       568) Effort Level: <i>Low</i>
de/volunteer.wml       569) <br />
de/volunteer.wml       570) Skill Level: <i>Low</i>
de/volunteer.wml       571) <br />
de/volunteer.wml       572) Likely Mentors: <i>Jacob, Tup</i>
de/volunteer.wml       573) <br />
de/volunteer.wml       574) The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
de/volunteer.wml       575) is written by our fabulous anonymous
de/volunteer.wml       576) contributer Tup. It's a DNS server written in Haskell that supports part of our <a
de/volunteer.wml       577) href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">exitlist
de/volunteer.wml       578) design document</a>. Currently, it is functional and it is used by
de/volunteer.wml       579) check.torproject.org and other users. The issues that are outstanding
de/volunteer.wml       580) are mostly aesthetic. This wonderful service could use a much better
de/volunteer.wml       581) website using the common Tor theme. It would be best served with better
de/volunteer.wml       582) documentation for common services that use an RBL. It could use more
de/volunteer.wml       583) publicity. A person working on this project should be interested in DNS,
de/volunteer.wml       584) basic RBL configuration for popular services, and writing documentation.
de/volunteer.wml       585) The person would require minimal Tor interaction &mdash; testing their
de/volunteer.wml       586) own documentation at the very least. Furthermore, it would be useful
de/volunteer.wml       587) if they were interested in Haskell and wanted to implement more of the
de/volunteer.wml       588) torel-design.txt suggestions.
de/volunteer.wml       589) </li>
de/volunteer.wml       590) 
de/volunteer.wml       591) <li>
de/volunteer.wml       592) <b>Testing integration of Tor with web browsers for our end users</b>
de/volunteer.wml       593) <br />
de/volunteer.wml       594) Priority: <i>Medium</i>
de/volunteer.wml       595) <br />
de/volunteer.wml       596) Effort Level: <i>Medium</i>
de/volunteer.wml       597) <br />
de/volunteer.wml       598) Skill Level: <i>Medium</i>
de/volunteer.wml       599) <br />
de/volunteer.wml       600) Likely Mentors: <i>Jacob, Mike, Greg</i>
de/volunteer.wml       601) <br />
de/volunteer.wml       602) Applications as of 1 Apr 00:00 UTC: <i>1</i>
de/volunteer.wml       603) <br />
de/volunteer.wml       604) The Tor project currently lacks a solid test suite to ensure that a
de/volunteer.wml       605) user has a properly and safely configured web browser. It should test for as
de/volunteer.wml       606) many known issues as possible. It should attempt to decloak the
de/volunteer.wml       607) user in any way possible. Two current webpages that track these
de/volunteer.wml       608) kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
de/volunteer.wml       609) href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
de/volunteer.wml       610) with their proof of concept code, bug issues, etc</a>. HD Moore runs
de/volunteer.wml       611) the <a href="http://metasploit.com/research/projects/decloak/">metasploit
de/volunteer.wml       612) decloak website</a>. A student interested in defending Tor could start
de/volunteer.wml       613) by collecting as many workable and known methods for decloaking a
de/volunteer.wml       614) Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
de/volunteer.wml       615) be helpful as a start.) The student should be familiar with the common
de/volunteer.wml       616) pitfalls but
de/volunteer.wml       617) possibly have new methods in mind for implementing decloaking issues. The
de/volunteer.wml       618) website should ensure that it tells a user what their problem is. It
de/volunteer.wml       619) should help them to fix the problem or direct them to the proper support
de/volunteer.wml       620) channels. The student should be closely familiar with using Tor and how
de/volunteer.wml       621) to prevent Tor information leakage.
de/volunteer.wml       622) </li>
de/volunteer.wml       623) 
de/volunteer.wml       624) <li>
de/volunteer.wml       625) <b>Libevent and Tor integration improvements</b>
de/volunteer.wml       626) <br />
de/volunteer.wml       627) Priority: <i>Medium</i>
de/volunteer.wml       628) <br />
de/volunteer.wml       629) Effort Level: <i>High</i>
de/volunteer.wml       630) <br />
de/volunteer.wml       631) Skill Level: <i>Medium to High</i>
de/volunteer.wml       632) <br />
de/volunteer.wml       633) Likely Mentors: <i>Nick</i>
de/volunteer.wml       634) <br />
de/volunteer.wml       635) Tor should make better use of the more recent features of Niels
de/volunteer.wml       636) Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
de/volunteer.wml       637) library.  Tor already uses Libevent for its low-level asynchronous IO
de/volunteer.wml       638) calls, and could also use Libevent's increasingly good implementations
de/volunteer.wml       639) of network buffers and of HTTP.  This wouldn't be simply a matter of
de/volunteer.wml       640) replacing Tor's internal calls with calls to Libevent: instead, we'll
de/volunteer.wml       641) need to refactor Tor to use Libevent calls that do not follow the
de/volunteer.wml       642) same models as Tor's existing backends. Also, we'll need to add
de/volunteer.wml       643) missing functionality to Libevent as needed &mdash; most difficult likely
de/volunteer.wml       644) will be adding OpenSSL support on top of Libevent's buffer abstraction.
de/volunteer.wml       645) Also tricky will be adding rate-limiting to Libevent.
de/volunteer.wml       646) </li>
de/volunteer.wml       647) 
de/volunteer.wml       648) <li>
de/volunteer.wml       649) <b>Tuneup Tor!</b>
de/volunteer.wml       650) <br />
de/volunteer.wml       651) Priority: <i>Medium</i>
de/volunteer.wml       652) <br />
de/volunteer.wml       653) Effort Level: <i>Medium</i>
de/volunteer.wml       654) <br />
de/volunteer.wml       655) Skill Level: <i>Medium to High</i>
de/volunteer.wml       656) <br />
de/volunteer.wml       657) Likely Mentors: <i>Nick, Roger, Mike</i>
de/volunteer.wml       658) <br />
de/volunteer.wml       659) Right now, Tor relays measure and report their own bandwidth, and Tor
de/volunteer.wml       660) clients choose which relays to use in part based on that bandwidth.
de/volunteer.wml       661) This approach is vulnerable to
de/volunteer.wml       662) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
de/volunteer.wml       663) relays lie about their bandwidth</a>;
de/volunteer.wml       664) to address this, Tor currently caps the maximum bandwidth
de/volunteer.wml       665) it's willing to believe any relay provides.  This is a limited fix, and
de/volunteer.wml       666) a waste of bandwidth capacity to boot.  Instead,
de/volunteer.wml       667) Tor should possibly measure bandwidth in a more distributed way, perhaps
de/volunteer.wml       668) as described in the
de/volunteer.wml       669) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
de/volunteer.wml       670) Tor"</a> paper
de/volunteer.wml       671) by Snader and Borisov. A student could use current testing code to
de/volunteer.wml       672) double-check this paper's findings and verify the extent to which they
de/volunteer.wml       673) dovetail with Tor as deployed in the wild, and determine good ways to
de/volunteer.wml       674) incorporate them into their suggestions Tor network without adding too
de/volunteer.wml       675) much communications overhead between relays and directory
de/volunteer.wml       676) authorities.
de/volunteer.wml       677) </li>
de/volunteer.wml       678) 
de/volunteer.wml       679) <!--
de/volunteer.wml       680) <li>
de/volunteer.wml       681) <b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
de/volunteer.wml       682) <br />
de/volunteer.wml       683) Priority: <i>High</i>
de/volunteer.wml       684) <br />
de/volunteer.wml       685) Effort Level: <i>Medium</i>
de/volunteer.wml       686) <br />
de/volunteer.wml       687) Skill Level: <i>Medium</i>
de/volunteer.wml       688) <br />
de/volunteer.wml       689) Likely Mentors: <i>Jacob, Andrew</i>
de/volunteer.wml       690) <br />
de/volunteer.wml       691) It would be useful to have automated build processes for Windows and
de/volunteer.wml       692) probably other platforms. The purpose of having a continuous integration
de/volunteer.wml       693) build environment is to ensure that Windows isn't left behind for any of
de/volunteer.wml       694) the software projects used in the Tor project or its accompanying.<br />
de/volunteer.wml       695) Buildbot may be a good choice for this as it appears to support all of
de/volunteer.wml       696) the platforms Tor does. See the
de/volunteer.wml       697) <a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
de/volunteer.wml       698) buildbot</a>.<br />
de/volunteer.wml       699) There may be better options and the person undertaking this task should
de/volunteer.wml       700) evaluate other options. Any person working on this automatic build
de/volunteer.wml       701) process should have experience or be willing to learn how to build all
de/volunteer.wml       702) of the respective Tor related code bases from scratch. Furthermore, the
de/volunteer.wml       703) person should have some experience building software in Windows
de/volunteer.wml       704) environments as this is the target audience we want to ensure we do not
de/volunteer.wml       705) leave behind. It would require close work with the Tor source code but
de/volunteer.wml       706) probably only in the form of building, not authoring.<br />
de/volunteer.wml       707) Additionally, we need to automate our performance testing for all platforms.
de/volunteer.wml       708) We've got buildbot (except on Windows &mdash; as noted above) to automate
de/volunteer.wml       709) our regular integration and compile testing already,
de/volunteer.wml       710) but we need to get our network simulation tests (as built in torflow)
de/volunteer.wml       711) updated for more recent versions of Tor, and designed to launch a test
de/volunteer.wml       712) network either on a single machine, or across several, so we can test
de/volunteer.wml       713) changes in performance on machines in different roles automatically.
de/volunteer.wml       714) </li>
de/volunteer.wml       715) -->
de/volunteer.wml       716) 
de/volunteer.wml       717) <li>
de/volunteer.wml       718) <b>Improve our unit testing process</b>
de/volunteer.wml       719) <br />
de/volunteer.wml       720) Priority: <i>Medium</i>
de/volunteer.wml       721) <br />
de/volunteer.wml       722) Effort Level: <i>Medium</i>
de/volunteer.wml       723) <br />
de/volunteer.wml       724) Skill Level: <i>Medium</i>
de/volunteer.wml       725) <br />
de/volunteer.wml       726) Likely Mentors: <i>Nick</i>
de/volunteer.wml       727) <br />
de/volunteer.wml       728) Tor needs to be far more tested. This is a multi-part effort. To start
de/volunteer.wml       729) with, our unit test coverage should rise substantially, especially in
de/volunteer.wml       730) the areas outside the utility functions. This will require significant
de/volunteer.wml       731) refactoring of some parts of Tor, in order to dissociate as much logic
de/volunteer.wml       732) as possible from globals.
de/volunteer.wml       733) <br />
de/volunteer.wml       734) Additionally, we need to automate our performance testing. We've got
de/volunteer.wml       735) buildbot to automate our regular integration and compile testing already
de/volunteer.wml       736) (though we need somebody to set it up on Windows),
de/volunteer.wml       737) but we need to get our network simulation tests (as built in TorFlow: see
de/volunteer.wml       738) the "Tor Node Scanner improvements" item)
de/volunteer.wml       739) updated for more recent versions of Tor, and designed to launch a test
de/volunteer.wml       740) network either on a single machine, or across several, so we can test
de/volunteer.wml       741) changes in performance on machines in different roles automatically.
de/volunteer.wml       742) </li>
de/volunteer.wml       743) 
de/volunteer.wml       744) <li>
de/volunteer.wml       745) <b>Help revive an independent Tor client implementation</b>
de/volunteer.wml       746) <br />
de/volunteer.wml       747) Priority: <i>Medium</i>
de/volunteer.wml       748) <br />
de/volunteer.wml       749) Effort Level: <i>High</i>
de/volunteer.wml       750) <br />
de/volunteer.wml       751) Skill Level: <i>Medium to High</i>
de/volunteer.wml       752) <br />
de/volunteer.wml       753) Likely Mentors: <i>Karsten, Nick</i>
de/volunteer.wml       754) <br />
de/volunteer.wml       755) Applications as of 1 Apr 00::00 UTC: <i>4</i>
de/volunteer.wml       756) <br />
de/volunteer.wml       757) Reanimate one of the approaches to implement a Tor client in Java,
de/volunteer.wml       758) e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
de/volunteer.wml       759) project</a>, and make it run on <a
de/volunteer.wml       760) href="http://code.google.com/android/">Android</a>. The first step
de/volunteer.wml       761) would be to port the existing code and execute it in an Android
de/volunteer.wml       762) environment. Next, the code should be updated to support the newer Tor
de/volunteer.wml       763) protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
de/volunteer.wml       764) directory protocol</a>. Further, support for requesting or even
de/volunteer.wml       765) providing Tor hidden services would be neat, but not required.
de/volunteer.wml       766) <br />
de/volunteer.wml       767) The student should be able to understand and write new Java code, including
de/volunteer.wml       768) a Java cryptography API. Being able to read C code would be helpful,
de/volunteer.wml       769) too. The student should be willing to read the existing documentation,
de/volunteer.wml       770) implement code based on it, and refine the documentation
de/volunteer.wml       771) when things are underdocumented. This project is mostly about coding and
de/volunteer.wml       772) to a small degree about design.
de/volunteer.wml       773) </li>
de/volunteer.wml       774) 
de/volunteer.wml       775) <li>
de/volunteer.wml       776) <b>Automatic system tests and automatically starting private Tor networks</b>
de/volunteer.wml       777) <br />
de/volunteer.wml       778) Priority: <i>Medium</i>
de/volunteer.wml       779) <br />
de/volunteer.wml       780) Effort Level: <i>Medium</i>
de/volunteer.wml       781) <br />
de/volunteer.wml       782) Skill Level: <i>Medium</i>
de/volunteer.wml       783) <br />
de/volunteer.wml       784) Likely Mentors: <i>Karsten, Nick, Roger</i>
de/volunteer.wml       785) <br />
de/volunteer.wml       786) Applications as of 1 Apr 00:00 UTC: <i>2</i>
de/volunteer.wml       787) <br />
de/volunteer.wml       788) Write a tool that runs automatic system tests in addition
de/volunteer.wml       789) to the existing unit tests. The Java-based Tor simulator <a
de/volunteer.wml       790) href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
de/volunteer.wml       791) might be a good start for starting up a private Tor network, using it
de/volunteer.wml       792) for a while, and verifying that at least parts of it are working. This
de/volunteer.wml       793) project requires to conceive a blueprint for performing system tests
de/volunteer.wml       794) of private Tor networks, before starting to code. Typical types of
de/volunteer.wml       795) tests range from performing single requests over the private network to
de/volunteer.wml       796) manipulating exchanged messages and see if nodes handle corrupt messages
de/volunteer.wml       797) appropriately.
de/volunteer.wml       798) <br />
de/volunteer.wml       799) The student should be able to obtain a good understanding
de/volunteer.wml       800) of how Tor works and what problems and bugs could arise to design good
de/volunteer.wml       801) test cases. Understanding the existing Tor code structure and documentation is
de/volunteer.wml       802) vital. If PuppeTor is used, the student should also be able to understand
de/volunteer.wml       803) and possibly extend an existing Java application. This project is partly
de/volunteer.wml       804) about design and partly about coding.
de/volunteer.wml       805) </li>
de/volunteer.wml       806) 
de/volunteer.wml       807) <li>
de/volunteer.wml       808) <b>Bring moniTor to life</b>
de/volunteer.wml       809) <br />
de/volunteer.wml       810) Priority: <i>Medium</i>
de/volunteer.wml       811) <br />
de/volunteer.wml       812) Effort Level: <i>Medium</i>
de/volunteer.wml       813) <br />
de/volunteer.wml       814) Skill Level: <i>Low to Medium</i>
de/volunteer.wml       815) <br />
de/volunteer.wml       816) Likely Mentors: <i>Karsten, Jacob</i>
de/volunteer.wml       817) <br />
de/volunteer.wml       818) Applications as of 1 Apr 00::00 UTC: <i>2</i>
de/volunteer.wml       819) <br />
de/volunteer.wml       820) Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
de/volunteer.wml       821) management tool for Tor relays. The purpose of such a tool would be
de/volunteer.wml       822) to monitor a local Tor relay via its control port and include useful
de/volunteer.wml       823) system information of the underlying machine. When running this tool, it
de/volunteer.wml       824) would dynamically update its content like top does for Linux processes.
de/volunteer.wml       825) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
de/volunteer.wml       826) or-dev post</a> might be a good first read.
de/volunteer.wml       827) <br />
de/volunteer.wml       828) The student should be familiar
de/volunteer.wml       829) with or willing to learn about administering a Tor relay and configuring
de/volunteer.wml       830) it via its control port. As an initial prototype is written in Python,
de/volunteer.wml       831) some knowledge about writing Python code would be helpful, too. This
de/volunteer.wml       832) project is one part about identifying requirements to such a
de/volunteer.wml       833) tool and designing its interface, and one part lots of coding.
de/volunteer.wml       834) </li>
de/volunteer.wml       835) 
de/volunteer.wml       836) <li>
de/volunteer.wml       837) <b>Torbutton improvements</b>
de/volunteer.wml       838) <br />
de/volunteer.wml       839) Priority: <i>Medium</i>
de/volunteer.wml       840) <br />
de/volunteer.wml       841) Effort Level: <i>High</i>
de/volunteer.wml       842) <br />
de/volunteer.wml       843) Skill Level: <i>High</i>
de/volunteer.wml       844) <br />
de/volunteer.wml       845) Likely Mentors: <i>Mike</i>
de/volunteer.wml       846) <br/>
de/volunteer.wml       847) Torbutton has a number of improvements that can be made in the post-1.2
de/volunteer.wml       848) timeframe. Most of these are documented as feature requests in the <a
de/volunteer.wml       849) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">Torbutton
de/volunteer.wml       850) flyspray section</a>. Good examples include: stripping off node.exit on http
de/volunteer.wml       851) headers, more fine-grained control over formfill blocking, improved referrer
de/volunteer.wml       852) spoofing based on the domain of the site (a-la <a
de/volunteer.wml       853) href="https://addons.mozilla.org/en-US/firefox/addon/953">refcontrol extension</a>),
de/volunteer.wml       854) tighter integration with Vidalia for reporting Tor status, a New Identity
de/volunteer.wml       855) button with Tor integration and multiple identity management, and anything
de/volunteer.wml       856) else you might think of.
de/volunteer.wml       857) <br />
de/volunteer.wml       858) This work would be independent coding in Javascript and the fun world of <a
de/volunteer.wml       859) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
de/volunteer.wml       860) with not too much involvement in the Tor internals.
de/volunteer.wml       861) </li>
de/volunteer.wml       862) 
de/volunteer.wml       863) <li>
de/volunteer.wml       864) <b>Porting Polipo to Windows</b>
de/volunteer.wml       865) <br />
de/volunteer.wml       866) Priority: <i>Medium</i>
de/volunteer.wml       867) <br />
de/volunteer.wml       868) Effort Level: <i>Medium</i>
de/volunteer.wml       869) <br />
de/volunteer.wml       870) Skill Level: <i>Medium to High</i>
de/volunteer.wml       871) <br />
de/volunteer.wml       872) Likely Mentors: <i>Andrew, Steven, Roger</i>
de/volunteer.wml       873) <br />
de/volunteer.wml       874) Help port <a
de/volunteer.wml       875) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
de/volunteer.wml       876) Windows. Example topics to tackle include:
de/volunteer.wml       877) 1) handle spaces in path names and understand the filesystem
de/volunteer.wml       878) namespace &mdash; that is, where application data, personal data,
de/volunteer.wml       879) and program data typically reside in various versions of Windows. 2) the
de/volunteer.wml       880) ability to handle ipv6 communications. 3) the ability to asynchronously
de/volunteer.wml       881) query name servers, find the system nameservers, and manage netbios
de/volunteer.wml       882) and dns queries. 4) use native regex capabilities of Windows, rather
de/volunteer.wml       883) than using 3rd party GNU regex libraries. 5) manage events and buffers
de/volunteer.wml       884) natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
de/volunteer.wml       885) Windows it's whatever the config specifies). 6) some sort of GUI config
de/volunteer.wml       886) and reporting tool, bonus if it has a systray icon with right clickable
de/volunteer.wml       887) menu options. Double bonus if it's cross-platform compatible.
de/volunteer.wml       888) </li>
de/volunteer.wml       889) 
de/volunteer.wml       890) <li>
de/volunteer.wml       891) <b>Make our diagrams beautiful and automated</b>
de/volunteer.wml       892) <br />
de/volunteer.wml       893) Priority: <i>Medium</i>
de/volunteer.wml       894) <br />
de/volunteer.wml       895) Effort Level: <i>Low</i>
de/volunteer.wml       896) <br />
de/volunteer.wml       897) Skill Level: <i>Low</i>
de/volunteer.wml       898) <br />
de/volunteer.wml       899) Likely Mentors: <i>Andrew</i>
de/volunteer.wml       900) <br />
de/volunteer.wml       901) We need a way to generate the website diagrams (for example, the "How
de/volunteer.wml       902) Tor Works" pictures on the <a href="<page overview>">overview page</a>
de/volunteer.wml       903) from source, so we can translate them as UTF-8 text rather than edit
de/volunteer.wml       904) them by hand with Gimp. We might want to
de/volunteer.wml       905) integrate this as an wml file so translations are easy and images are
de/volunteer.wml       906) generated in multiple languages whenever we build the website. See the
de/volunteer.wml       907) "Translation Wiki" idea above.
de/volunteer.wml       908) </li>
de/volunteer.wml       909) 
de/volunteer.wml       910) <li>
de/volunteer.wml       911) <b>Improve the LiveCD offerings for the Tor community</b>
de/volunteer.wml       912) <br />
de/volunteer.wml       913) Priority: <i>Low</i>
de/volunteer.wml       914) <br />
de/volunteer.wml       915) Effort Level: <i>Low</i>
de/volunteer.wml       916) <br />
de/volunteer.wml       917) Skill Level: <i>Medium to High</i>
de/volunteer.wml       918) <br />
de/volunteer.wml       919) Likely Mentors: <i>Anonym, Jacob, Roger</i>
de/volunteer.wml       920) <br />
de/volunteer.wml       921) How can we make the <a
de/volunteer.wml       922) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
de/volunteer.wml       923) easier to maintain, improve, and document?
de/volunteer.wml       924) </li>
de/volunteer.wml       925) 
de/volunteer.wml       926) <li>
de/volunteer.wml       927) <b>Rework and extend Blossom</b>
de/volunteer.wml       928) <br />
de/volunteer.wml       929) Priority: <i>Medium</i>
de/volunteer.wml       930) <br />
de/volunteer.wml       931) Effort Level: <i>Medium to High</i>
de/volunteer.wml       932) <br />
de/volunteer.wml       933) Skill Level: <i>Medium to High</i>
de/volunteer.wml       934) <br />
de/volunteer.wml       935) Likely Mentors: <i>Goodell</i>
de/volunteer.wml       936) <br />
de/volunteer.wml       937) Rework and extend Blossom (a tool for monitoring and
de/volunteer.wml       938) selecting appropriate Tor circuits based upon exit node requirements
de/volunteer.wml       939) specified by the user) to gather data in a self-contained way, with
de/volunteer.wml       940) parameters easily configurable by the user.  Blossom is presently
de/volunteer.wml       941) implemented as a single Python script that interfaces with Tor using the
de/volunteer.wml       942) Controller interface and depends upon metadata about Tor nodes obtained
de/volunteer.wml       943) via external processes, such as a webpage indicating status of the nodes
de/volunteer.wml       944) plus publically available data from DNS, whois, etc.  This project has
de/volunteer.wml       945) two parts: (1) Determine which additional metadata may be useful and
de/volunteer.wml       946) rework Blossom so that it cleanly obtains the metadata on its own rather
de/volunteer.wml       947) than depend upon external scripts (this may, for example, involve
de/volunteer.wml       948) additional threads or inter-process communication), and (2) develop a
de/volunteer.wml       949) means by which the user can easily configure Blossom, starting with a
de/volunteer.wml       950) configuration file and possibly working up to a web configuration engine.
de/volunteer.wml       951) Knowledge of Tor and Python are important; knowledge of
de/volunteer.wml       952) TCP, interprocess communication, and Perl will also be helpful.  An
de/volunteer.wml       953) interest in network neutrality is important as well, since the
de/volunteer.wml       954) principles of evaluating and understanding internet inconsistency are at
de/volunteer.wml       955) the core of the Blossom effort.
de/volunteer.wml       956) </li>
de/volunteer.wml       957) 
de/volunteer.wml       958) <li>
de/volunteer.wml       959) <b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
de/volunteer.wml       960) <br />
de/volunteer.wml       961) Priority: <i>Low</i>
de/volunteer.wml       962) <br />
de/volunteer.wml       963) Effort Level: <i>Medium</i>
de/volunteer.wml       964) <br />
de/volunteer.wml       965) Skill Level: <i>Medium</i>
de/volunteer.wml       966) <br />
de/volunteer.wml       967) Likely Mentors: <i>Goodell</i>
de/volunteer.wml       968) <br />
de/volunteer.wml       969) Develop and implement a means of affording Blossom
de/volunteer.wml       970) users the ability to qualitatively describe the exit node that they
de/volunteer.wml       971) want.  The Internet is an inconsistent place: some Tor exit nodes see
de/volunteer.wml       972) the world differently than others.  As presently implemented, Blossom (a
de/volunteer.wml       973) tool for monitoring and selecting appropriate Tor circuits based upon
de/volunteer.wml       974) exit node requirements specified by the user) lacks a sufficiently rich
de/volunteer.wml       975) language to describe how the different vantage points are different.
de/volunteer.wml       976) For example, some exit nodes may have an upstream network that filters
de/volunteer.wml       977) certain kinds of traffic or certain websites.  Other exit nodes may
de/volunteer.wml       978) provide access to special content as a result of their location, perhaps
de/volunteer.wml       979) as a result of discrimination on the part of the content providers
de/volunteer.wml       980) themselves.  This project has two parts: (1) develop a language for
de/volunteer.wml       981) describing characteristics of networks in which exit nodes reside, and
de/volunteer.wml       982) (2) incorporate this language into Blossom so that users can select Tor
de/volunteer.wml       983) paths based upon the description.
de/volunteer.wml       984) Knowledge of Tor and Python are important; knowledge of
de/volunteer.wml       985) TCP, interprocess communication, and Perl will also be helpful.  An
de/volunteer.wml       986) interest in network neutrality is important as well, since the
de/volunteer.wml       987) principles of evaluating and understanding internet inconsistency are at
de/volunteer.wml       988) the core of the Blossom effort.
de/volunteer.wml       989) </li>
de/volunteer.wml       990) 
de/volunteer.wml       991) <li>
de/volunteer.wml       992) <b>Bring up new ideas!</b>
de/volunteer.wml       993) <br />
de/volunteer.wml       994) Don't like any of these? Look at the <a
de/volunteer.wml       995) href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
de/volunteer.wml       996) roadmap</a> for more ideas.
de/volunteer.wml       997) </li>
de/volunteer.wml       998) 
de/volunteer.wml       999) </ol>
de/volunteer.wml      1000) 

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

de/volunteer.de.html  1002) 
de/volunteer.de.html  1003) <ol>

de/volunteer.wml      1004)   <li>Torserver funktionieren unter Windows XP nicht sehr gut. Wir
de/volunteer.wml      1005)   verwenden auf Windows den standardm��igen <code>select</code>-Systemaufruf.
de/volunteer.wml      1006)   Dies bereitet gerade auf mittelgro�en Servern <a

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

de/volunteer.wml      1008)   Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine L�sung
de/volunteer.wml      1009)   w�re, <a href="http://www.monkey.org/~provos/libevent/">libevent</a>
de/volunteer.wml      1010)   beizubringen, Overlapped I/O statt <code>select()</code> zu w�hlen. Tor muss
de/volunteer.wml      1011)   dann an die neue libevent-Schnittstelle angepasst werden. Christian King hat
de/volunteer.wml      1012)   <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">einen guten
de/volunteer.wml      1013)   Anfang</a> gemacht.</li>
de/volunteer.wml      1014)   <li>Wie k�nnen wir die <a
de/volunteer.wml      1015)   href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> leichter
de/volunteer.wml      1016)   zu warten, verbessern und zu dokumentieren machen?</li>

de/volunteer.wml      1017)   <li>Wir sollten damit anfangen unser <a href="<page
de/volunteer.wml      1018)   documentation>#DesignDoc">gegen Blockierungen gesch�tztes Design</a> zu
de/volunteer.wml      1019)   implementieren. Dies beinhaltet die Ausarbeitung des Designs, die
de/volunteer.wml      1020)   Modifizierung diverser Teile von Tor, die Arbeit an einer <a
de/volunteer.wml      1021)   href="http://vidalia-project.net/">GUI</a>, die intuitiv ist und die Planung
de/volunteer.wml      1022)   f�r den Einsatz.</li>
de/volunteer.wml      1023)   <li>Wir brauchen ein flexibles Ger�st, um Ende-zu-Ende Attacken des
de/volunteer.wml      1024)   Netzverkehrs zu simulieren. Viele Forscher haben Simulatoren geschaffen, die
de/volunteer.wml      1025)   ihre Intuition, ob ein Angriff oder Verteidigung funktioniert, unterst�tzt.
de/volunteer.wml      1026)   K�nnen wir einen Simulator bauen, der offen und gut dokumentiert ist? Dies
de/volunteer.wml      1027)   wird eine Menge neuer Forschung anregen. Schaue auch auf den <a

de/volunteer.wml      1028)   href="#Research">Eintrag unten</a>, um Details zu dieser Aufgabe zu entdecken.
de/volunteer.wml      1029)   Wenn es fertig ist, k�nntest du helfen, eine Ver�ffentlichung  dazu zu schreiben.</li>

de/volunteer.wml      1030)   <li>Momentan werden die Deskriptoren der versteckten Services nur
de/volunteer.wml      1031)   auf einigen wenigen Verzeichnisservern gespeichert. Dies ist
de/volunteer.wml      1032)   schlecht f�r die Privatsph�re und die Robustheit. Um mehr Robustheit
de/volunteer.wml      1033)   zu erlangen, sollten wir die privaten Daten aus den Deskriptoren
de/volunteer.wml      1034)   entfernen, um diese auf verschiedenen Pl�tzen spiegeln zu
de/volunteer.wml      1035)   k�nnen. Idealerweise h�tten wir gern ein Speicher-/Backupsystem, das
de/volunteer.wml      1036)   verschieden zu den Verzeichnisservern ist. Das erste Problem ist,
de/volunteer.wml      1037)   das wir Format f�r die versteckten Services schaffen m�ssen, welches
de/volunteer.wml      1038)   a) ASCII statt bin�r ist, b) die Liste der Introductionpoints
de/volunteer.wml      1039)   verschl�sselt, solange man nicht die <tt>.onion</tt>-Adresse kennt
de/volunteer.wml      1040)   und c) den Verzeichnissen erlaubt, den Zeitstempel und die Signatur
de/volunteer.wml      1041)   eines Deskriptors zu verifizieren, so dass diese nicht mit falschen
de/volunteer.wml      1042)   �berrumpelt werden. Zweitens wird es jedes verteilte Speichersystem
de/volunteer.wml      1043)   tun, solange es authentifizierte Updates erlaubt.</li>

de/volunteer.de.html  1044)   <li>Torversionen ab 0.1.1.x unterst�tzen Cryptohardwarebeschleuniger
de/volunteer.de.html  1045)     via OpenSSL. Bisher hat das niemand getestet. M�chte jemand gern
de/volunteer.de.html  1046)     eine Karte haben und schauen, ob das funktioniert?</li>
de/volunteer.de.html  1047)   <li>Eine Sicherheitsanalyse mit
de/volunteer.de.html  1048)     "<a href="http://en.wikipedia.org/wiki/Fuzz_testing">Fuzz</a>"
de/volunteer.de.html  1049)     machen.  Herausfinden, ob es da drau�en gute Bibliotheken daf�r
de/volunteer.de.html  1050)     gibt. Gewinne Ruhm und Ehre, wenn wir nur wegen dir ein neues
de/volunteer.de.html  1051)     Release herausbringen!</li>
de/volunteer.de.html  1052)   <li>Tor nutzt TCP f�r den Transport und TLS f�r die Verschl�sselung
de/volunteer.de.html  1053)     der Verbindungen. Dies ist einfach. Es bedeutet aber auch, dass
de/volunteer.de.html  1054)     alle Zellen Versp�tungen erfahren, wenn nur ein Paket verworfen
de/volunteer.de.html  1055)     wird. Daher k�nnen wir nur bedingt TCP-Streams unterst�tzen. Es
de/volunteer.de.html  1056)     gibt eine <a

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

de/volunteer.de.html  1058)     von Gr�nden</a>, warum wir nicht zu Transport per UDP gewechselt

de/volunteer.wml      1059)     sind. Es w�re sch�n, wenn diese Liste k�rzer werden w�rde. Wir
de/volunteer.wml      1060)   haben auch eine <a

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

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

de/volunteer.de.html  1064)   <li>Wir sind nicht weit davon entfernt, Unterst�tzung f�r IPv6 bei
de/volunteer.de.html  1065)     Exitknoten zu haben. Falls du dich stark um IPv6 k�mmerst, ist
de/volunteer.de.html  1066)     das wahrscheinlich der Platz, um zu starten.</li>

de/volunteer.wml      1067)   <li>Du magst keinen von den obigen Punkten? Schaue dir die <a
de/volunteer.wml      1068)   href="<svnsandbox>doc/design-paper/roadmap-future.pdf">weiteren Pl�ne</a> f�r
de/volunteer.wml      1069)   weitere Ideen an.</li>

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

de/contribute.de.html 1071) 

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

de/volunteer.de.html  1074) 

de/volunteer.de.html  1075) <ol>
de/volunteer.de.html  1076)   <li>Die Fingerprintattacken gegen Webseiten machen eine Liste von
de/volunteer.de.html  1077)     einigen wenigen popul�ren Webseiten, laden die Inhalte herunter
de/volunteer.de.html  1078)     und machen einen Satz von Signaturen f�r jede Seite. Danach

de/volunteer.wml      1079)     beobachten sie den Verkehr des Torclients. W�hrenddessen gelangen sie

de/volunteer.de.html  1080)     schnell zu einer Vermutung, welche Seite gerade besucht wird. Wie
de/volunteer.de.html  1081)     effektiv ist dieser Angriff bez�glich der aktuellen Codebasis von
de/volunteer.de.html  1082)     Tor? Beginne danach Verteidigungsm�glichkeiten auszuloten. Wir
de/volunteer.de.html  1083)     k�nnten beispielsweise die Zellgr��e von 512 Bytes auf 1024 Bytes
de/volunteer.de.html  1084)     anheben und Techniken wie <a
de/volunteer.de.html  1085)     href="http://freehaven.net/anonbib/#timing-fc2004">defensives
de/volunteer.de.html  1086)     Verwerfen</a> anwenden. Wir k�nnten auch k�nstliche Versp�tungen
de/volunteer.de.html  1087)     einarbeiten. Welchen Einfluss haben diese Massnahmen und wie gro�
de/volunteer.de.html  1088)     ist der Einfluss auf die Benutzbarkeit?</li>
de/volunteer.de.html  1089)   <li>Eine weitere Angriffsm�glichkeit (end-to-end traffic

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

de/volunteer.de.html  1091)     Alice und Bob beobachtet wird. Durch den <a
de/volunteer.de.html  1092)     href="http://freehaven.net/anonbib/#danezis:pet2004">Vergleich
de/volunteer.de.html  1093)     der Signaturen des Netzverkehrs kann man herausfinden, on man
de/volunteer.de.html  1094)     denselben Stream verfolgt</a>. Bis jetzt akzeptiert Tor dies als
de/volunteer.de.html  1095)     Fakt und nimmt an, dass dies in allen F�llen trivial ist. Ist das
de/volunteer.de.html  1096)     wahr? Wieviel Verkehr von welcher Sorte braucht man, um sicher zu
de/volunteer.de.html  1097)     sicher, dass es funktioniert? Gibt es Szenarien, die die Attacke
de/volunteer.de.html  1098)     ausbremsen? Funktioniert Padding besser als anderes?</li>

de/volunteer.wml      1099)     <li>Eine verwandte Frage: Bringt der Betrieb eines Relays oder
de/volunteer.wml      1100)   eines Br�ckenservers zus�tzlichen Schutz gegen Timingangriffe? Kann
de/volunteer.wml      1101)   ein externer Angreifer individuelle Str�me erkennen, obwohl er nicht
de/volunteer.wml      1102)   in die TLS-Str�me sehen kann? Hat die H�he des durchgeleiteten
de/volunteer.wml      1103)   Verkehrs Einfluss? Was w�re, wenn der Client anderen Verkehr
de/volunteer.wml      1104)   verlangsamt, um es so aussehen zu lassen, dass er auch
de/volunteer.wml      1105)   weitergeleitet wird? Die selbe Queue k�nnte auch zur Maskierung der
de/volunteer.wml      1106)   Timings mit Techniken von <a
de/volunteer.wml      1107)   href="http://www.freehaven.net/anonbib/#ShWa-Timing06" >adaptivem
de/volunteer.wml      1108)   Padding</a> genutzt werden, aber ohne zus�tzlich Traffic zu
de/volunteer.wml      1109)   erzeugen. W�rde das das Timing f�r externe Angreifer verschleiern?
de/volunteer.wml      1110)   M�ssten die Strategien f�r assymetrische Knoten angepasst werden?
de/volunteer.wml      1111)   W�re es dort beispielsweise m�glich, den Clienttraffic von anderem
de/volunteer.wml      1112)   zu unterscheiden? Oder ist das vielleicht f�r symmetrische
de/volunteer.wml      1113)   Verbindungen leichter?</li>
de/volunteer.wml      1114)   <li>Wiederhole die <a
de/volunteer.wml      1115)   href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta"
de/volunteer.wml      1116)   >Angriffe von Murdoch und Danezis von der Oakland 05</a> im
de/volunteer.wml      1117)   aktuellen Tor-Netzwerk. Schaue, ob du herausfinden kannst, warum das
de/volunteer.wml      1118)   bei einigen gut und bei anderen schlecht funktioniert. (Meine
de/volunteer.wml      1119)   Theorie ist, dass schnelle Knoten mit Restkapazit�t dem Angriff
de/volunteer.wml      1120)   besser widerstehen.) Wenn das wahr ist, experimentiere mit
de/volunteer.wml      1121)   <var>RelayBandwidthRate</var> und
de/volunteer.wml      1122)   <var>RelayBandwidthBurst</var>. Dabei betreibst du ein Relay,
de/volunteer.wml      1123)   welches als Client genutzt wird, um den Verkehr des Angreifers
de/volunteer.wml      1124)   weiterzuleiten. Was ist das richtige Verh�ltnis von
de/volunteer.wml      1125)   <var>RelayBandwidthRate</var> zu aktueller Kapazit�t? Gibt es
de/volunteer.wml      1126)   �berhaupt ein Verh�ltnis? Wenn wir dabei sind, erh�ht eine gro�e
de/volunteer.wml      1127)   Zahl von Relays die Fehlerrate des Angriffs? (Das Tor-Netzwerk ist
de/volunteer.wml      1128)   nun fast zwei Gr��enordnungen gewachsen, seit die Ver�ffentlichung
de/volunteer.wml      1129)   geschrieben wurde.) Lies auf jeden Fall auch <a
de/volunteer.wml      1130)   href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the
de/volunteer.wml      1131)   Queue</a>.</li>

de/volunteer.de.html  1132)   <li>Die Attacke auf die Routingzonen ist der Netzpfad zwischen
de/volunteer.de.html  1133)     Alice und dem Eingangsknoten (bzw. zwischen dem Exitknoten und
de/volunteer.de.html  1134)     Bob). In der Literatur wird dies als einfache Verbindung auf
de/volunteer.de.html  1135)     einem Graph dargestellt. In der Praxis durchquert der Pfad viele
de/volunteer.de.html  1136)     autonome Systeme. Es ist nicht ungew�hnlich, dass dasselbe
de/volunteer.de.html  1137)     <a href="http://freehaven.net/anonbib/#feamster:wpes2004">autonome
de/volunteer.de.html  1138)     System sowohl beim Eingangs- wie auch beim Ausgangspfad
de/volunteer.de.html  1139)     erscheint</a>. Um nun herauszufinden, ob ein spezielles Alice-,
de/volunteer.de.html  1140)     Eingangs-, Ausgangs-, Bobviereck gef�hrlich ist, m�ssten wir die

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

de/volunteer.de.html  1142)     darauf ausf�hren. Gibt es praktische Absch�tzungen, die die
de/volunteer.de.html  1143)     Arbeit erleichtern k�nnen?</li>

de/volunteer.wml      1144)     <li>Andere Fragen in der Forschung, die die geografische
de/volunteer.wml      1145)     Verteilung betreffen, betrachten einen Kompromiss zwischen der Wahl
de/volunteer.wml      1146)     einer effizienten Route und einer zuf�lligen Route. Wirf einen Blick
de/volunteer.wml      1147)     auf das <a
de/volunteer.wml      1148)     href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">Positionspapier</a>
de/volunteer.wml      1149)     von Stephen Rollyson. Es diskutiert, wie man langsame Leitungen
de/volunteer.wml      1150)     auschalten kann, ohne die Anonymit�t zu stark einzuschr�nken. Die
de/volunteer.wml      1151)     Begr�ndungen machen einen guten Eindruck, brauchen aber noch mehr
de/volunteer.wml      1152)     Arbeit.</li>

de/volunteer.de.html  1153)   <li>Tor funktioniert nicht sehr gut, wenn Server eine asymmetrische
de/volunteer.de.html  1154)     Bandbreite (Kabel oder DSL) haben. Tor hat separate
de/volunteer.de.html  1155)     TCP-Verbindungen zwischen jedem Hop. Wenn nun die einkommenden
de/volunteer.de.html  1156)     Pakete gut ankommen und die ausgehenden alle verworfen werden,
de/volunteer.de.html  1157)     �bertragen die die TCP-Pushback-Mechanismen diese Informationen
de/volunteer.de.html  1158)     nicht gut hin zu den eingehenden Verbindungen. Eventuell sollte
de/volunteer.de.html  1159)     Tor feststellen, wenn eine Menge an ausgehenden Verbindungen
de/volunteer.de.html  1160)     verworfen werden und dann die eigehenden Verbindungen selbst
de/volunteer.de.html  1161)     herunterregeln? Ich k�nnte mir ein Schema vorstellen, wo wir ein
de/volunteer.de.html  1162)     konservatives Ratelimit suchen und das langsam vergr��ern, bis
de/volunteer.de.html  1163)     Pakete verworfen werden. Wir brauchen jemanden, der sich gut mit
de/volunteer.de.html  1164)     Netzwerken auskennt, um dies zu simulieren und eine L�sung zu
de/volunteer.de.html  1165)     finden. Wir m�ssen die Erosion in der Performance verstehen und
de/volunteer.de.html  1166)     das als Motivation f�r Transport per UDP verstehen.</li>
de/volunteer.de.html  1167)   <li>Ein verwandtes Thema ist die Kontrolle bei Netz�berlastung. Ist
de/volunteer.de.html  1168)     unser Design ausreichend, um hohe Netzlast auszuhalten?
de/volunteer.de.html  1169)     Vielleicht sollten wir mit Fenstern von variabler Gr��e
de/volunteer.de.html  1170)     experimentieren? Das schien im <a
de/volunteer.de.html  1171)     href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">Experiment
de/volunteer.de.html  1172)     mit dem SSH-Durchsatz</a> gut zu funktionieren. Wir m�ssen das
de/volunteer.de.html  1173)     messen und verbessern und bei guten Resultaten Tor �berholen.</li>
de/volunteer.de.html  1174)   <li>Damit Dissidenden in fernen L�ndern Tor nutzen k�nnen, ohne von
de/volunteer.de.html  1175)     der Firewall des Landes geblockt zu werden, brauchen wir einen
de/volunteer.de.html  1176)     Weg, um zehntausende von Relays zu bekommen anstatt nur einigen

de/volunteer.wml      1177)     hundert. Wir k�nnen uns eine GUI vorstellen, die einen "Tor for
de/volunteer.wml      1178)     Freedom"-Button (Tor f�r die Freiheit) hat. Dieser �ffnet einen
de/volunteer.wml      1179)     Port und verteilt ein paar

de/volunteer.de.html  1180)     Kilobyte Traffic ins Tornetzwerk. Wie verteilen wir eine Liste
de/volunteer.de.html  1181)     dieser Freiwilligen in einer automatischen Art und Weise? Dies
de/volunteer.de.html  1182)     muss so passieren, dass die Firewalls auf Landesebene diese nicht
de/volunteer.de.html  1183)     erkennen. Wahrscheinlich muss das auf einem Niveau pers�nlichen

de/volunteer.wml      1184)     Vertrauens funktionieren. Siehe unseren <a href="<page
de/volunteer.wml      1185)   documentation>#DesignDoc">Designdokument hierzu</a> sowie den <a

de/volunteer.wml      1186)     href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance"

de/volunteer.wml      1187)     >Eintrag in der FAQ</a> und lies dann <a
de/volunteer.wml      1188)     href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship"

de/volunteer.wml      1189)     >die Zensurwiderstandssektion der AnonBib</a>.

de/volunteer.wml      1190)     </li>

de/volunteer.wml      1191)     <li>Unsere Ziele zum Schutz vor Zensur schlie�en ein, dass ein
de/volunteer.wml      1192)   Angreifer Tor-Verkehr von <a
de/volunteer.wml      1193)   href="https://www.torproject.org/svn/trunk/doc/design-paper/blocking.html#sec:network-fingerprint">normalem
de/volunteer.wml      1194)   SSL-Verkehr unterscheiden</a> kann. Offensichtlich k�nnen wir keine
de/volunteer.wml      1195)   perfekte Steganographie erreichen und dabei benutzbar bleiben. Aber
de/volunteer.wml      1196)   wir m�chten gern Angriffen, die nur wenige Pakete betrachten,
de/volunteer.wml      1197)   �berwinden. Eine der verbliebenen Angriffe, die wir nicht sehr gepr�ft
de/volunteer.wml      1198)   haben, ist das Verh�ltnis von der Gr��e der Tor-Zellen (512 Byte)
de/volunteer.wml      1199)   zum restlichen Verkehr. Wieviel erkennt man davon, haben die
de/volunteer.wml      1200)   Leerungsmechanismen der Buffer einen Einfluss, k�nnte Padding helfen?</li>

de/volunteer.wml      1201)   <li>Tor-Verbindungen werden schrittweise aufgebaut, ein Knoten nach
de/volunteer.wml      1202)     dem anderen.  Also haben wir theoretisch die M�glichkeit, manche
de/volunteer.wml      1203)     Str�me schon nach dem zweiten Knoten die Tor-Wolke verlassen zu
de/volunteer.wml      1204)     lassen, andere nach dem dritten Knoten, und so weiter.  Dies erscheint
de/volunteer.wml      1205)     nett, weil es die Menge der austretenden Str�me, welcher ein bestimmter
de/volunteer.wml      1206)     Server sieht, begrenzt.  Wenn wir diesen Strom jedoch sicher haben wollen,
de/volunteer.wml      1207)     dann, laut unserer aktuellen Logik,  sollte der k�rzeste Pfad mindestens 3
de/volunteer.wml      1208)     Knoten lang sein.  Das heisst, die anderen Str�me w�ren noch l�nger.  Wir
de/volunteer.wml      1209)     m�ssen diese Performance/Sicherheitsabw�gung untersuchen.</li>
de/volunteer.wml      1210)    <li>Es ist nicht schwer, DoS Angriffe auf Tor-Server oder
de/volunteer.wml      1211)     Tor-Verzeischnisserver erfolgreich durchzuf�hren.  Sind Client-Puzzles die
de/volunteer.wml      1212)     richtige Anwort?  Welche anderen praktischen Herangehensweisen gibt es?
de/volunteer.wml      1213)     Bonuspunkte, wenn diese mit dem aktuellen Tor-Protokoll abw�rtskompatibel
de/volunteer.wml      1214)     sind.</li>

de/volunteer.wml      1215)     <li>Programme, wie <a
de/volunteer.wml      1216)   href="https://torbutton.torproject.org/dev/">Torbutton</a>,
de/volunteer.wml      1217)   versuchen den User-Agent des Browsers zu verstecken, indem sie
de/volunteer.wml      1218)   diesen durch eine gew�hnliche Angabe ersetzen. Dadurch kann ein
de/volunteer.wml      1219)   Angreifer Tor-Nutzer nicht durch einen Blick auf die
de/volunteer.wml      1220)   Nachrichtenk�pfe erkennen. Die Software versucht einen, allgemein
de/volunteer.wml      1221)   genutzten Wert zu nehmen. Frage 1: Wie sehr schaden wir uns, wenn
de/volunteer.wml      1222)   wir die Firefox-Version periodisch anpassen? Wenn wir zu oft
de/volunteer.wml      1223)   updaten, kann man es unterscheiden. Machen wir es nicht, findet man
de/volunteer.wml      1224)   Tor-Nutzer heraus, da sie sehr alte Versionen nutzen. Die Antwort
de/volunteer.wml      1225)   h�ngt wahrscheinlich von den Firefox-Versionen, die es gibt,
de/volunteer.wml      1226)   ab. Frage 2: Die Leute fragen immer wieder, zwischen n verschiedenen
de/volunteer.wml      1227)   User-Agents zu wechseln. Hilft der Ansatz oder macht das keinen
de/volunteer.wml      1228)   Unterschied? Betrachte dabei Cookies und Tor-Nutzer, die periodisch
de/volunteer.wml      1229)   den User-Agent wechseln. B�sartige Webseiten greifen nur bestimmte
de/volunteer.wml      1230)   Browser an. Wie beeinflussen die Antworten auf diese Fragen diese
de/volunteer.wml      1231)   Antwort.</li>

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

de/contribute.de.html 1233) 

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

de/contribute.de.html 1236) 
de/contribute.de.html 1237) </div><!-- #main -->