tor-webwml.git

en/volunteer.wml   1) ## translation metadata

en/volunteer.wml   2) # Revision: $Revision$

en/volunteer.wml   3) # Translation-Priority: 4-optional

volunteer.html     4) 

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

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

en/volunteer.wml  10) <h2>A few things everyone can do now:</h2>

volunteer.html    11) <ol>

en/volunteer.wml  12) <li>Please consider <a href="<page docs/tor-doc-relay>">running
en/volunteer.wml  13) a relay</a> to help the Tor network grow.</li>
en/volunteer.wml  14) <li>Tell your friends! Get them to run relays. Get them to run hidden

volunteer.html    15) services. Get them to tell their friends.</li>

en/volunteer.wml  16) <li>If you like Tor's goals, please <a href="<page donate>">take a moment
en/volunteer.wml  17) to donate to support further Tor development</a>. We're also looking
en/volunteer.wml  18) for more sponsors &mdash; if you know any companies, NGOs, agencies,
en/volunteer.wml  19) or other organizations that want anonymity / privacy / communications
en/volunteer.wml  20) security, let them know about us.</li>
en/volunteer.wml  21) <li>We're looking for more <a href="<page torusers>">good examples of Tor
en/volunteer.wml  22) users and Tor use cases</a>. If you use Tor for a scenario or purpose not
en/volunteer.wml  23) yet described on that page, and you're comfortable sharing it with us,
en/volunteer.wml  24) we'd love to hear from you.</li>

volunteer.html    25) </ol>
volunteer.html    26) 

en/volunteer.wml  27) <p>Tor has <a href="<page open-positions>">two open positions</a>.
en/volunteer.wml  28) Please <a href="<page contact>">contact us</a> if you are qualified!</p>

en/volunteer.wml  29) 

en/volunteer.wml  30) <a id="Documentation"></a>
en/volunteer.wml  31) <h2><a class="anchor" href="#Documentation">Documentation</a></h2>

volunteer.html    32) <ol>

en/volunteer.wml  33) <li>Help translate the web page and documentation into other
en/volunteer.wml  34) languages. See the <a href="<page translation>">translation
en/volunteer.wml  35) guidelines</a> if you want to help out. We especially need Arabic or
en/volunteer.wml  36) Farsi translations, for the many Tor users in censored areas.</li>
en/volunteer.wml  37) <li>Evaluate and document

en/volunteer.wml  38) <a href="<wiki>TorifyHOWTO">our

en/volunteer.wml  39) list of programs</a> that can be configured to use Tor.</li>

en/volunteer.wml  40) <li>We have a huge list of <a

en/volunteer.wml  41) href="<wiki>SupportPrograms">potentially useful

en/volunteer.wml  42) programs that interface to Tor</a>. Which ones are useful in which
en/volunteer.wml  43) situations? Please help us test them out and document your results.</li>

volunteer.html    44) </ol>
volunteer.html    45) 

en/volunteer.wml  46) <a id="Advocacy"></a>

en/volunteer.wml  47) <h2><a class="anchor" href="#Advocacy">Advocacy</a></h2>
en/volunteer.wml  48) <ol>

en/volunteer.wml  49) <li>Create a <a href="https://trac.torproject.org/projects/tor/wiki/CommunityLogos">community logo</a> under a Creative Commons license that all can use and modify</li>

en/volunteer.wml  50) <li>Create a presentation that can be used for various user group meetings around the world</li>

en/volunteer.wml  51) <li>Create a video about the positive uses of Tor, what Tor is, or how
en/volunteer.wml  52) to use it.  Some have already

en/volunteer.wml  53) started on <a href="http://media.torproject.org/video/">Tor's Media

en/volunteer.wml  54) server</a>, <a
en/volunteer.wml  55) href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>,

en/volunteer.wml  56) and <a href="http://www.youtube.com/thetorproject">Youtube</a>.</li> 

en/volunteer.wml  57) <li>Create a poster, or a set of posters, around a theme,
en/volunteer.wml  58) such as "Tor for Freedom!"</li>

en/volunteer.wml  59) </ol>
en/volunteer.wml  60) 

en/volunteer.wml  61) <a id="Coding"></a>

en/volunteer.wml  62) <a id="Summer"></a>
en/volunteer.wml  63) <a id="Projects"></a>

en/volunteer.wml  64) <h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>

en/volunteer.wml  65) 
en/volunteer.wml  66) <p>

en/volunteer.wml  67) You may find some of these projects to be good <a href="<page

en/volunteer.wml  68) gsoc>">Google Summer of Code 2010</a> ideas. We have labelled each idea

en/volunteer.wml  69) with how useful it would be to the overall Tor project (priority), how
en/volunteer.wml  70) much work we expect it would be (effort level), how much clue you should
en/volunteer.wml  71) start with (skill level), and which of our <a href="<page
en/volunteer.wml  72) people>#Core">core developers</a> would be good mentors.
en/volunteer.wml  73) If one or more of these ideas looks promising to you, please <a
en/volunteer.wml  74) href="<page contact>">contact us</a> to discuss your plans rather than
en/volunteer.wml  75) sending blind applications. You may also want to propose your own project

en/volunteer.wml  76) idea — which often results in the best applications.

en/volunteer.wml  77) </p>
en/volunteer.wml  78) 

en/volunteer.wml  79) <ol>
en/volunteer.wml  80) 

en/volunteer.wml  81) <li>

en/volunteer.wml  82) <b>Tor Browser Bundle for Mac OS X</b>

en/volunteer.wml  83) <br />

en/volunteer.wml  84) Priority: <i>High</i>

en/volunteer.wml  85) <br />

en/volunteer.wml  86) Effort Level: <i>High</i>
en/volunteer.wml  87) <br />
en/volunteer.wml  88) Skill Level: <i>Medium</i>
en/volunteer.wml  89) <br />

en/volunteer.wml  90) Likely Mentors: <i>Steven, Erinn, Jacob, Andrew</i>

en/volunteer.wml  91) <br />

en/volunteer.wml  92) The Tor Browser Bundle incorporates Tor, Firefox, Polipo, and the Vidalia
en/volunteer.wml  93) user interface (and optionally the <a href="http://pidgin.im/">Pidgin</a>
en/volunteer.wml  94) Instant Messaging client). Components are pre-configured to operate in a
en/volunteer.wml  95) secure way, and it has very few dependencies on the installed operating
en/volunteer.wml  96) system. It has therefore become one of the most easy to use, and popular,
en/volunteer.wml  97) ways to use Tor on Windows.

en/volunteer.wml  98) <br />

en/volunteer.wml  99) However, there is currently no released package for Mac OS X, so this project
en/volunteer.wml 100) would be to implement Tor Browser Bundle for OS X. This will involve
en/volunteer.wml 101) modifications to Vidalia (C++), possibly Firefox (C) then creating and testing
en/volunteer.wml 102) the launcher on a range of operating system versions and configurations to
en/volunteer.wml 103) verify portability.  Some work on this was completed as part of the Google
en/volunteer.wml 104) Summer of Code 2009. Another part of this project is to identify all of the
en/volunteer.wml 105) traces left behind by using a Tor Browser Bundle on Mac OS X or Linux.
en/volunteer.wml 106) Developing ways to stop, counter, or remove these traces is a final step.

en/volunteer.wml 107) <br />
en/volunteer.wml 108) Students should be familiar with application development on one or
en/volunteer.wml 109) preferably both of Linux and Mac OS X, and be comfortable with C/C++
en/volunteer.wml 110) and shell scripting.
en/volunteer.wml 111) <br />
en/volunteer.wml 112) Part of this project could be usability testing of Tor Browser Bundle,

en/volunteer.wml 113) ideally amongst our target demographic.  That would help a lot in knowing
en/volunteer.wml 114) what needs to be done in terms of bug fixes or new features. We get this
en/volunteer.wml 115) informally at the moment, but a more structured process would be better.

