tor-webwml.git

en/volunteer.wml   1) ## translation metadata

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

volunteer.html     3) 

en/volunteer.wml   4) #include "head.wmi" TITLE="Volunteer"

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

en/volunteer.wml   9) <h2>Four things everyone can do now:</h2>

volunteer.html    10) <ol>

en/volunteer.wml  11) <li> Please consider <a href="<cvssandbox>tor/doc/tor-doc-server.html">running

volunteer.html    12) a server</a> to help the Tor network grow.</li>

en/volunteer.wml  13) <li> Take a look at the <a href="<page gui/index>">Tor GUI Competition</a>, and

en/volunteer.wml  14) contribute to making Tor's interface
en/volunteer.wml  15) and usability better. Free Tor T-shirt for each submission!</li>

volunteer.html    16) <li> Tell your friends! Get them to run servers. Get them to run hidden
volunteer.html    17) services. Get them to tell their friends.</li>

en/volunteer.wml  18) <li> We are looking for funding and sponsors. If you like Tor's goals, please

en/volunteer.wml  19)   <a href="<page donate>">take a moment to donate to support further
en/volunteer.wml  20)   Tor development</a>. Also, if you know any

en/volunteer.wml  21)   companies, NGOs, or other organizations that want communications
en/volunteer.wml  22)   security, let them know about us.</li>

volunteer.html    23) </ol>
volunteer.html    24) 

en/volunteer.wml  25) <a id="Bugs"></a>
en/volunteer.wml  26) <h2><a class="anchor" href="#Bugs">Critical bugs</a></h2>
en/volunteer.wml  27) <ol>
en/volunteer.wml  28) <li>Tor servers are not stable on Windows XP currently,
en/volunteer.wml  29) because we try to use hundreds of sockets, and the
en/volunteer.wml  30) Windows kernel doesn't seem capable of handling this. <a
en/volunteer.wml  31) href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Please
en/volunteer.wml  32) help us solve this!</a> It is the number one problem with growing
en/volunteer.wml  33) the Tor network currently.</li>
en/volunteer.wml  34) </ol>
en/volunteer.wml  35) 

en/volunteer.wml  36) <!--

en/volunteer.wml  37) <a id="Installers"></a>
en/volunteer.wml  38) <h2><a class="anchor" href="#Installers">Installers</a></h2>

volunteer.html    39) <ol>

en/volunteer.wml  40) <li>Matt Edman has written an <a

en/volunteer.wml  41) href="http://freehaven.net/~edmanm/torcp/download.html">NSIS-based
en/volunteer.wml  42) Windows installer bundle that
en/volunteer.wml  43) includes Privoxy and TorCP</a>. Can you help make it more stable and
en/volunteer.wml  44) featureful?
en/volunteer.wml  45) </li>

volunteer.html    46) <li>Develop a way to handle OS X uninstallation

en/volunteer.wml  47) that is more automated than telling people to
en/volunteer.wml  48) <a href="<cvssandbox>tor/doc/tor-doc-osx.html#uninstall">manually remove

en/volunteer.wml  49) each file</a>. It needs to have a way to click it into action.</li>

en/volunteer.wml  50) <li>Our <a href="<cvssandbox>tor/tor.spec.in">RPM spec file</a>

volunteer.html    51) needs a maintainer, so we can get back to the business of writing Tor. If
volunteer.html    52) you have RPM fu, please help out.</li>
volunteer.html    53) </ol>

en/volunteer.wml  54) -->

volunteer.html    55) 

en/volunteer.wml  56) <a id="Usability"></a>
en/volunteer.wml  57) <h2><a class="anchor" href="#Usability">Usability and Interface</a></h2>

volunteer.html    58) <ol>

en/volunteer.wml  59) <li><a
en/volunteer.wml  60) href="http://tor.eff.org/cvs/tor/doc/tor-switchproxy.html">SwitchProxy</a>
en/volunteer.wml  61) is more complex than we need. It has confusing options like "anonymous"
en/volunteer.wml  62) proxies that aren't really anonymous. Plus, the user needs to manually
en/volunteer.wml  63) type in things like "localhost" and "8118". Should we offer our own
en/volunteer.wml  64) adapted plugin that has suitable defaults for Tor pre-assigned?
en/volunteer.wml  65) Also, I hear SwitchProxy is not as compatible with Firefox 1.5 -- are
en/volunteer.wml  66) other plugins like ProxyButton more flexible across versions?</li>

