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 -->

volunteer.html     9) <h2>Seven things everyone can do now:</h2>
volunteer.html    10) <ol>

volunteer.html    11) <li> We need users like you to try Tor out, and let the Tor developers
volunteer.html    12) know about bugs you find or features you don't find.</li>

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

volunteer.html    14) a server</a> to help the Tor network grow.</li>
volunteer.html    15) <li> We especially need people with Windows programming skills to run
volunteer.html    16) an exit server on Windows, to help us debug.</li>

en/volunteer.wml  17) <li> Run a <a href="<cvssandbox>tor/doc/tor-hidden-service.html">Tor hidden

volunteer.html    18) service</a> and put interesting content on it.</li>

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

volunteer.html    20) come up with ideas or designs to contribute to making Tor's interface
volunteer.html    21) and usability better. Free T-shirt for each submission!</li>
volunteer.html    22) <li> Tell your friends! Get them to run servers. Get them to run hidden
volunteer.html    23) services. Get them to tell their friends.</li>

en/volunteer.wml  24) <li> We are looking for funding and sponsors. Take a look at the

en/volunteer.wml  25)  <a href="<page people>">people page</a>, and if you know any
en/volunteer.wml  26)   companies, NGOs, or other organizations that want communications
en/volunteer.wml  27)   security, let them know about us.</li>

volunteer.html    28) </ol>
volunteer.html    29) 

volunteer.html    30) <h2>Installers</h2>

volunteer.html    31) <ol>

volunteer.html    32) <li>Extend our NSIS-based Windows installer to include Privoxy. Include
volunteer.html    33) a preconfigured config file to work well with Tor. We might also want
volunteer.html    34) to include FreeCap -- is it stable enough and useful enough to be
volunteer.html    35) worthwhile?</li>
volunteer.html    36) <li>Develop a way to handle OS X uninstallation

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

volunteer.html    39) each file</a>.</li>

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

volunteer.html    41) needs a maintainer, so we can get back to the business of writing Tor. If
volunteer.html    42) you have RPM fu, please help out.</li>
volunteer.html    43) </ol>
volunteer.html    44) 
volunteer.html    45) <h2>Usability and Interface</h2>
volunteer.html    46) <ol>
volunteer.html    47) <li>We need a way to intercept DNS requests so they don't "leak" while
volunteer.html    48) we're trying to be anonymous. (This happens because the application does
volunteer.html    49) the DNS resolve before going to the SOCKS proxy.) One option is to use
volunteer.html    50) Tor's built-in support for doing DNS resolves; but you need to ask via
volunteer.html    51) our new socks extension for that, and no applications do this yet. A
volunteer.html    52) nicer option is to use Tor's controller interface: you intercept the
volunteer.html    53) DNS resolve, tell Tor about the resolve, and Tor replies with a dummy IP
volunteer.html    54) address. Then the application makes a connection through Tor to that dummy
volunteer.html    55) IP address, and Tor automatically maps it back to the original query.</li>
volunteer.html    56) <li>People running servers tell us they want to have one BandwidthRate
volunteer.html    57) during some part of the day, and a different BandwidthRate at other parts
volunteer.html    58) of the day. Rather than coding this inside Tor, we should have a little

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

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

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

volunteer.html    64) <li>We have a variety of ways to <a
volunteer.html    65) href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">exit
volunteer.html    66) the Tor network from a particular country</a>, but they all
volunteer.html    67) require specifying the nickname of a particular Tor server. It
volunteer.html    68) would be nice to be able to specify just a country, and
volunteer.html    69) have something automatically pick. This requires having some
volunteer.html    70) component that knows what country each Tor node is in. The <a
volunteer.html    71) href="http://serifos.eecs.harvard.edu:8000/cgi-bin/exit.pl">script on
volunteer.html    72) serifos</a> manually parses whois entries for this. Maybe geolocation
volunteer.html    73) data will also work?</li>
volunteer.html    74) <li>Speaking of geolocation data, somebody should draw a map of the Earth
volunteer.html    75) with a pin-point for each Tor server. Bonus points if it updates as the
volunteer.html    76) network grows and changes.</li>
volunteer.html    77) <li>Tor provides anonymous connections, but we don't support
volunteer.html    78) keeping multiple pseudonyms in practice (say, in case you
volunteer.html    79) frequently go to two websites and if anybody knew about both of
volunteer.html    80) them they would conclude it's you). We should find a good approach
volunteer.html    81) and interface for handling pseudonymous profiles in Tor. See <a

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

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