en/volunteer.wml 116) <br />
en/volunteer.wml 117) A beta version of the Tor Browser Bundle has been released for GNU/Linux, but
en/volunteer.wml 118) work is still required for the Tor IM Browser bundle. Work is currently being
en/volunteer.wml 119) done on the Mac OS X version as well. If you would like to help extend or do
en/volunteer.wml 120) security auditing for either (or both) of these, please contact Erinn.

en/volunteer.wml 121) </li>
en/volunteer.wml 122) 

en/volunteer.wml 123) <li>
en/volunteer.wml 124) <b>Help track the overall Tor Network status</b>

en/volunteer.wml 125) <br />

en/volunteer.wml 126) Priority: <i>Medium to High</i>
en/volunteer.wml 127) <br />
en/volunteer.wml 128) Effort Level: <i>Medium</i>
en/volunteer.wml 129) <br />
en/volunteer.wml 130) Skill Level: <i>Medium</i>
en/volunteer.wml 131) <br />

en/volunteer.wml 132) Likely Mentors: <i>Karsten, Roger</i>

en/volunteer.wml 133) <br />

en/volunteer.wml 134) It would be great to set up an automated system for tracking network
en/volunteer.wml 135) health over time, graphing it, etc. Part of this project would involve
en/volunteer.wml 136) inventing better metrics for assessing network health and growth. Is the
en/volunteer.wml 137) average uptime of the network increasing? How many relays are qualifying
en/volunteer.wml 138) for Guard status this month compared to last month? What's the turnover
en/volunteer.wml 139) in terms of new relays showing up and relays shutting off? Periodically
en/volunteer.wml 140) people collect brief snapshots, but where it gets really interesting is
en/volunteer.wml 141) when we start tracking data points over time.
en/volunteer.wml 142) <br />

en/volunteer.wml 143) Data could be collected from the Tor Network Scanners in <a
en/volunteer.wml 144) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, from

en/volunteer.wml 145) the server descriptors that each relay publishes, and from other
en/volunteer.wml 146) sources. Results over time could be integrated into one of the <a
en/volunteer.wml 147) href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be
en/volunteer.wml 148) kept separate. Speaking of the Tor Status pages, take a look at Roger's
en/volunteer.wml 149) <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
en/volunteer.wml 150) Status wish list</a>.
en/volunteer.wml 151) </li>
en/volunteer.wml 152) 

en/volunteer.wml 153) <li>
en/volunteer.wml 154) <b>Rewrite TorDNSEL, this time with a spec!</b>
en/volunteer.wml 155) <br />
en/volunteer.wml 156) Priority: <i>High</i>
en/volunteer.wml 157) <br />
en/volunteer.wml 158) Effort Level: <i>Medium</i>
en/volunteer.wml 159) <br />
en/volunteer.wml 160) Skill Level: <i>Medium</i>
en/volunteer.wml 161) <br />

en/volunteer.wml 162) Likely Mentors: <i>Mike, Roger, Sebastian, Damian</i>

en/volunteer.wml 163) <br />

en/volunteer.wml 164) The <a href="<page tordnsel/index>">Tor DNS Exit List</a> is an
en/volunteer.wml 165) unmaintained Haskell

en/volunteer.wml 166) program that serves three purposes. First, it provides an rbl-style DNS
en/volunteer.wml 167) interface for people to look up whether a given IP address is (or has
en/volunteer.wml 168) recently been) a Tor exit relay. Second, it actively builds circuits over
en/volunteer.wml 169) the Tor network and connects back to itself, to learn the actual exit
en/volunteer.wml 170) IP address of each relay — some Tor relays exit from a different
en/volunteer.wml 171) address than they advertise in their descriptor. Third, it exports a <a
en/volunteer.wml 172) href="http://exitlist.torproject.org/exitAddresses">set of conclusions</a>
en/volunteer.wml 173) so that <a href="https://check.torproject.org/">check.torproject.org</a>
en/volunteer.wml 174) can guess for you whether your browser is configured to point to Tor.
en/volunteer.wml 175) <br />
en/volunteer.wml 176) This project would make use of <a
en/volunteer.wml 177) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>,

en/volunteer.wml 178) a set of Python scripts to interact with Tor,

en/volunteer.wml 179) to figure out how our Tor Exit Checker should actually work, and then
en/volunteer.wml 180) build it — probably in Python since Torflow is in Python. The main
en/volunteer.wml 181) goal is to reduce false positives as much as possible, by making sure
en/volunteer.wml 182) that it learns about new relays as soon as possible, making sure that
en/volunteer.wml 183) the testing phase concludes quickly, and making sure the answers get
en/volunteer.wml 184) passed to the Check script quickly. As a bonus, we should standardize
en/volunteer.wml 185) (specify) the format of the exitAddresses file, and rewrite the <a
en/volunteer.wml 186) href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">Tor

en/volunteer.wml 187) Bulk Exit List</a> script to use that file rather than its current <a

en/volunteer.wml 188) href="https://trac.torproject.org/projects/tor/ticket/1019">horrible

en/volunteer.wml 189) DNS hacks</a>. As an extra bonus, we should work with Freenode, OFTC,
en/volunteer.wml 190) and/or other IRC networks to make sure that the scripts we offer are
en/volunteer.wml 191) actually the scripts they want, in terms of accurately identifying which
en/volunteer.wml 192) of their users are coming from the Tor network.

en/volunteer.wml 193) <br />
en/volunteer.wml 194) You can fetch the <a href="git://git.torproject.org/git/tordnsel">latest
en/volunteer.wml 195) tordnsel</a> via git.
en/volunteer.wml 196) </li>
en/volunteer.wml 197) 

en/volunteer.wml 198) <li>
en/volunteer.wml 199) <b>Improving Tor's ability to resist censorship</b>
en/volunteer.wml 200) <br />

en/volunteer.wml 201) Priority: <i>Medium to High</i>

en/volunteer.wml 202) <br />

en/volunteer.wml 203) Effort Level: <i>Medium to High</i>

en/volunteer.wml 204) <br />
en/volunteer.wml 205) Skill Level: <i>High</i>
en/volunteer.wml 206) <br />

en/volunteer.wml 207) Likely Mentors: <i>Roger, Nick, Steven</i>

en/volunteer.wml 208) <br />

en/volunteer.wml 209) The Tor 0.2.1.x series makes <a

en/volunteer.wml 210) href="<svnprojects>design-paper/blocking.html">significant

en/volunteer.wml 211) improvements</a> in resisting national and organizational censorship.
en/volunteer.wml 212) But Tor still needs better mechanisms for some parts of its

en/volunteer.wml 213) anti-censorship design.
en/volunteer.wml 214) <br />
en/volunteer.wml 215) One huge category of work is adding features to our <a
en/volunteer.wml 216) href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
en/volunteer.wml 217) service (Python). Tor aims to give out <a href="<page bridges>">bridge
en/volunteer.wml 218) relay addresses</a> to users that can't reach the Tor network
en/volunteer.wml 219) directly, but there's an arms race between algorithms for distributing
en/volunteer.wml 220) addresses and algorithms for gathering and blocking them. See <a

en/volunteer.wml 221) href="<blog>bridge-distribution-strategies">our

en/volunteer.wml 222) blog post on the topic</a> as an overview, and then look at <a
en/volunteer.wml 223) href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's
en/volunteer.wml 224) or-dev post</a> from December for more recent thoughts &mdash; lots of
en/volunteer.wml 225) design work remains.
en/volunteer.wml 226) <br />

en/volunteer.wml 227) If you want to get more into the guts of Tor itself (C), a more minor problem

en/volunteer.wml 228) we should address is that current Tors can only listen on a single
en/volunteer.wml 229) address/port combination at a time. There's

en/volunteer.wml 230) <a href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">a

en/volunteer.wml 231) proposal to address this limitation</a> and allow clients to connect
en/volunteer.wml 232) to any given Tor on multiple addresses and ports, but it needs more

en/volunteer.wml 233) work.
en/volunteer.wml 234) <br />

en/volunteer.wml 235) This project could involve a lot of research and design. One of the big