volunteer.html    67) <li>We need a way to intercept DNS requests so they don't "leak" while
volunteer.html    68) we're trying to be anonymous. (This happens because the application does
volunteer.html    69) the DNS resolve before going to the SOCKS proxy.) One option is to use
volunteer.html    70) Tor's built-in support for doing DNS resolves; but you need to ask via
volunteer.html    71) our new socks extension for that, and no applications do this yet. A
volunteer.html    72) nicer option is to use Tor's controller interface: you intercept the
volunteer.html    73) DNS resolve, tell Tor about the resolve, and Tor replies with a dummy IP
volunteer.html    74) address. Then the application makes a connection through Tor to that dummy
volunteer.html    75) IP address, and Tor automatically maps it back to the original query.</li>
volunteer.html    76) <li>People running servers tell us they want to have one BandwidthRate
volunteer.html    77) during some part of the day, and a different BandwidthRate at other parts
volunteer.html    78) of the day. Rather than coding this inside Tor, we should have a little

en/volunteer.wml  79) script that speaks via the <a href="<page gui/index>">Tor Controller Interface</a>,

volunteer.html    80) and does a setconf to change the bandwidth rate. Perhaps it would run out
volunteer.html    81) of cron, or perhaps it would sleep until appropriate times and then do
volunteer.html    82) its tweak (that's probably more portable). Can somebody write one for us

en/volunteer.wml  83) and we'll put it into <a href="<cvssandbox>tor/contrib/">tor/contrib/</a>?</li>

volunteer.html    84) <li>We have a variety of ways to <a
volunteer.html    85) href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">exit
volunteer.html    86) the Tor network from a particular country</a>, but they all
volunteer.html    87) require specifying the nickname of a particular Tor server. It
volunteer.html    88) would be nice to be able to specify just a country, and
volunteer.html    89) have something automatically pick. This requires having some
volunteer.html    90) component that knows what country each Tor node is in. The <a

en/volunteer.wml  91) href="http://serifos.eecs.harvard.edu/cgi-bin/exit.pl">script on

volunteer.html    92) serifos</a> manually parses whois entries for this. Maybe geolocation
volunteer.html    93) data will also work?</li>
volunteer.html    94) <li>Speaking of geolocation data, somebody should draw a map of the Earth
volunteer.html    95) with a pin-point for each Tor server. Bonus points if it updates as the
volunteer.html    96) network grows and changes.</li>
volunteer.html    97) <li>Tor provides anonymous connections, but we don't support
volunteer.html    98) keeping multiple pseudonyms in practice (say, in case you
volunteer.html    99) frequently go to two websites and if anybody knew about both of
volunteer.html   100) them they would conclude it's you). We should find a good approach
volunteer.html   101) and interface for handling pseudonymous profiles in Tor. See <a

volunteer.html   102) href="http://archives.seul.org/or/talk/Dec-2004/msg00086.html">this

volunteer.html   103) post</a> and <a
volunteer.html   104) href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html">followup</a>
volunteer.html   105) for details.</li>

volunteer.html   106) </ol>
volunteer.html   107) 

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

volunteer.html   110) <ol>

volunteer.html   111) <li>Please volunteer to help maintain this website: code, content,

volunteer.html   112) css, layout. Step one is to hang out on the IRC channel until we
volunteer.html   113) get to know you.</li>

volunteer.html   114) <li>We have too much documentation --- it's spread out too much and
volunteer.html   115) duplicates itself in places. Please send us patches, pointers, and
volunteer.html   116) confusions about the documentation so we can clean it up.</li>
volunteer.html   117) <li>Help translate the web page and documentation into other

en/volunteer.wml 118) languages. See the <a href="<page translation>">translation

volunteer.html   119) guidelines</a> if you want to help out. We also need people to help

en/volunteer.wml 120) maintain the existing Italian, French, and Swedish translations -
en/volunteer.wml 121) see the <a href="<page translation-status>">translation status
en/volunteer.wml 122) overview</a>.</li>

volunteer.html   123) <li>Investigate privoxy vs. freecap vs. sockscap for win32 clients. Are
volunteer.html   124) there usability or stability issues that we can track down and
volunteer.html   125) resolve, or at least inform people about?</li>

volunteer.html   126) <li>Can somebody help Matt Edman with the documentation and how-tos
volunteer.html   127) for his <a href="http://freehaven.net/~edmanm/torcp/">Windows Tor

volunteer.html   128) Controller</a>?</li>

en/volunteer.wml 129) <li>Evaluate and document
en/volunteer.wml 130) <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">our
en/volunteer.wml 131) list of programs</a> that can be configured to use Tor.</li>

volunteer.html   132) <li>We need better documentation for dynamically intercepting

en/volunteer.wml 133) connections and sending them through Tor. tsocks (Linux), dsocks (BSD),
en/volunteer.wml 134) and freecap (Windows) seem to be good candidates.</li>

en/volunteer.wml 135) <li>We have a huge list of <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">potentially useful

volunteer.html   136) programs that interface to Tor</a>. Which ones are useful in which
volunteer.html   137) situations? Please help us test them out and document your results.</li>
volunteer.html   138) </ol>
volunteer.html   139) 

