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="Usability"></a>

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

volunteer.html    24) <ol>

en/volunteer.wml  25) <li>We need good ways to intercept DNS requests so they don't "leak" their
en/volunteer.wml  26) request to a local observer while we're trying to be anonymous. (This
en/volunteer.wml  27) happens because the application does the DNS resolve before going to
en/volunteer.wml  28) the SOCKS proxy.)</li>

en/volunteer.wml  29) <li>Tsocks/dsocks items:

en/volunteer.wml  30) <ul>
en/volunteer.wml  31) <li>We need to <a
en/volunteer.wml  32) href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">apply
en/volunteer.wml  33) all our tsocks patches</a> and maintain a new fork. We'll host it if
en/volunteer.wml  34) you want.</li>
en/volunteer.wml  35) <li>We should patch Dug Song's "dsocks" program to use Tor's
en/volunteer.wml  36) <i>mapaddress</i> commands from the controller interface, so we
en/volunteer.wml  37) don't waste a whole round-trip inside Tor doing the resolve before
en/volunteer.wml  38) connecting.</li>
en/volunteer.wml  39) <li>We need to make our <i>torify</i> script detect which of tsocks or
en/volunteer.wml  40) dsocks is installed, and call them appropriately. This probably means
en/volunteer.wml  41) unifying their interfaces, and might involve sharing code between them
en/volunteer.wml  42) or discarding one entirely.</li>
en/volunteer.wml  43) </ul>

en/volunteer.wml  44) </li>

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

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

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

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

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

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

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

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

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

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

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

volunteer.html    70) </ol>
volunteer.html    71) 

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

volunteer.html    74) <ol>

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

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

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

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

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

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

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

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

en/volunteer.wml  95) <li>Help translate the web page and documentation into other
en/volunteer.wml  96) languages. See the <a href="<page translation>">translation
en/volunteer.wml  97) guidelines</a> if you want to help out. We also need people to help

en/volunteer.wml  98) maintain the existing French and Swedish translations -

en/volunteer.wml  99) see the <a href="<page translation-status>">translation status
en/volunteer.wml 100) overview</a>.</li>

en/volunteer.wml 101) <li>Can somebody walk us through whether we want to go the
en/volunteer.wml 102) <a href="http://www.cacert.org/">cacert</a> route for our
en/volunteer.wml 103) SSL <a href="<page documentation>#Developers">SVN repository?</a></li>

volunteer.html   104) </ol>
volunteer.html   105) 

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

volunteer.html   108) <ol>

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

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

en/volunteer.wml 111) call, which uses space in the non-page pool. This means
en/volunteer.wml 112) that a medium sized Tor server will empty the non-page pool, <a
en/volunteer.wml 113) href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">causing

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

en/volunteer.wml 115) instead. One solution would be to teach <a
en/volunteer.wml 116) href="http://www.monkey.org/~provos/libevent/">libevent</a> how to use
en/volunteer.wml 117) overlapped IO rather than select() on Windows, and then adapt Tor to
en/volunteer.wml 118) the new libevent interface.</li>

en/volunteer.wml 119) <li>Because Tor servers need to store-and-forward each cell they handle,
en/volunteer.wml 120) high-bandwidth Tor servers end up using dozens of megabytes of memory
en/volunteer.wml 121) just for buffers. We need better heuristics for when to shrink/expand
en/volunteer.wml 122) buffers. Maybe this should be modelled after the Linux kernel buffer

en/volunteer.wml 123) design, where we have many smaller buffers that link to each other,

en/volunteer.wml 124) rather than monolithic buffers?</li>
en/volunteer.wml 125) <li>We need an official central site to answer "Is this IP address a Tor

en/volunteer.wml 126) exit server?" questions. This should provide several interfaces, including

en/volunteer.wml 127) a web interface and a DNSBL-style interface. It can provide the most
en/volunteer.wml 128) up-to-date answers by keeping a local mirror of the Tor directory

en/volunteer.wml 129) information. The tricky point is that being an exit server is not a
en/volunteer.wml 130) boolean: so the question is actually "Is this IP address a Tor exit
en/volunteer.wml 131) server that can exit to my IP address:port?" The DNSBL interface
en/volunteer.wml 132) will probably receive hundreds of queries a minute, so some smart
en/volunteer.wml 133) algorithms are in order. Bonus points if it does active testing through

en/volunteer.wml 134) each exit node to find out what IP address it's really exiting from.
en/volunteer.wml 135) <a href="<svnsandbox>doc/contrib/torbl-design.txt">Read more here</a>.</li>

en/volunteer.wml 136) <li>Sometimes Tor servers crash, or the computers they're on fall off the
en/volunteer.wml 137) network, or other accidents happen. Some Tor operators have expressed
en/volunteer.wml 138) an interest in signing up to a "notifying" service that periodically
en/volunteer.wml 139) checks whether their Tor server is healthy and sends them a reminder mail
en/volunteer.wml 140) when it's not. Anybody want to write a few cgi scripts, a few web pages,
en/volunteer.wml 141) and set up some sort of wget hack and/or something more complex like <a
en/volunteer.wml 142) href="http://nagios.org/">Nagios</a> to do the monitoring? The first
en/volunteer.wml 143) version could check just the directory port, e.g. looking through the
en/volunteer.wml 144) cached network-status page for the right IP address and port and then
en/volunteer.wml 145) asking for the "/tor/server/authority" page.</li>

en/volunteer.wml 146) <li>It would be great to have a LiveCD that includes the latest
en/volunteer.wml 147) versions of Tor, Polipo or Privoxy, Firefox, Gaim+OTR, etc. There are
en/volunteer.wml 148) two challenges here: first is documenting the system and choices well
en/volunteer.wml 149) enough that security people can form an opinion on whether it should be
en/volunteer.wml 150) secure, and the second is figuring out how to make it easily maintainable,
en/volunteer.wml 151) so it doesn't become quickly obsolete like AnonymOS. Bonus points if
en/volunteer.wml 152) the CD image fits on one of those small-form-factor CDs.</li>