en/volunteer.wml 236) challenges will be identifying and crafting approaches that can still
en/volunteer.wml 237) resist an adversary even after the adversary knows the design, and
en/volunteer.wml 238) then trading off censorship resistance with usability and robustness.
en/volunteer.wml 239) </li>
en/volunteer.wml 240) 

en/volunteer.wml 241) <li>

en/volunteer.wml 242) <b>Tor Controller Status Event Interface for Vidalia</b>

en/volunteer.wml 243) <br />

en/volunteer.wml 244) Priority: <i>Medium</i>
en/volunteer.wml 245) <br />
en/volunteer.wml 246) Effort Level: <i>Medium</i>
en/volunteer.wml 247) <br />

en/volunteer.wml 248) Skill Level: <i>Low to Medium</i>

en/volunteer.wml 249) <br />
en/volunteer.wml 250) Likely Mentors: <i>Matt</i>
en/volunteer.wml 251) <br />

en/volunteer.wml 252) There are a number of status changes inside Tor of which the user may need

en/volunteer.wml 253) to be informed. For example, if the user is trying to set up his Tor as a
en/volunteer.wml 254) relay and Tor decides that its ports are not reachable from outside

en/volunteer.wml 255) the user's network, we should alert the user. Currently, all the user

en/volunteer.wml 256) gets is a couple log messages in Vidalia's 'message log' window, which they

en/volunteer.wml 257) likely never see since they don't receive a notification that something
en/volunteer.wml 258) has gone wrong. Even if the user does actually look at the message log,
en/volunteer.wml 259) most of the messages make little sense to the novice user.
en/volunteer.wml 260) <br />
en/volunteer.wml 261) Tor has the ability to inform Vidalia of many such status changes, and
en/volunteer.wml 262) we recently implemented support for a couple of these events. Still,
en/volunteer.wml 263) there are many more status events the user should be informed of and we
en/volunteer.wml 264) need a better UI for actually displaying them to the user.
en/volunteer.wml 265) <br />
en/volunteer.wml 266) The goal of this project then is to design and implement a UI for
en/volunteer.wml 267) displaying Tor status events to the user. For example, we might put a
en/volunteer.wml 268) little badge on Vidalia's tray icon that alerts the user to new status
en/volunteer.wml 269) events they should look at. Double-clicking the icon could bring up a
en/volunteer.wml 270) dialog that summarizes recent status events in simple terms and maybe

en/volunteer.wml 271) suggests a remedy for any negative events if they can be corrected by

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

en/volunteer.wml 273) suggest another approach.
en/volunteer.wml 274) <br />

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

en/volunteer.wml 276) and some C++ development experience. Previous experience with Qt and

en/volunteer.wml 277) Qt's Designer will be very helpful, but are not required. Some

en/volunteer.wml 278) English writing ability will also be useful, since this project will
en/volunteer.wml 279) likely involve writing small amounts of help documentation that should
en/volunteer.wml 280) be understandable by non-technical users. Bonus points for some graphic
en/volunteer.wml 281) design/Photoshop fu, since we might want/need some shiny new icons too.
en/volunteer.wml 282) </li>
en/volunteer.wml 283) 

en/volunteer.wml 284) <li>

en/volunteer.wml 285) <b>Improve our unit testing process</b>

en/volunteer.wml 286) <br />

en/volunteer.wml 287) Priority: <i>Medium</i>

en/volunteer.wml 288) <br />

en/volunteer.wml 289) Effort Level: <i>Medium</i>
en/volunteer.wml 290) <br />
en/volunteer.wml 291) Skill Level: <i>Medium</i>
en/volunteer.wml 292) <br />

en/volunteer.wml 293) Likely Mentors: <i>Nick, Erinn</i>

en/volunteer.wml 294) <br />
en/volunteer.wml 295) Tor needs to be far more tested. This is a multi-part effort. To start
en/volunteer.wml 296) with, our unit test coverage should rise substantially, especially in
en/volunteer.wml 297) the areas outside the utility functions. This will require significant
en/volunteer.wml 298) refactoring of some parts of Tor, in order to dissociate as much logic
en/volunteer.wml 299) as possible from globals.
en/volunteer.wml 300) <br />
en/volunteer.wml 301) Additionally, we need to automate our performance testing. We've got
en/volunteer.wml 302) buildbot to automate our regular integration and compile testing already
en/volunteer.wml 303) (though we need somebody to set it up on Windows),
en/volunteer.wml 304) but we need to get our network simulation tests (as built in <a
en/volunteer.wml 305) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
en/volunteer.wml 306) updated for more recent versions of Tor, and designed to launch a test
en/volunteer.wml 307) network either on a single machine, or across several, so we can test
en/volunteer.wml 308) changes in performance on machines in different roles automatically.
en/volunteer.wml 309) </li>
en/volunteer.wml 310) 
en/volunteer.wml 311) <li>

en/volunteer.wml 312) <b>Help with independent Tor client implementations</b>

en/volunteer.wml 313) <br />
en/volunteer.wml 314) Priority: <i>Medium</i>
en/volunteer.wml 315) <br />
en/volunteer.wml 316) Effort Level: <i>High</i>
en/volunteer.wml 317) <br />
en/volunteer.wml 318) Skill Level: <i>Medium to High</i>
en/volunteer.wml 319) <br />

en/volunteer.wml 320) Likely Mentors: <i>Bruce, Nathan</i>

en/volunteer.wml 321) <br />

en/volunteer.wml 322) Others are currently working on Tor clients for Java, Android, and Maemo

en/volunteer.wml 323) environments.  The first step is to get a handle on the current state of

en/volunteer.wml 324) the project in which you are interested in helping; <a

en/volunteer.wml 325) href="http://github.com/brl/JTor">Tor for Java</a>,
en/volunteer.wml 326) <a href="https://svn.torproject.org/svn/projects/android/trunk/">Android/Orbot</a>

en/volunteer.wml 327) , or <a href="<page docs/N900>">Tor for Maemo</a>. Check out the
en/volunteer.wml 328) repository and familiarize yourself

en/volunteer.wml 329) with the source code.  Further, support for requesting or even providing
en/volunteer.wml 330) Tor hidden services would be neat, but not required.

en/volunteer.wml 331) <br />
en/volunteer.wml 332) A prospective developer should be able to understand and write new Java

en/volunteer.wml 333) code, including a Java cryptography API. Being able to read C code would be helpful,

en/volunteer.wml 334) too. One should be willing to read the existing documentation,
en/volunteer.wml 335) implement code based on it, and refine the documentation
en/volunteer.wml 336) when things are underdocumented. This project is mostly about coding and
en/volunteer.wml 337) to a small degree about design.
en/volunteer.wml 338) </li>

en/volunteer.wml 339) <li>
en/volunteer.wml 340) <b>More on Orbot &amp; Android OS-specific development</b>
en/volunteer.wml 341) <br/>
en/volunteer.wml 342) <br />
en/volunteer.wml 343) Priority: <i>Medium</i>
en/volunteer.wml 344) <br />
en/volunteer.wml 345) Effort Level: <i>High</i>
en/volunteer.wml 346) <br />
en/volunteer.wml 347) Skill Level: <i>Medium to High</i>
en/volunteer.wml 348) <br />
en/volunteer.wml 349) Likely Mentors: <i>Nathan</i>
en/volunteer.wml 350) <br />
en/volunteer.wml 351) 
en/volunteer.wml 352) <b>Android Java UI work:</b> Improved home screen to show better statistics about data transferred (up/down), number of circuits connected, quality of connection and so on. The "Tether Wifi" Android application is a good model to follow in how it shows a realtime count of bytes transferred as well as notifications when wifi client connect. In addition, better display/handling of Tor system/error messages would also be very helpful. Finally, the addition of a wizard or tutorial walkthrough for novice users to explain to them exactly what or what is not anonymized or protected would greatly improve the likelihood they will use Orbot correctly.
en/volunteer.wml 353) <br/><br/>
en/volunteer.wml 354) 
en/volunteer.wml 355) <b>Android Java OS/Core app work:</b> Better system-wide indicator either via the notification bar, "Toast" pop-up dialogs or some other indicator that an application's traffic is indeed moving through Orbot/Tor. For instance, right now you need to first go to a torcheck web service to ensure your browser is routing via Tor. Orbot should be able to notify you that circuits are being opened, used, etc. The aforementioned data transfer tracker might provide this type of awareness as well.
en/volunteer.wml 356) 
en/volunteer.wml 357) <br/><br/>
en/volunteer.wml 358) <b>Android Java Library/Community Outreach work:</b> We need to package a simple library for use with third-party application to easily enable them to support "Torification" on non-root devices (aka w/o transparent proxying). This library should include a wrapper for the Apache HTTPClient library, a utility class for detecting the state of Orbot connectivity, and other relevant/useful things an Android app might need to anonymize itself. This work would include the creation of the library, documentation, and sample code. Outreach or effort to implement the library within other open-source apps would follow.
en/volunteer.wml 359) 
en/volunteer.wml 360) <br/><br/>
en/volunteer.wml 361) <b>Android OS/C/Linux work:</b> The port of Tor to Android is basically a straight cross-compile to Linux ARM. There has been no work done in looking the optimization of Tor within a mobile hardware environment, on the ARM processor or other Android hardware, or on mobile networks. It should be noted, that even without optimization, Tor is handling the mobile network environment very well, automatically detecting change in IP addresses, reconnecting circuits, etc across switching from 2G to 3G to Wifi, and so forth. 
en/volunteer.wml 362) </li>