en/volunteer.wml 140) <a id="Coding"></a>
en/volunteer.wml 141) <h2><a class="anchor" href="#Coding">Coding and Design</a></h2>

volunteer.html   142) <ol>
volunteer.html   143) <li>We recommend Privoxy as a good scrubbing web proxy, but it's
volunteer.html   144) unmaintained and still has bugs, especially on Windows. While we're at
volunteer.html   145) it, what sensitive information is not kept safe by Privoxy? Are there
volunteer.html   146) other scrubbing web proxies that are more secure?</li>
volunteer.html   147) <li>tsocks appears to be unmaintained: we have submitted several patches
volunteer.html   148) with no response. Can somebody volunteer to start maintaining a new
volunteer.html   149) tsocks branch? We'll help.</li>

volunteer.html   150) <li>Right now the hidden service descriptors are being stored on just a few
volunteer.html   151) directory servers. This is bad for privacy and bad for robustness. To get
volunteer.html   152) more robustness, we're going to need to make hidden service descriptors
volunteer.html   153) even less private because we're going to have to mirror them onto many
volunteer.html   154) places. Ideally we'd like to separate the storage/lookup system from the
volunteer.html   155) Tor directory servers entirely. Any reliable distributed storage system
volunteer.html   156) will do, as long as it allows authenticated updates. As far as we know,
volunteer.html   157) no implemented DHT code supports authenticated updates. What's the right
volunteer.html   158) next step?</li>
volunteer.html   159) <li>Tor exit servers need to do many DNS resolves in parallel. But
volunteer.html   160) gethostbyname() is poorly designed --- it blocks until it has finished

volunteer.html   161) resolving a query --- so it requires its own thread or process. So Tor
volunteer.html   162) is forced to spawn many separate DNS "worker" threads. There are some
volunteer.html   163) asynchronous DNS libraries out there, but historically they are buggy and

volunteer.html   164) abandoned. Are any of them stable, fast, clean, and free software? (Remember,
volunteer.html   165) Tor uses OpenSSL, and OpenSSL is (probably) not compatible with the GPL, so
volunteer.html   166) any GPL libraries are out of the running.) If so

volunteer.html   167) (or if we can make that so), we should integrate them into Tor. See <a

volunteer.html   168) href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">Agl's

volunteer.html   169) post</a> for one potential approach. Also see
volunteer.html   170) <a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> and
volunteer.html   171) <a href="http://www.monkey.org/~provos/libdnsres/">libdnsres</a>.
volunteer.html   172) </li>

volunteer.html   173) <li>Tor 0.1.1.x includes support for hardware crypto accelerators via
volunteer.html   174) OpenSSL. Nobody has ever tested it, though. Does somebody want to get
volunteer.html   175) a card and let us know how it goes?</li>

volunteer.html   176) <li>Because Tor servers need to store-and-forward each cell they handle,
volunteer.html   177) high-bandwidth Tor servers end up using dozens of megabytes of memory
volunteer.html   178) just for buffers. We need better heuristics for when to shrink/expand
volunteer.html   179) buffers. Maybe this should be modelled after the Linux kernel buffer
volunteer.html   180) design, where you have many smaller buffers that link to each other,
volunteer.html   181) rather than monolithic buffers?</li>

volunteer.html   182) <li>How do ulimits work on Win32, anyway? We're having problems,

volunteer.html   183) especially on older Windowses with people running out of file
volunteer.html   184) descriptors, connection buffer space, etc. (We should handle
volunteer.html   185) WSAENOBUFS as needed, look at the MaxConnections registry entry,
volunteer.html   186) look at the MaxUserPort entry, and look at the TcpTimedWaitDelay
volunteer.html   187) entry. We may also want to provide a way to set them as needed. See <a

volunteer.html   188) href="http://bugs.noreply.org/flyspray/index.php?do=details&id=98">bug

volunteer.html   189) 98</a>.)</li>

volunteer.html   190) <li>Patches to Tor's autoconf scripts. First, we'd like our configure.in
volunteer.html   191) to handle cross-compilation, e.g. so we can build Tor for obscure

volunteer.html   192) platforms like the Linksys WRTG54. Second, we'd like the with-ssl-dir
volunteer.html   193) option to disable the search for ssl's libraries.</li>

volunteer.html   194) <li>Implement reverse DNS requests inside Tor (already specified in

en/volunteer.wml 195) Section 5.4 of <a href="<cvssandbox>tor/doc/tor-spec.txt">tor-spec.txt</a>).</li>

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

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

volunteer.html   199) getting credit when we put out a new release because of you!</li>
volunteer.html   200) <li>How hard is it to patch bind or a DNS proxy to redirect requests to

volunteer.html   201) Tor via our <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">tor-resolve socks extension</a>? What about to convert UDP DNS

volunteer.html   202) requests to TCP requests and send them through Tor?</li>