volunteer.html    86) </ol>
volunteer.html    87) 

volunteer.html    88) <h2>Documentation</h2>

volunteer.html    89) <ol>

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

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

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

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

volunteer.html    98) guidelines</a> if you want to help out. We also need people to help
volunteer.html    99) maintain the existing (Italian and German) translations.</li>
volunteer.html   100) <li>Investigate privoxy vs. freecap vs. sockscap for win32 clients. Are
volunteer.html   101) there usability or stability issues that we can track down and
volunteer.html   102) resolve, or at least inform people about?</li>

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

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

volunteer.html   106) <li>Evaluate, create, and <a
volunteer.html   107) href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">document
volunteer.html   108) a list of programs</a> that can be routed through Tor.</li>
volunteer.html   109) <li>We need better documentation for dynamically intercepting

volunteer.html   110) connections and sending them through Tor. tsocks (Linux) and freecap

volunteer.html   111) (Windows) seem to be good candidates.</li>

en/volunteer.wml 112) <li>We have a huge list of <a href="<page support>">potentially useful

volunteer.html   113) programs that interface to Tor</a>. Which ones are useful in which
volunteer.html   114) situations? Please help us test them out and document your results.</li>
volunteer.html   115) </ol>
volunteer.html   116) 
volunteer.html   117) <h2>Coding and Design</h2>
volunteer.html   118) <ol>
volunteer.html   119) <li>We recommend Privoxy as a good scrubbing web proxy, but it's
volunteer.html   120) unmaintained and still has bugs, especially on Windows. While we're at
volunteer.html   121) it, what sensitive information is not kept safe by Privoxy? Are there
volunteer.html   122) other scrubbing web proxies that are more secure?</li>
volunteer.html   123) <li>tsocks appears to be unmaintained: we have submitted several patches
volunteer.html   124) with no response. Can somebody volunteer to start maintaining a new
volunteer.html   125) tsocks branch? We'll help.</li>

volunteer.html   126) <li>Some popular clients that people use with Tor
volunteer.html   127) include <a href="http://gaim.sourceforge.net/">Gaim</a>
volunteer.html   128) and <a href="http://www.xchat.org/">xchat</a>. These
volunteer.html   129) programs support socks, but they don't support <a
volunteer.html   130) href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#SOCKSAndDNS">socks4a
volunteer.html   131) or socks5-with-remote-dns</a>. Please write a patch for them and submit
volunteer.html   132) it to the appropriate people. Let us know if you've written the patch
volunteer.html   133) but you're having trouble getting it accepted.</li>

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

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

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

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

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

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

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

volunteer.html   160) <li>Long ago, we added dmalloc support to Tor, to track leaks. But we
volunteer.html   161) never quite got it working. Is dmalloc unfit for the job? Look at the
volunteer.html   162) --with-dmalloc configure option and go from there.</li>

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

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

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

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

volunteer.html   176) 98</a>.)</li>
volunteer.html   177) <li>Encrypt identity keys on disk, and implement passphrase protection
volunteer.html   178) for them. Right now they're just stored in plaintext.</li>

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

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

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

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

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

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

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

volunteer.html   190) 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   191) requests to TCP requests and send them through Tor?</li>

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

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

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

volunteer.html   202) </ol>
volunteer.html   203) 
volunteer.html   204) <h2>Research</h2>
volunteer.html   205) <ol>

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

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

volunteer.html   228) <li>The "run two servers and wait attack": Tor clients pick a new path
volunteer.html   229) periodically. If the adversary runs an entry and an exit, eventually some
volunteer.html   230) Alice will build a circuit that begins and ends with his nodes. The
volunteer.html   231) current Tor threat model assumes the end-to-end traffic confirmation attack
volunteer.html   232) is trivial, and instead aims to limit the chance that the adversary will
volunteer.html   233) be able to see both sides of a circuit. One way to help this is 
volunteer.html   234) <a href="http://freehaven.net/anonbib/#wright03">helper
volunteer.html   235) nodes</a> -- Alice picks a small set of entry nodes and uses them always.
volunteer.html   236) But in reality, Tor nodes disappear sometimes. So it would seem that the
volunteer.html   237) attack continues, albeit slower than before. How much slower?</li>

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

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

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

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

volunteer.html   287) </ol>
volunteer.html   288) 
volunteer.html   289) Drop by the #tor IRC channel at irc.oftc.net or email tor-volunteer@freehaven.net if you want to help out!
volunteer.html   290) 

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

volunteer.html   292)