en/volunteer.wml 363) 

en/volunteer.wml 364) <li>

en/volunteer.wml 365) <b>New Torbutton Features</b>
en/volunteer.wml 366) <br />
en/volunteer.wml 367) Priority: <i>Medium</i>
en/volunteer.wml 368) <br />
en/volunteer.wml 369) Effort Level: <i>High</i>
en/volunteer.wml 370) <br />
en/volunteer.wml 371) Skill Level: <i>High</i>
en/volunteer.wml 372) <br />
en/volunteer.wml 373) Likely Mentors: <i>Mike</i>
en/volunteer.wml 374) <br/>
en/volunteer.wml 375) There are several <a

en/volunteer.wml 376) href="https://trac.torproject.org/projects/tor/report/14">good
en/volunteer.wml 377) feature requests</a> on the Torbutton Trac section. In particular, <a
en/volunteer.wml 378) href="https://trac.torproject.org/projects/tor/ticket/523">Integrating

en/volunteer.wml 379) 'New Identity' with Vidalia</a>,

en/volunteer.wml 380) <a href="https://trac.torproject.org/projects/tor/ticket/940">ways of
en/volunteer.wml 381) managing multiple cookie jars/identities</a>, 
en/volunteer.wml 382) <a href="https://trac.torproject.org/projects/tor/ticket/637">preserving

en/volunteer.wml 383) specific cookies</a> when cookies are cleared,
en/volunteer.wml 384) <a

en/volunteer.wml 385) href="https://trac.torproject.org/projects/tor/ticket/524">better

en/volunteer.wml 386) referrer spoofing</a>, <a

en/volunteer.wml 387) href="https://trac.torproject.org/projects/tor/ticket/564">correct

en/volunteer.wml 388) Tor status reporting</a>, and <a

en/volunteer.wml 389) href="https://trac.torproject.org/projects/tor/ticket/462">"tor://"

en/volunteer.wml 390) and "tors://" urls</a> are all interesting
en/volunteer.wml 391) features that could be added.
en/volunteer.wml 392) <br />
en/volunteer.wml 393) This work would be independent coding in Javascript and the fun world of <a
en/volunteer.wml 394) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
en/volunteer.wml 395) with not too much involvement in the Tor internals.

en/volunteer.wml 396) </li>

en/volunteer.wml 397) 

en/volunteer.wml 398) <!-- <li>

en/volunteer.wml 399) <b>New Thandy Features</b>
en/volunteer.wml 400) <br />
en/volunteer.wml 401) Priority: <i>Medium</i>
en/volunteer.wml 402) <br />
en/volunteer.wml 403) Effort Level: <i>Medium</i>
en/volunteer.wml 404) <br />
en/volunteer.wml 405) Skill Level: <i>Medium to High</i>
en/volunteer.wml 406) <br />
en/volunteer.wml 407) Likely Mentors: <i>Martin</i>
en/volunteer.wml 408) <br />
en/volunteer.wml 409) Additional capabilities are needed for assisted updates of all the Tor
en/volunteer.wml 410) related software for Windows and other operating systems. Some of the
en/volunteer.wml 411) features to consider include:

en/volunteer.wml 412) <ol>
en/volunteer.wml 413) <li> Integration of the <a

en/volunteer.wml 414) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
en/volunteer.wml 415) Python library</a>

en/volunteer.wml 416) for authenticated HTTPS downloads.</li>
en/volunteer.wml 417) <li> Adding a level of indirection

en/volunteer.wml 418) between the timestamp signatures and the package files included in an

en/volunteer.wml 419) update. See the "Thandy attacks / suggestions" thread on or-dev.</li>
en/volunteer.wml 420) <li> Support locale specific installation and configuration of assisted

en/volunteer.wml 421) updates based on preference, host, or user account language settings.
en/volunteer.wml 422) Familiarity with Windows codepages, unicode, and other character sets
en/volunteer.wml 423) is helpful in addition to general win32 and posix API experience and

en/volunteer.wml 424) Python proficiency.</li>
en/volunteer.wml 425) </ol>

en/volunteer.wml 426) </li> -->

en/volunteer.wml 427) 
en/volunteer.wml 428) <li>
en/volunteer.wml 429) <b>Simulator for slow Internet connections</b>
en/volunteer.wml 430) <br />
en/volunteer.wml 431) Priority: <i>Medium</i>
en/volunteer.wml 432) <br />
en/volunteer.wml 433) Effort Level: <i>Medium</i>
en/volunteer.wml 434) <br />
en/volunteer.wml 435) Skill Level: <i>Medium</i>
en/volunteer.wml 436) <br />
en/volunteer.wml 437) Likely Mentors: <i>Steven</i>
en/volunteer.wml 438) <br />
en/volunteer.wml 439) Many users of Tor have poor-quality Internet connections, giving low
en/volunteer.wml 440) bandwidth, high latency, and high packet loss/re-ordering. User
en/volunteer.wml 441) experience is that Tor reacts badly to these conditions, but it is
en/volunteer.wml 442) difficult to improve the situation without being able to repeat the
en/volunteer.wml 443) problems in the lab.
en/volunteer.wml 444) <br />
en/volunteer.wml 445) This project would be to build a simulation environment which
en/volunteer.wml 446) replicates the poor connectivity so that the effect on Tor performance
en/volunteer.wml 447) can be measured. Other components would be a testing utility to
en/volunteer.wml 448) establish what are the properties of connections available, and to
en/volunteer.wml 449) measure the effect of performance-improving modifications to Tor.
en/volunteer.wml 450) <br />
en/volunteer.wml 451) The tools used would be up to the student, but dummynet (for FreeBSD)
en/volunteer.wml 452) and nistnet (for Linux) are two potential components on which this
en/volunteer.wml 453) project could be built. Students should be experienced with network
en/volunteer.wml 454) programming/debugging and TCP/IP, and preferably familiar with C and a
en/volunteer.wml 455) scripting language.
en/volunteer.wml 456) </li>
en/volunteer.wml 457) 
en/volunteer.wml 458) <li>
en/volunteer.wml 459) <b>An Improved and More Usable Network Map in Vidalia</b>
en/volunteer.wml 460) <br />
en/volunteer.wml 461) Priority: <i>Low to Medium</i>
en/volunteer.wml 462) <br />
en/volunteer.wml 463) Effort Level: <i>Medium</i>
en/volunteer.wml 464) <br />
en/volunteer.wml 465) Skill Level: <i>Medium</i>
en/volunteer.wml 466) <br />
en/volunteer.wml 467) Likely Mentors: <i>Matt</i>
en/volunteer.wml 468) <br />
en/volunteer.wml 469) One of Vidalia's existing features is a network map that shows the user
en/volunteer.wml 470) the approximate geographic location of relays in the Tor network and
en/volunteer.wml 471) plots the paths the user's traffic takes as it is tunneled through the
en/volunteer.wml 472) Tor network. The map is currently not very interactive and has rather
en/volunteer.wml 473) poor graphics. Instead, we implemented KDE's Marble widget such
en/volunteer.wml 474) that it gives us a better quality map and enables improved interactivity,
en/volunteer.wml 475) such as allowing the user to click on individual relays or circuits to
en/volunteer.wml 476) display additional information. We want to add the ability
en/volunteer.wml 477) for users to click on a particular relay or a country containing one or
en/volunteer.wml 478) more Tor exit relays and say, "I want my connections to exit
en/volunteer.wml 479) from here."
en/volunteer.wml 480) <br />
en/volunteer.wml 481) This project will first involve getting familiar with Vidalia
en/volunteer.wml 482) and the Marble widget's API. One will then integrate the widget
en/volunteer.wml 483) into Vidalia and customize Marble to be better suited for our application,
en/volunteer.wml 484) such as making circuits clickable, storing cached map data in Vidalia's
en/volunteer.wml 485) own data directory, and customizing some of the widget's dialogs.
en/volunteer.wml 486) <br />
en/volunteer.wml 487) A person undertaking this project should have good C++ development
en/volunteer.wml 488) experience. Previous experience with Qt and CMake is helpful, but not
en/volunteer.wml 489) required.
en/volunteer.wml 490) </li>
en/volunteer.wml 491) 
en/volunteer.wml 492) <li>
en/volunteer.wml 493) <b>Torbutton equivalent for Thunderbird</b>
en/volunteer.wml 494) <br />