volunteer.html   203) <li>Tor uses TCP for transport and TLS for link
volunteer.html   204) encryption. This is nice and simple, but it means all cells
volunteer.html   205) on a link are delayed when a single packet gets dropped, and
volunteer.html   206) it means we can only reasonably support TCP streams. We have a <a
volunteer.html   207) href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">list
volunteer.html   208) of reasons why we haven't shifted to UDP transport</a>, but it would be

volunteer.html   209) great to see that list get shorter.</li>

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

volunteer.html   213) </ol>
volunteer.html   214) 

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

volunteer.html   217) <ol>

volunteer.html   218) <li>The "website fingerprinting attack": make a list of a few
volunteer.html   219) hundred popular websites, download their pages, and make a set of
volunteer.html   220) "signatures" for each site. Then observe a Tor client's traffic. As
volunteer.html   221) you watch him receive data, you quickly approach a guess about which
volunteer.html   222) (if any) of those sites he is visiting. First, how effective is
volunteer.html   223) this attack on the deployed Tor codebase? Then start exploring
volunteer.html   224) defenses: for example, we could change Tor's cell size from 512
volunteer.html   225) bytes to 1024 bytes, we could employ padding techniques like <a
volunteer.html   226) href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>,
volunteer.html   227) or we could add traffic delays. How much of an impact do these have,
volunteer.html   228) and how much usability impact (using some suitable metric) is there from
volunteer.html   229) a successful defense in each case?</li>

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

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

volunteer.html   250) <li>Tor doesn't work very well when servers have asymmetric bandwidth
volunteer.html   251) (e.g. cable or DSL). Because Tor has separate TCP connections between
volunteer.html   252) each hop, if the incoming bytes are arriving just fine and the outgoing
volunteer.html   253) bytes are all getting dropped on the floor, the TCP push-back mechanisms
volunteer.html   254) don't really transmit this information back to the incoming streams.
volunteer.html   255) Perhaps Tor should detect when it's dropping a lot of outgoing packets,
volunteer.html   256) and rate-limit incoming streams to regulate this itself? I can imagine
volunteer.html   257) a build-up and drop-off scheme where we pick a conservative rate-limit,
volunteer.html   258) slowly increase it until we get lost packets, back off, repeat. We
volunteer.html   259) need somebody who's good with networks to simulate this and help design
volunteer.html   260) solutions; and/or we need to understand the extent of the performance
volunteer.html   261) degradation, and use this as motivation to reconsider UDP transport.</li>
volunteer.html   262) <li>A related topic is congestion control. Is our
volunteer.html   263) current design sufficient once we have heavy use? Maybe
volunteer.html   264) we should experiment with variable-sized windows rather
volunteer.html   265) than fixed-size windows? That seemed to go well in an <a
volunteer.html   266) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh
volunteer.html   267) throughput experiment</a>. We'll need to measure and tweak, and maybe
volunteer.html   268) overhaul if the results are good.</li>

volunteer.html   269) <li>To let dissidents in remote countries use Tor without being blocked
volunteer.html   270) at their country's firewall, we need a way to get tens of thousands of
volunteer.html   271) relays, not just a few hundred. We can imagine a Tor client GUI that
volunteer.html   272) has a "help China" button at the top that opens a port and relays a
volunteer.html   273) few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too
volunteer.html   274) much hassle, and there are few abuse issues since they're not being exit
volunteer.html   275) nodes.) But how do we distribute a list of these volunteer clients to the
volunteer.html   276) good dissidents in an automated way that doesn't let the country-level
volunteer.html   277) firewalls intercept and enumerate them? Probably needs to work on a

en/volunteer.wml 278) human-trust level. See our <a
en/volunteer.wml 279) href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China">FAQ
en/volunteer.wml 280) entry</a> on this, and then read the <a
en/volunteer.wml 281) href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">censorship
en/volunteer.wml 282) resistance section of anonbib</a>.</li>

volunteer.html   283) <li>Tor circuits are built one hop at a time, so in theory we have the
volunteer.html   284) ability to make some streams exit from the second hop, some from the
volunteer.html   285) third, and so on. This seems nice because it breaks up the set of exiting
volunteer.html   286) streams that a given server can see. But if we want each stream to be safe,
volunteer.html   287) the "shortest" path should be at least 3 hops long by our current logic, so
volunteer.html   288) the rest will be even longer. We need to examine this performance / security
volunteer.html   289) tradeoff.</li>
volunteer.html   290) <li>It's not that hard to DoS Tor servers or dirservers. Are client
volunteer.html   291) puzzles the right answer? What other practical approaches are there? Bonus
volunteer.html   292) if they're backward-compatible with the current Tor protocol.</li>

volunteer.html   293) </ol>
volunteer.html   294) 

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

volunteer.html   297) 

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

volunteer.html   299)