en/volunteer.wml 153) <li>Related to the LiveCD image, we should work on an intuitively secure
en/volunteer.wml 154) and well-documented USB image for Tor and supporting applications. A
en/volunteer.wml 155) lot of the hard part here is deciding what configurations are secure,
en/volunteer.wml 156) documentating these decisions, and making something that is easy to
en/volunteer.wml 157) maintain going forward.</li>

en/volunteer.wml 158) <li>Our preferred graphical front-end for Tor, named
en/volunteer.wml 159) <a href="http://vidalia-project.net/">Vidalia</a>, needs all sorts
en/volunteer.wml 160) of development work.</li>

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

en/volunteer.wml 163) fleshing out the design, modifying many different pieces of Tor, adapting
en/volunteer.wml 164) <a href="http://vidalia-project.net/">Vidalia</a> so it supports the
en/volunteer.wml 165) new features, and planning for deployment.</li>

en/volunteer.wml 166) <li>We need a flexible simulator framework for studying end-to-end
en/volunteer.wml 167) traffic confirmation attacks. Many researchers have whipped up ad hoc
en/volunteer.wml 168) simulators to support their intuition either that the attacks work
en/volunteer.wml 169) really well or that some defense works great. Can we build a simulator
en/volunteer.wml 170) that's clearly documented and open enough that everybody knows it's
en/volunteer.wml 171) giving a reasonable answer? This will spur a lot of new research.
en/volunteer.wml 172) See the entry <a href="#Research">below</a> on confirmation attacks for
en/volunteer.wml 173) details on the research side of this task &mdash; who knows, when it's
en/volunteer.wml 174) done maybe you can help write a paper or three also.</li>
en/volunteer.wml 175) <li>We need a measurement study of <a
en/volunteer.wml 176) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
en/volunteer.wml 177) vs <a href="http://www.privoxy.org/">Privoxy</a>. Is Polipo in fact
en/volunteer.wml 178) significantly faster, once you factor in the slow-down from Tor? Are the
en/volunteer.wml 179) results the same on both Linux and Windows? Related, does Polipo handle
en/volunteer.wml 180) more web sites correctly than Privoxy, or vice versa? Are there stability
en/volunteer.wml 181) issues on any common platforms, e.g. Windows?</li>
en/volunteer.wml 182) <li>Related on the above, would you like to help port <a
en/volunteer.wml 183) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> so it
en/volunteer.wml 184) runs stably and efficiently on Windows?</li>

en/volunteer.wml 185) <li>We need a distributed testing framework. We have unit tests,

en/volunteer.wml 186) but it would be great to have a script that starts up a Tor network, uses
en/volunteer.wml 187) it for a while, and verifies that at least parts of it are working.</li>

en/volunteer.wml 188) <li>Help Mike Perry on his <a
en/volunteer.wml 189) href="http://tor.eff.org/svn/torflow/">TorFlow</a>

en/volunteer.wml 190) library (<a href="http://tor.eff.org/svn/torflow/TODO">TODO</a>):
en/volunteer.wml 191) it's a python library that uses the <a

en/volunteer.wml 192) href="http://tor.eff.org/svn/torctl/doc/howto.txt">Tor controller
en/volunteer.wml 193) protocol</a> to instruct Tor to build circuits in a variety of ways,
en/volunteer.wml 194) and then it measures performance and tries to detect anomalies.</li>

en/volunteer.wml 195) <!--

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

en/volunteer.wml 210) -->

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

volunteer.html   213) OpenSSL. Nobody has ever tested it, though. Does somebody want to get
volunteer.html   214) a card and let us know how it goes?</li>

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

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

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

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

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

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

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

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

en/volunteer.wml 232) <li>Don't like any of these? Look at the <a
en/volunteer.wml 233) href="<svnsandbox>doc/design-paper/roadmap-2007.pdf">Tor development
en/volunteer.wml 234) roadmap</a> for more ideas.</li>
en/volunteer.wml 235) <li>Don't see your idea here? We probably need it anyway! Contact
en/volunteer.wml 236) us and find out.</li>

volunteer.html   237) </ol>
volunteer.html   238) 

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

volunteer.html   241) <ol>

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

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

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

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

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

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

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

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

volunteer.html   300) <li>To let dissidents in remote countries use Tor without being blocked
volunteer.html   301) at their country's firewall, we need a way to get tens of thousands of
volunteer.html   302) relays, not just a few hundred. We can imagine a Tor client GUI that

en/volunteer.wml 303) has a "Tor for Freedom" button at the top that opens a port and relays a

volunteer.html   304) few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too
volunteer.html   305) much hassle, and there are few abuse issues since they're not being exit
volunteer.html   306) nodes.) But how do we distribute a list of these volunteer clients to the
volunteer.html   307) good dissidents in an automated way that doesn't let the country-level
volunteer.html   308) firewalls intercept and enumerate them? Probably needs to work on a

en/volunteer.wml 309) human-trust level. See our <a href="<page documentation>#DesignDoc">early
en/volunteer.wml 310) blocking-resistance design document</a> and our
en/volunteer.wml 311) <a

en/volunteer.wml 312) href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">FAQ

en/volunteer.wml 313) entry</a> on this, and then read the <a
en/volunteer.wml 314) href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">censorship
en/volunteer.wml 315) resistance section of anonbib</a>.</li>

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

volunteer.html   326) </ol>
volunteer.html   327) 

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

volunteer.html   330) 

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

volunteer.html   332) 

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