en/volunteer.wml 495) Priority: <i>Medium</i>

en/volunteer.wml 496) <br />
en/volunteer.wml 497) Effort Level: <i>High</i>
en/volunteer.wml 498) <br />
en/volunteer.wml 499) Skill Level: <i>High</i>
en/volunteer.wml 500) <br />
en/volunteer.wml 501) Likely Mentors: <i>Mike</i>
en/volunteer.wml 502) <br />
en/volunteer.wml 503) We're hearing from an increasing number of users that they want to use
en/volunteer.wml 504) Thunderbird with Tor. However, there are plenty of application-level
en/volunteer.wml 505) concerns, for example, by default Thunderbird will put your hostname in
en/volunteer.wml 506) the outgoing mail that it sends. At some point we should start a new
en/volunteer.wml 507) push to build a Thunderbird extension similar to Torbutton.
en/volunteer.wml 508) </li>
en/volunteer.wml 509) 

en/volunteer.wml 510) <li>
en/volunteer.wml 511) <b>Improve Tor Weather</b>
en/volunteer.wml 512) <br />
en/volunteer.wml 513) Priority: <i>Medium</i>
en/volunteer.wml 514) <br />
en/volunteer.wml 515) Effort Level: <i>Medium</i>
en/volunteer.wml 516) <br />
en/volunteer.wml 517) Skill Level: <i>Medium</i>
en/volunteer.wml 518) <br />

en/volunteer.wml 519) Likely Mentors: <i>Christian, Roger, Damian</i>

en/volunteer.wml 520) <br />
en/volunteer.wml 521) <a href="https://weather.torproject.org/">Tor weather</a> is a tool
en/volunteer.wml 522) that allows signing up to receive notifications via email when the
en/volunteer.wml 523) tracked Tor relay is down. Currently, it isn't really useful for
en/volunteer.wml 524) people who use the hibernation feature of Tor, or for those who
en/volunteer.wml 525) have to shut down their relay regularly. During the project, Tor

en/volunteer.wml 526) weather could be extended to allow more flexible configurations.

en/volunteer.wml 527) Other enhancements are also possible: Weather could send out warnings

en/volunteer.wml 528) when your relay runs an out-of-date version of Tor, or when its

en/volunteer.wml 529) observed bandwith drops below a certain value. It might also be a
en/volunteer.wml 530) nice tool that allows for checking whether your relay has earned

en/volunteer.wml 531) you a <a href="<page tshirt>">T-Shirt</a>, or sending reminders to
en/volunteer.wml 532) directory authorities that
en/volunteer.wml 533) their keys are about to expire. Be creative, and consider how the
en/volunteer.wml 534) above project to track overall network status can help you get your job
en/volunteer.wml 535) done more quickly! See also its
en/volunteer.wml 536) <a href="https://svn.torproject.org/svn/weather/trunk/README">README</a>
en/volunteer.wml 537) and <a href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.

en/volunteer.wml 538) </li>
en/volunteer.wml 539) 

en/volunteer.wml 540) <li>

en/volunteer.wml 541) <b>Improvements for Tor+Vidalia interaction on Linux/Unix platforms</b>

en/volunteer.wml 542) <br />

en/volunteer.wml 543) Priority: <i>Medium</i>
en/volunteer.wml 544) <br />
en/volunteer.wml 545) Effort Level: <i>Medium</i>
en/volunteer.wml 546) <br />
en/volunteer.wml 547) Skill Level: <i>Medium</i>
en/volunteer.wml 548) <br />
en/volunteer.wml 549) Likely Mentors: <i>Erinn, Peter</i>
en/volunteer.wml 550) <br />

en/volunteer.wml 551) Vidalia currently doesn't play nicely with Tor on Linux and Unix platforms.
en/volunteer.wml 552) Currently, on Debian and Ubuntu, there is a configuration mechanism which
en/volunteer.wml 553) allows Vidalia to override Tor's ability to start on boot (by sourcing
en/volunteer.wml 554) <code>/etc/default/tor.vidalia</code> which sets <code>RUN_DAEMON=no</code> at the user's
en/volunteer.wml 555) request), but full implementation of <a href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> 
en/volunteer.wml 556) communication is still required.
en/volunteer.wml 557) <br />
en/volunteer.wml 558) A better solution on Linux and Unix platforms would be to use Tor's
en/volunteer.wml 559) ControlSocket, which allows Vidalia to talk to Tor via a Unix domain socket,
en/volunteer.wml 560) and could possibly be enabled by default in Tor's distribution packages.
en/volunteer.wml 561) Vidalia can then authenticate to Tor using filesystem-based (cookie)
en/volunteer.wml 562) authentication if the user running Vidalia is also in the distribution-specific
en/volunteer.wml 563) tor group.
en/volunteer.wml 564) <br />
en/volunteer.wml 565) This project will first involve adding support for Tor's ControlSocket to
en/volunteer.wml 566) Vidalia. The student will then develop and test this support on various
en/volunteer.wml 567) distributions to make sure it behaves in a predictable and consistent manner on
en/volunteer.wml 568) all of them.
en/volunteer.wml 569) <br />
en/volunteer.wml 570) The next challenge would be to find an intuitive and usable way for Vidalia to be
en/volunteer.wml 571) able to change Tor's configuration (torrc) even though it is located in
en/volunteer.wml 572) <code>/etc/tor/torrc</code> and thus immutable. In Debian and Ubuntu we handle
en/volunteer.wml 573) this with the aforementioned <code>/etc/default/tor.vidalia</code> but this
en/volunteer.wml 574) functionality could (or should) be less distribution-specific. 
en/volunteer.wml 575) <br />
en/volunteer.wml 576) The best idea we've come up with so far is to feed Tor a new configuration via
en/volunteer.wml 577) the ControlSocket when Vidalia starts, but that's bad because if the user is not
en/volunteer.wml 578) using the latest Debian/Ubuntu packages, they may not have disabled Tor's
en/volunteer.wml 579) ability to run on boot and will end up with a configuration that is different
en/volunteer.wml 580) from what they want. The second best idea we've come up with is for Vidalia to
en/volunteer.wml 581) write out a temporary torrc file and ask the user to manually move it to
en/volunteer.wml 582) <code>/etc/tor/torrc</code>, but that's bad because users shouldn't have to
en/volunteer.wml 583) mess with files directly.
en/volunteer.wml 584) <br />
en/volunteer.wml 585) A person undertaking this project should have prior knowledge of various Linux
en/volunteer.wml 586) distributions and their packaging mechanisms as well as some C++ development
en/volunteer.wml 587) experience. Previous experience with Qt is helpful, but not required.

