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>Three things everyone can do now:</h2>

volunteer.html    10) <ol>

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

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

en/volunteer.wml  13) <li>Tell your friends! Get them to run servers. Get them to run hidden

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

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

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

en/volunteer.wml  18)   companies, NGOs, agencies, or other organizations that want communications

en/volunteer.wml  19)   security, let them know about us.</li>

volunteer.html    20) </ol>
volunteer.html    21) 

en/volunteer.wml  22) <a id="Bugs"></a>
en/volunteer.wml  23) <h2><a class="anchor" href="#Bugs">Critical bugs</a></h2>
en/volunteer.wml  24) <ol>
en/volunteer.wml  25) <li>Tor servers are not stable on Windows XP currently,
en/volunteer.wml  26) because we try to use hundreds of sockets, and the
en/volunteer.wml  27) Windows kernel doesn't seem capable of handling this. <a
en/volunteer.wml  28) href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Please

en/volunteer.wml  29) help us solve this!</a> Probably the best solution is to teach libevent
en/volunteer.wml  30) how to use overlapped IO rather than select() on Windows, and then adapt
en/volunteer.wml  31) Tor to the new libevent interface.</li>

en/volunteer.wml  32) </ol>
en/volunteer.wml  33) 

en/volunteer.wml  34) <a id="Usability"></a>

en/volunteer.wml  35) <h2><a class="anchor" href="#Usability">Supporting Applications</a></h2>

volunteer.html    36) <ol>

en/volunteer.wml  37) <li>We need good ways to intercept DNS requests so they don't "leak" their
en/volunteer.wml  38) request to a local observer while we're trying to be anonymous. (This
en/volunteer.wml  39) happens because the application does the DNS resolve before going to
en/volunteer.wml  40) the SOCKS proxy.)</li>
en/volunteer.wml  41) <ul>
en/volunteer.wml  42) <li>We need to <a
en/volunteer.wml  43) href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">apply
en/volunteer.wml  44) all our tsocks patches</a> and maintain a new fork. We'll host it if
en/volunteer.wml  45) you want.</li>
en/volunteer.wml  46) <li>We should patch Dug Song's "dsocks" program to use Tor's
en/volunteer.wml  47) <i>mapaddress</i> commands from the controller interface, so we
en/volunteer.wml  48) don't waste a whole round-trip inside Tor doing the resolve before
en/volunteer.wml  49) connecting.</li>
en/volunteer.wml  50) <li>We need to make our <i>torify</i> script detect which of tsocks or
en/volunteer.wml  51) dsocks is installed, and call them appropriately. This probably means
en/volunteer.wml  52) unifying their interfaces, and might involve sharing code between them
en/volunteer.wml  53) or discarding one entirely.</li>
en/volunteer.wml  54) </ul>

volunteer.html    55) <li>People running servers tell us they want to have one BandwidthRate
volunteer.html    56) during some part of the day, and a different BandwidthRate at other parts
volunteer.html    57) of the day. Rather than coding this inside Tor, we should have a little

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

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

en/volunteer.wml  62) and we'll put it into <a href="<svnsandbox>contrib/">contrib/</a>?

en/volunteer.wml  63) This is a good entry for the <a href="<page gui/index>">Tor GUI

en/volunteer.wml  64) competition</a>.
en/volunteer.wml  65)   <!-- We have a good script to adjust stuff now, right? -NM -->
en/volunteer.wml  66) </li>

en/volunteer.wml  67) <li>Tor can <a

volunteer.html    68) href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">exit

en/volunteer.wml  69) the Tor network from a particular exit node</a>, but we should be able
en/volunteer.wml  70) to specify just a country and have something automatically pick. The
en/volunteer.wml  71) best bet is to fetch Blossom's directory also, and run a local Blossom
en/volunteer.wml  72) client that fetches this directory securely (via Tor and checking its
en/volunteer.wml  73) signature), intercepts <tt>.country.blossom</tt> hostnames, and does
en/volunteer.wml  74) the right thing.</li>

volunteer.html    75) <li>Speaking of geolocation data, somebody should draw a map of the Earth
volunteer.html    76) with a pin-point for each Tor server. Bonus points if it updates as the