en/volunteer.wml 588) </li>
en/volunteer.wml 589) 

en/volunteer.wml 590) <li>

en/volunteer.wml 591) <b>Usability testing of Tor</b>
en/volunteer.wml 592) <br />

en/volunteer.wml 593) Priority: <i>Medium</i>
en/volunteer.wml 594) <br />
en/volunteer.wml 595) Effort Level: <i>Medium</i>
en/volunteer.wml 596) <br />
en/volunteer.wml 597) Skill Level: <i>Low to Medium</i>
en/volunteer.wml 598) <br />
en/volunteer.wml 599) Likely Mentors: <i>Andrew</i>
en/volunteer.wml 600) <br />

en/volunteer.wml 601) Especially the browser bundle, ideally amongst our target demographic.
en/volunteer.wml 602) That would help a lot in knowing what needs to be done in terms of bug
en/volunteer.wml 603) fixes or new features. We get this informally at the moment, but a more
en/volunteer.wml 604) structured process would be better.

en/volunteer.wml 605) </li>

en/volunteer.wml 606) 
en/volunteer.wml 607) <li>
en/volunteer.wml 608) <b>An authenticating IRC proxy</b>
en/volunteer.wml 609) <br />

en/volunteer.wml 610) Priority: <i>Low</i>

en/volunteer.wml 611) <br />
en/volunteer.wml 612) Effort Level: <i>Medium to High</i>
en/volunteer.wml 613) <br />
en/volunteer.wml 614) Skill Level: <i>Medium to High</i>
en/volunteer.wml 615) <br />
en/volunteer.wml 616) Likely Mentors: <i>Sebastian, Weasel, Roger</i>
en/volunteer.wml 617) <br />
en/volunteer.wml 618) The world needs an authenticating irc proxy. As we're periodically
en/volunteer.wml 619) reminded from the Penny Arcade web comic, "Internet user + anonymity =
en/volunteer.wml 620) jerk". With respect to websites we're actually doing ok, since websites
en/volunteer.wml 621) can make their users log in and use other application-level authentication
en/volunteer.wml 622) approaches. But IRC servers are much worse off, because most IRC server
en/volunteer.wml 623) code is poorly written: hard to maintain, and harder to modify. Many
en/volunteer.wml 624) IRC networks now block connections from Tor, and we're basically down to
en/volunteer.wml 625) two holdouts (OFTC and Freenode). This state of affairs means that a lot
en/volunteer.wml 626) of people around the world are thinking "I told you so" about anonymity
en/volunteer.wml 627) online, when in fact the problem is simply lack of technology to make the
en/volunteer.wml 628) problem manageable. We need some way to let the IRC networks distinguish
en/volunteer.wml 629) which users have developed a reputation as not being jerks, so they can
en/volunteer.wml 630) treat the two groups separately. There are some really cool research
en/volunteer.wml 631) designs like <a href="http://www.cs.dartmouth.edu/~nymble/">Nymble</a>,
en/volunteer.wml 632) which aim to let websites blacklist users without needing to learn who
en/volunteer.wml 633) they are.  But Nymble is designed around web interactions. We need to
en/volunteer.wml 634) build the glue around the IRC protocol that would let us plug in a project
en/volunteer.wml 635) like Nymble (or a simpler one to start, as a proof-of-concept). One way
en/volunteer.wml 636) to do that would be to build an IRC proxy that knows how to hear from
en/volunteer.wml 637) IRC clients, knows how to talk to IRC servers, and has an additional

en/volunteer.wml 638) layer that requires the users to authenticate.  Some work on this has
en/volunteer.wml 639) begun by other volunteers, see their progress at <a
en/volunteer.wml 640) href="http://github.com/anonirc/orc">http://github.com/anonirc/orc</a>.

en/volunteer.wml 641) </li>
en/volunteer.wml 642) 

en/volunteer.wml 643) <li>
en/volunteer.wml 644) <b>Make torsocks/dsocks work on OS X</b>
en/volunteer.wml 645) <br />
en/volunteer.wml 646) Priority: <i>Medium</i>
en/volunteer.wml 647) <br />
en/volunteer.wml 648) Effort Level: <i>Medium</i>
en/volunteer.wml 649) <br />
en/volunteer.wml 650) Skill Level: <i>Medium</i>
en/volunteer.wml 651) <br />
en/volunteer.wml 652) Likely Mentors: <i>?</i>
en/volunteer.wml 653) <br />
en/volunteer.wml 654) <a href="http://code.google.com/p/torsocks/">Torsocks</a> and <a
en/volunteer.wml 655) href="http://code.google.com/p/dsocks/">dsocks</a> are wrappers that will
en/volunteer.wml 656) run applications, intercept their outgoing network connections, and push
en/volunteer.wml 657) those connections through Tor. The goal is to handle applications that
en/volunteer.wml 658) don't support proxies (or don't supporting them well). To get it right,
en/volunteer.wml 659) they need to intercept many system calls. The syscalls you need to
en/volunteer.wml 660) intercept on Linux differ dramatically from those on BSD. So Torsocks
en/volunteer.wml 661) works fine on Linux, dsocks works ok on BSD (though it may be less
en/volunteer.wml 662) maintained and thus might miss more syscalls), and nothing works well
en/volunteer.wml 663) on both. First, we should patch dsocks to use Tor's <i>mapaddress</i>
en/volunteer.wml 664) commands from the controller interface, so we don't waste a whole
en/volunteer.wml 665) round-trip inside Tor doing the resolve before connecting. Second,
en/volunteer.wml 666) we should make our <i>torify</i> script detect which of torsocks or
en/volunteer.wml 667) dsocks is installed, and call them appropriately. This probably means
en/volunteer.wml 668) unifying their interfaces, and might involve sharing code between them
en/volunteer.wml 669) or discarding one entirely.
en/volunteer.wml 670) </li>
en/volunteer.wml 671) 

en/volunteer.wml 672) <li>
en/volunteer.wml 673) <b>Bring up new ideas!</b>
en/volunteer.wml 674) <br />
en/volunteer.wml 675) Don't like any of these? Look at the <a

en/volunteer.wml 676) href="<svnprojects>roadmaps/2008-12-19-roadmap-full.pdf">Tor development

en/volunteer.wml 677) roadmap</a> for more ideas, or just try out Tor, Vidalia, and Torbutton,
en/volunteer.wml 678) and find out what you think needs fixing.

en/volunteer.wml 679) Some of the <a href="<gittree>doc/spec/proposals">current proposals</a>
en/volunteer.wml 680) might also be short on developers.
en/volunteer.wml 681) </li>
en/volunteer.wml 682) 

en/volunteer.wml 683) </ol>
en/volunteer.wml 684) 

en/volunteer.wml 685) <a id="OtherCoding"></a>
en/volunteer.wml 686) <h2><a class="anchor" href="#OtherCoding">Other Coding and Design related ideas</a></h2>

volunteer.html   687) <ol>

en/volunteer.wml 688) <li>Tor relays don't work well on Windows XP. On

en/volunteer.wml 689) Windows, Tor uses the standard <tt>select()</tt> system

en/volunteer.wml 690) call, which uses space in the non-page pool. This means

en/volunteer.wml 691) that a medium sized Tor relay will empty the non-page pool, <a

en/volunteer.wml 692) href="<wiki>WindowsBufferProblems">causing

en/volunteer.wml 693) havoc and system crashes</a>. We should probably be using overlapped IO

en/volunteer.wml 694) instead. One solution would be to teach <a
en/volunteer.wml 695) href="http://www.monkey.org/~provos/libevent/">libevent</a> how to use
en/volunteer.wml 696) overlapped IO rather than select() on Windows, and then adapt Tor to

en/volunteer.wml 697) the new libevent interface. Christian King made a

en/volunteer.wml 698) <a href="https://svn.torproject.org/svn/libevent-urz/trunk/">good

en/volunteer.wml 699) start</a> on this in the summer of 2007.</li>

en/volunteer.wml 700) 

en/volunteer.wml 701) <li>We need to actually start building our <a href="<page
en/volunteer.wml 702) documentation>#DesignDoc">blocking-resistance design</a>. This involves

en/volunteer.wml 703) fleshing out the design, modifying many different pieces of Tor, adapting

en/volunteer.wml 704) <a href="<page vidalia/index>">Vidalia</a> so it supports the

en/volunteer.wml 705) new features, and planning for deployment.</li>

en/volunteer.wml 706) 

en/volunteer.wml 707) <li>We need a flexible simulator framework for studying end-to-end
en/volunteer.wml 708) traffic confirmation attacks. Many researchers have whipped up ad hoc
en/volunteer.wml 709) simulators to support their intuition either that the attacks work
en/volunteer.wml 710) really well or that some defense works great. Can we build a simulator
en/volunteer.wml 711) that's clearly documented and open enough that everybody knows it's
en/volunteer.wml 712) giving a reasonable answer? This will spur a lot of new research.
en/volunteer.wml 713) See the entry <a href="#Research">below</a> on confirmation attacks for
en/volunteer.wml 714) details on the research side of this task &mdash; who knows, when it's
en/volunteer.wml 715) done maybe you can help write a paper or three also.</li>

en/volunteer.wml 716) 

en/volunteer.wml 717) <li>Tor 0.1.1.x and later include support for hardware crypto accelerators

en/volunteer.wml 718) via OpenSSL. It has been lightly tested and is possibly very buggy.  We're looking for more rigorous testing, performance analysis, and optimally, code fixes to openssl and Tor if needed.</li>

en/volunteer.wml 719) 

volunteer.html   720) <li>Perform a security analysis of Tor with <a
volunteer.html   721) href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determine

en/volunteer.wml 722) if there are good fuzzing libraries out there for what we want. Win fame by

volunteer.html   723) getting credit when we put out a new release because of you!</li>

en/volunteer.wml 724) 

volunteer.html   725) <li>Tor uses TCP for transport and TLS for link
volunteer.html   726) encryption. This is nice and simple, but it means all cells
volunteer.html   727) on a link are delayed when a single packet gets dropped, and
volunteer.html   728) it means we can only reasonably support TCP streams. We have a <a

en/volunteer.wml 729) href="<wiki>TorFAQ#YoushouldtransportallIPpacketsnotjustTCPpackets.">list

en/volunteer.wml 730) of reasons why we haven't shifted to UDP transport</a>, but it would
en/volunteer.wml 731) be great to see that list get shorter. We also have a proposed <a

en/volunteer.wml 732) href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specification

en/volunteer.wml 733) for Tor and

en/volunteer.wml 734) UDP</a> &mdash; please let us know what's wrong with it.</li>

en/volunteer.wml 735) 

volunteer.html   736) <li>We're not that far from having IPv6 support for destination addresses
volunteer.html   737) (at exit nodes). If you care strongly about IPv6, that's probably the
volunteer.html   738) first place to start.</li>

en/volunteer.wml 739) 
en/volunteer.wml 740) <li>We need a way to generate the website diagrams (for example, the "How
en/volunteer.wml 741) Tor Works" pictures on the <a href="<page overview>">overview page</a>
en/volunteer.wml 742) from source, so we can translate them as UTF-8 text rather than edit

en/volunteer.wml 743) them by hand with image editors. We might want to integrate this as an
en/volunteer.wml 744) wml file so translations are easy and images are generated in multiple
en/volunteer.wml 745) languages whenever we build the website.</li>

en/volunteer.wml 746) 

en/volunteer.wml 747) <li>How can we make the various LiveCD/USB systems easier

en/volunteer.wml 748) to maintain, improve, and document?  One example is <a
en/volunteer.wml 749) href="https://amnesia.boum.org/">The (Amnesic) Incognito Live
en/volunteer.wml 750) System</a>.

en/volunteer.wml 751) </li>

en/volunteer.wml 752) 
en/volunteer.wml 753) <li>
en/volunteer.wml 754) Another anti-censorship project is to try to make Tor
en/volunteer.wml 755) more scanning-resistant.  Right now, an adversary can identify <a
en/volunteer.wml 756) href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
en/volunteer.wml 757) just by trying to connect to them, following the Tor protocol,
en/volunteer.wml 758) and seeing if they respond.  To solve this, bridges could <a

en/volunteer.wml 759) href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

en/volunteer.wml 760) webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
en/volunteer.wml 761) and not act like bridges until the user provides a bridge-specific key.
en/volunteer.wml 762) To start, check out Shane Pope's <a
en/volunteer.wml 763) href="http://dl.dropbox.com/u/37735/index.html">thesis and prototype</a>.
en/volunteer.wml 764) </li>
en/volunteer.wml 765) 

volunteer.html   766) </ol>
volunteer.html   767) 

en/volunteer.wml 768) <a id="Research"></a>
en/volunteer.wml 769) <h2><a class="anchor" href="#Research">Research</a></h2>

volunteer.html   770) <ol>

volunteer.html   771) <li>The "end-to-end traffic confirmation attack":
volunteer.html   772) by watching traffic at Alice and at Bob, we can <a
volunteer.html   773) href="http://freehaven.net/anonbib/#danezis:pet2004">compare
volunteer.html   774) traffic signatures and become convinced that we're watching the same
volunteer.html   775) stream</a>. So far Tor accepts this as a fact of life and assumes this
volunteer.html   776) attack is trivial in all cases. First of all, is that actually true? How
volunteer.html   777) much traffic of what sort of distribution is needed before the adversary
volunteer.html   778) is confident he has won? Are there scenarios (e.g. not transmitting much)
volunteer.html   779) that slow down the attack? Do some traffic padding or traffic shaping
volunteer.html   780) schemes work better than others?</li>

en/volunteer.wml 781) <li>A related question is: Does running a relay/bridge provide additional
en/volunteer.wml 782) protection against these timing attacks? Can an external adversary that can't

en/volunteer.wml 783) see inside TLS links still recognize individual streams reliably?

en/volunteer.wml 784) Does the amount of traffic carried degrade this ability any? What if the
en/volunteer.wml 785) client-relay deliberately delayed upstream relayed traffic to create a queue
en/volunteer.wml 786) that could be used to mimic timings of client downstream traffic to make it
en/volunteer.wml 787) look like it was also relayed? This same queue could also be used for masking
en/volunteer.wml 788) timings in client upstream traffic with the techniques from <a
en/volunteer.wml 789) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptive padding</a>,
en/volunteer.wml 790) but without the need for additional traffic. Would such an interleaving of
en/volunteer.wml 791) client upstream traffic obscure timings for external adversaries? Would the
en/volunteer.wml 792) strategies need to be adjusted for asymmetric links? For example, on
en/volunteer.wml 793) asymmetric links, is it actually possible to differentiate client traffic from
en/volunteer.wml 794) natural bursts due to their asymmetric capacity? Or is it easier than
en/volunteer.wml 795) symmetric links for some other reason?</li>

en/volunteer.wml 796) <li>Repeat Murdoch and Danezis's <a
en/volunteer.wml 797) href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">attack from
en/volunteer.wml 798) Oakland 05</a> on the current Tor network. See if you can learn why it
en/volunteer.wml 799) works well on some nodes and not well on others. (My theory is that the
en/volunteer.wml 800) fast nodes with spare capacity resist the attack better.) If that's true,
en/volunteer.wml 801) then experiment with the RelayBandwidthRate and RelayBandwidthBurst
en/volunteer.wml 802) options to run a relay that is used as a client while relaying the
en/volunteer.wml 803) attacker's traffic: as we crank down the RelayBandwidthRate, does the
en/volunteer.wml 804) attack get harder? What's the right ratio of RelayBandwidthRate to
en/volunteer.wml 805) actually capacity? Or is it a ratio at all? While we're at it, does a
en/volunteer.wml 806) much larger set of candidate relays increase the false positive rate
en/volunteer.wml 807) or other complexity for the attack? (The Tor network is now almost two
en/volunteer.wml 808) orders of magnitude larger than it was when they wrote their paper.) Be
en/volunteer.wml 809) sure to read <a href="http://freehaven.net/anonbib/#clog-the-queue">Don't
en/volunteer.wml 810) Clog the Queue</a> too.</li>