en/volunteer.wml  77) network grows and changes. Unfortunately, the easy ways to do this involve
en/volunteer.wml  78) sending all the data to Google and having them draw the map for you. How
en/volunteer.wml  79) much does this impact privacy, and do we have any other good options?</li>

volunteer.html    80) </ol>
volunteer.html    81) 

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

volunteer.html    84) <ol>

en/volunteer.wml  85) <li>We hear that Tor users can fall victim to anonymity-breaking attacks
en/volunteer.wml  86) from javascript, java, activex, flash, etc, if they don't disable
en/volunteer.wml  87) them. Are there plugins out there (like NoScript for Firefox) that make
en/volunteer.wml  88) it easier for users to manage this risk? What is the risk exactly?</li>
en/volunteer.wml  89) <li>Is there a full suite of plugins that will replace all of Privoxy's
en/volunteer.wml  90) functionality for Firefox 1.5+? We hear Tor is much faster when you take
en/volunteer.wml  91) Privoxy out of the loop.</li>
en/volunteer.wml  92) <li>Please help Matt Edman with the documentation and how-tos for his

en/volunteer.wml  93) Tor controller,
en/volunteer.wml  94) <a href="http://vidalia-project.net/">Vidalia</a>.</li>

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

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

en/volunteer.wml  99) connections and sending them through Tor. tsocks (Linux), dsocks (BSD),

en/volunteer.wml 100) and freecap (Windows) seem to be good candidates, as would better
en/volunteer.wml 101) use of our new TransPort feature.</li>

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

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

en/volunteer.wml 105) <li>Help translate the web page and documentation into other
en/volunteer.wml 106) languages. See the <a href="<page translation>">translation
en/volunteer.wml 107) guidelines</a> if you want to help out. We also need people to help
en/volunteer.wml 108) maintain the existing Italian, French, and Swedish translations -
en/volunteer.wml 109) see the <a href="<page translation-status>">translation status
en/volunteer.wml 110) overview</a>.</li>

volunteer.html   111) </ol>
volunteer.html   112) 

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

volunteer.html   115) <ol>

en/volunteer.wml 116) <li>Right now the hidden service descriptors are being stored on just a
en/volunteer.wml 117) few directory servers. This is bad for privacy and bad for robustness. To
en/volunteer.wml 118) get more robustness, we're going to need to make hidden service
en/volunteer.wml 119) descriptors even less private because we're going to have to mirror them
en/volunteer.wml 120) onto many places. Ideally we'd like to separate the storage/lookup system
en/volunteer.wml 121) from the Tor directory servers entirely. The first problem is that we need
en/volunteer.wml 122) to design a new hidden service descriptor format to a) be ascii rather
en/volunteer.wml 123) than binary for convenience; b) keep the list of introduction points
en/volunteer.wml 124) encrypted unless you know the <tt>.onion</tt> address, so the directory
en/volunteer.wml 125) can't learn them; and c) allow the directories to verify the timestamp
en/volunteer.wml 126) and signature on a hidden service descriptor so they can't be tricked
en/volunteer.wml 127) into giving out fake ones. Second, any reliable distributed storage
en/volunteer.wml 128) system will do, as long as it allows authenticated updates, but as far
en/volunteer.wml 129) as we know no implemented DHT code supports authenticated updates.</li>

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

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

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

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

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

volunteer.html   143) <li>Tor uses TCP for transport and TLS for link
volunteer.html   144) encryption. This is nice and simple, but it means all cells
volunteer.html   145) on a link are delayed when a single packet gets dropped, and
volunteer.html   146) it means we can only reasonably support TCP streams. We have a <a
volunteer.html   147) href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">list

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

en/volunteer.wml 150) href="<svnsandbox>doc/tor-spec-udp.txt">specification for Tor and

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

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

volunteer.html   155) </ol>
volunteer.html   156) 

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

volunteer.html   159) <ol>

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

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

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

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

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

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

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

volunteer.html   235) </ol>
volunteer.html   236) 

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

volunteer.html   239) 

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

volunteer.html   241) 

en/volunteer.wml 242) #include <foot.wmi>