volunteer.html   811) <li>The "routing zones attack": most of the literature thinks of
volunteer.html   812) the network path between Alice and her entry node (and between the
volunteer.html   813) exit node and Bob) as a single link on some graph. In practice,
volunteer.html   814) though, the path traverses many autonomous systems (ASes), and <a
volunteer.html   815) href="http://freehaven.net/anonbib/#feamster:wpes2004">it's not uncommon
volunteer.html   816) that the same AS appears on both the entry path and the exit path</a>.
volunteer.html   817) Unfortunately, to accurately predict whether a given Alice, entry,
volunteer.html   818) exit, Bob quad will be dangerous, we need to download an entire Internet
volunteer.html   819) routing zone and perform expensive operations on it. Are there practical
volunteer.html   820) approximations, such as avoiding IP addresses in the same /8 network?</li>

en/volunteer.wml 821) <li>Other research questions regarding geographic diversity consider
en/volunteer.wml 822) the tradeoff between choosing an efficient circuit and choosing a random

en/volunteer.wml 823) circuit. Look at Stephen Rollyson's <a

en/volunteer.wml 824) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">position
en/volunteer.wml 825) paper</a> on how to discard particularly slow choices without hurting

en/volunteer.wml 826) anonymity "too much". This line of reasoning needs more work and more
en/volunteer.wml 827) thinking, but it looks very promising.</li>

en/volunteer.wml 828) <li>Tor doesn't work very well when relays have asymmetric bandwidth

volunteer.html   829) (e.g. cable or DSL). Because Tor has separate TCP connections between
volunteer.html   830) each hop, if the incoming bytes are arriving just fine and the outgoing
volunteer.html   831) bytes are all getting dropped on the floor, the TCP push-back mechanisms
volunteer.html   832) don't really transmit this information back to the incoming streams.
volunteer.html   833) Perhaps Tor should detect when it's dropping a lot of outgoing packets,
volunteer.html   834) and rate-limit incoming streams to regulate this itself? I can imagine
volunteer.html   835) a build-up and drop-off scheme where we pick a conservative rate-limit,
volunteer.html   836) slowly increase it until we get lost packets, back off, repeat. We
volunteer.html   837) need somebody who's good with networks to simulate this and help design
volunteer.html   838) solutions; and/or we need to understand the extent of the performance
volunteer.html   839) degradation, and use this as motivation to reconsider UDP transport.</li>
volunteer.html   840) <li>A related topic is congestion control. Is our
volunteer.html   841) current design sufficient once we have heavy use? Maybe
volunteer.html   842) we should experiment with variable-sized windows rather
volunteer.html   843) than fixed-size windows? That seemed to go well in an <a
volunteer.html   844) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh
volunteer.html   845) throughput experiment</a>. We'll need to measure and tweak, and maybe
volunteer.html   846) overhaul if the results are good.</li>

en/volunteer.wml 847) <li>Our censorship-resistance goals include preventing
en/volunteer.wml 848) an attacker who's looking at Tor traffic on the wire from <a

en/volunteer.wml 849) href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">distinguishing

en/volunteer.wml 850) it from normal SSL traffic</a>. Obviously we can't achieve perfect
en/volunteer.wml 851) steganography and still remain usable, but for a first step we'd like to
en/volunteer.wml 852) block any attacks that can win by observing only a few packets. One of
en/volunteer.wml 853) the remaining attacks we haven't examined much is that Tor cells are 512
en/volunteer.wml 854) bytes, so the traffic on the wire may well be a multiple of 512 bytes.
en/volunteer.wml 855) How much does the batching and overhead in TLS records blur this on the
en/volunteer.wml 856) wire? Do different buffer flushing strategies in Tor affect this? Could
en/volunteer.wml 857) a bit of padding help a lot, or is this an attack we must accept?</li>

volunteer.html   858) <li>Tor circuits are built one hop at a time, so in theory we have the
volunteer.html   859) ability to make some streams exit from the second hop, some from the
volunteer.html   860) third, and so on. This seems nice because it breaks up the set of exiting

en/volunteer.wml 861) streams that a given relay can see. But if we want each stream to be safe,

volunteer.html   862) the "shortest" path should be at least 3 hops long by our current logic, so
volunteer.html   863) the rest will be even longer. We need to examine this performance / security
volunteer.html   864) tradeoff.</li>

en/volunteer.wml 865) <li>It's not that hard to DoS Tor relays or directory authorities. Are client

volunteer.html   866) puzzles the right answer? What other practical approaches are there? Bonus
volunteer.html   867) if they're backward-compatible with the current Tor protocol.</li>

en/volunteer.wml 868) <li>Programs like <a

en/volunteer.wml 869) href="<page torbutton/index>">Torbutton</a> aim to hide

en/volunteer.wml 870) your browser's UserAgent string by replacing it with a uniform answer for
en/volunteer.wml 871) every Tor user. That way the attacker can't splinter Tor's anonymity set
en/volunteer.wml 872) by looking at that header. It tries to pick a string that is commonly used
en/volunteer.wml 873) by non-Tor users too, so it doesn't stand out. Question one: how badly
en/volunteer.wml 874) do we hurt ourselves by periodically updating the version of Firefox
en/volunteer.wml 875) that Torbutton claims to be? If we update it too often, we splinter the
en/volunteer.wml 876) anonymity sets ourselves. If we don't update it often enough, then all the
en/volunteer.wml 877) Tor users stand out because they claim to be running a quite old version
en/volunteer.wml 878) of Firefox. The answer here probably depends on the Firefox versions seen
en/volunteer.wml 879) in the wild. Question two: periodically people ask us to cycle through N
en/volunteer.wml 880) UserAgent strings rather than stick with one. Does this approach help,
en/volunteer.wml 881) hurt, or not matter? Consider: cookies and recognizing Torbutton users
en/volunteer.wml 882) by their rotating UserAgents; malicious websites who only attack certain
en/volunteer.wml 883) browsers; and whether the answers to question one impact this answer.
en/volunteer.wml 884) </li>

en/volunteer.wml 885) <li>Right now Tor clients are willing to reuse a given circuit for ten
en/volunteer.wml 886) minutes after it's first used. The goal is to avoid loading down the
en/volunteer.wml 887) network with too many circuit extend operations, yet to also avoid having
en/volunteer.wml 888) clients use the same circuit for so long that the exit node can build a
en/volunteer.wml 889) useful pseudonymous profile of them. Alas, ten minutes is probably way
en/volunteer.wml 890) too long, especially if connections from multiple protocols (e.g. IM and
en/volunteer.wml 891) web browsing) are put on the same circuit. If we keep fixed the overall
en/volunteer.wml 892) number of circuit extends that the network needs to do, are there more
en/volunteer.wml 893) efficient and/or safer ways for clients to allocate streams to circuits,
en/volunteer.wml 894) or for clients to build preemptive circuits? Perhaps this research item
en/volunteer.wml 895) needs to start with gathering some traces of what connections typical
en/volunteer.wml 896) clients try to launch, so you have something realistic to try to optimize.
en/volunteer.wml 897) </li>
en/volunteer.wml 898) <li>How many bridge relays do you need to know to maintain
en/volunteer.wml 899) reachability? We should measure the churn in our bridges. If there is
en/volunteer.wml 900) lots of churn, are there ways to keep bridge users more likely to stay
en/volunteer.wml 901) connected?
en/volunteer.wml 902) </li>

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

en/volunteer.wml 905) <p>

en/volunteer.wml 906) <a href="<page contact>">Let us know</a> if you've made progress on any
en/volunteer.wml 907) of these!

en/volunteer.wml 908) </p>

volunteer.html   909) 

en/volunteer.wml 910)   </div><!-- #main -->

volunteer.html   911)