[or-cvs] revamp again

[arma@xxxxxxxx]

Update of /home2/or/cvsroot/website
In directory moria:/home/arma/work/onion/cvs/website

Modified Files:
	volunteer.html 
Log Message:
revamp again


Index: volunteer.html
===================================================================
RCS file: /home2/or/cvsroot/website/volunteer.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- volunteer.html	22 Sep 2005 02:37:39 -0000	1.20
+++ volunteer.html	22 Sep 2005 03:21:56 -0000	1.21
@@ -44,59 +44,116 @@
 <!-- PUT CONTENT AFTER THIS TAG -->
 <h2>Seven things everyone can do now:</h2>
 <ol>
-<li> We need users like you to try Tor out, and let the Tor developers know about bugs you find or features you don't find.</li>
-<li> Please consider <a href="/cvs/tor/doc/tor-doc-server.html">running a server</a> to help the Tor network grow.</li>
-<li> We especially need people with Windows programming skills to run an exit server on Windows, to help us debug.</li>
-<li> Run a <a href="/cvs/tor/doc/tor-hidden-service.html">Tor hidden service</a> and put interesting content on it.</li>
-<li> Take a look at the <a href="/gui/">Tor GUI Competition</a>, and come up with ideas or designs to contribute to making the Tor interface better. Free T-shirt for each submission!</li>
-<li> Tell your friends! Get them to run servers. Get them to run hidden services. Get them to tell their friends.</li>
-<li> Consider joining the <a href="http://secure.eff.org/tor";>Electronic Frontier Foundation</a>. More EFF donations means more freedom in the world, including more Tor development.</li>
+<li> We need users like you to try Tor out, and let the Tor developers
+know about bugs you find or features you don't find.</li>
+<li> Please consider <a href="/cvs/tor/doc/tor-doc-server.html">running
+a server</a> to help the Tor network grow.</li>
+<li> We especially need people with Windows programming skills to run
+an exit server on Windows, to help us debug.</li>
+<li> Run a <a href="/cvs/tor/doc/tor-hidden-service.html">Tor hidden
+service</a> and put interesting content on it.</li>
+<li> Take a look at the <a href="/gui/">Tor GUI Competition</a>, and
+come up with ideas or designs to contribute to making Tor's interface
+and usability better. Free T-shirt for each submission!</li>
+<li> Tell your friends! Get them to run servers. Get them to run hidden
+services. Get them to tell their friends.</li>
+<li> Consider joining the <a href="http://secure.eff.org/tor";>Electronic
+Frontier Foundation</a>. More EFF donations means more freedom in the
+world, including more Tor development.</li>
 </ol>
 
-<h2>Usability and Installers</h2>
+<h2>Installers</h2>
 <ol>
-<li>Make an entry to the <a href="/gui/">GUI competition</a>. This
-requires looking at how Tor interacts with the operating system and
-other applications, deciding where the critical usability issues are,
-and trying to make an application (or applet or plugin) that helps the
-user experience.</li>
-<li>Extend our NSIS-based windows installer to include FreeCap and/or
-Privoxy. When we ship Privoxy, include a config file that's preconfigured
-to work well with Tor.</li>
-<li>Develop a way to handle OS X installation and uninstallation.</li>
-<li>Choosing exit node by meta-data, e.g. country.</li>
-<li>Tor provides anonymous connections, but if you want to keep multiple
-pseudonyms in practice (say, in case you frequently go to two websites
-and if anybody knew about both of them they would conclude it's you), we
-don't support that well yet. We should find a good approach and
-interface for handling pseudonymous profiles in Tor. See <a
+<li>Extend our NSIS-based Windows installer to include Privoxy. Include
+a preconfigured config file to work well with Tor. We might also want
+to include FreeCap -- is it stable enough and useful enough to be
+worthwhile?</li>
+<li>Develop a way to handle OS X uninstallation
+that is more automated than telling people to <a
+href="http://tor.eff.org/doc/tor-doc-osx.html#uninstall";>manually remove
+each file</a>.</li>
+<li>Our <a href="http://tor.eff.org/cvs/tor/tor.spec.in";>RPM spec file</a>
+needs a maintainer, so we can get back to the business of writing Tor. If
+you have RPM fu, please help out.</li>
+</ol>
+
+<h2>Usability and Interface</h2>
+<ol>
+<li>We need a way to intercept DNS requests so they don't "leak" while
+we're trying to be anonymous. (This happens because the application does
+the DNS resolve before going to the SOCKS proxy.) One option is to use
+Tor's built-in support for doing DNS resolves; but you need to ask via
+our new socks extension for that, and no applications do this yet. A
+nicer option is to use Tor's controller interface: you intercept the
+DNS resolve, tell Tor about the resolve, and Tor replies with a dummy IP
+address. Then the application makes a connection through Tor to that dummy
+IP address, and Tor automatically maps it back to the original query.</li>
+<li>People running servers tell us they want to have one BandwidthRate
+during some part of the day, and a different BandwidthRate at other parts
+of the day. Rather than coding this inside Tor, we should have a little
+script that speaks via the <a href="/gui/">Tor Controller Interface</a>,
+and does a setconf to change the bandwidth rate. Perhaps it would run out
+of cron, or perhaps it would sleep until appropriate times and then do
+its tweak (that's probably more portable). Can somebody write one for us
+and we'll put it into <a href="/cvs/tor/contrib/">tor/contrib/</a>?</li>
+<li>We have a variety of ways to <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit";>exit
+the Tor network from a particular country</a>, but they all
+require specifying the nickname of a particular Tor server. It
+would be nice to be able to specify just a country, and
+have something automatically pick. This requires having some
+component that knows what country each Tor node is in. The <a
+href="http://serifos.eecs.harvard.edu:8000/cgi-bin/exit.pl";>script on
+serifos</a> manually parses whois entries for this. Maybe geolocation
+data will also work?</li>
+<li>Speaking of geolocation data, somebody should draw a map of the Earth
+with a pin-point for each Tor server. Bonus points if it updates as the
+network grows and changes.</li>
+<li>Tor provides anonymous connections, but we don't support
+keeping multiple pseudonyms in practice (say, in case you
+frequently go to two websites and if anybody knew about both of
+them they would conclude it's you). We should find a good approach
+and interface for handling pseudonymous profiles in Tor. See <a
 href="http://archives.seul.org/or/talk/Dec-2004/msg00086.html";>this
-post</a> and <a href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html";>followup</a> for details.</li>
+post</a> and <a
+href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html";>followup</a>
+for details.</li>
 </ol>
 
-<h2>Coding, Design, and Software Development</h2>
+<h2>Documentation</h2>
 <ol>
-<li>We need a better option for a scrubbing web proxy than
-just Privoxy, since it's unmaintained and still has bugs, especially
-on Windows. While we're at it, what sensitive information is not
-kept safe by Privoxy? Are there other scrubbing web proxies that are
-more secure?</li>
-<li>We need better applications for dynamically intercepting
+<li>Please volunteer to help maintain this website: code, content,
+css, layout.</li>
+<li>We have too much documentation --- it's spread out too much and
+duplicates itself in places. Please send us patches, pointers, and
+confusions about the documentation so we can clean it up.</li>
+<li>Help translate the web page and documentation into other
+languages. See the <a href="translation.html">translation
+guidelines</a> if you want to help out. We also need people to help
+maintain the existing (Italian and German) translations.</li>
+<li>Investigate privoxy vs. freecap vs. sockscap for win32 clients. Are
+there usability or stability issues that we can track down and
+resolve, or at least inform people about?</li>
+<li>Evaluate, create, and <a
+href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO";>document
+a list of programs</a> that can be routed through Tor.</li>
+<li>We need better documentation for dynamically intercepting
 connections and sending them through Tor. tsocks (Linux) and freecap
-(Windows) seem to be good candidates, and there are a variety of other
-possibilities listed at the bottom of <a href="/support.html">our support
-page</a>.</li>
-<li>Speaking of tsocks, it appears to be unmaintained: we have submitted
-several patches with no response. Can somebody volunteer to start
-maintaining a new tsocks branch? We'll help.</li>
-<li>We need a way to intercept DNS requests so they don't "leak" while
-we're trying to be anonymous. One option is to use Tor's built-in
-support for doing DNS resolves; but you need to ask via our new socks
-extension for that, and so no applications do this yet. Another option
-is to use Tor's controller interface: the application connects to Tor,
-hands it the DNS query, and Tor replies with a dummy IP address. Then
-the application makes a connection through Tor to that dummy IP address,
-and Tor automatically maps it back to the original query.</li>
+(Windows) seem to be good candidates.</li>
+<li>We have a huge list of <a href="/support.html">potentially useful
+programs that interface to Tor</a>. Which ones are useful in which
+situations? Please help us test them out and document your results.</li>
+</ol>
+
+<h2>Coding and Design</h2>
+<ol>
+<li>We recommend Privoxy as a good scrubbing web proxy, but it's
+unmaintained and still has bugs, especially on Windows. While we're at
+it, what sensitive information is not kept safe by Privoxy? Are there
+other scrubbing web proxies that are more secure?</li>
+<li>tsocks appears to be unmaintained: we have submitted several patches
+with no response. Can somebody volunteer to start maintaining a new
+tsocks branch? We'll help.</li>
 <li>Right now the hidden service descriptors are being stored on just a few
 directory servers. This is bad for privacy and bad for robustness. To get
 more robustness, we're going to need to make hidden service descriptors
@@ -108,26 +165,27 @@
 next step?</li>
 <li>Tor exit servers need to do many DNS resolves in parallel. But
 gethostbyname() is poorly designed --- it blocks until it has finished
-resolving a query --- so it requires its own thread or process. So
-Tor is forced to spawn many separate DNS "worker" threads. There are
-some asynchronous DNS libraries out there, but traditionally they are
-buggy and abandoned. There are rumors that some of them are becoming
-better. Are any of them stable, fast, clean, and free software? If
-so (or if we can make that so), we should integrate them into Tor
-so we don't need to spawn dozens of dns resolver threads. See <a
+resolving a query --- so it requires its own thread or process. So Tor
+is forced to spawn many separate DNS "worker" threads. There are some
+asynchronous DNS libraries out there, but historically they are buggy and
+abandoned. Are any of them stable, fast, clean, and free software? If so
+(or if we can make that so), we should integrate them into Tor. See <a
 href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html";>Agl's
-post</a> for a potential start.</li>
+post</a> for one potential approach.</li>
 <li>Currently Tor ships with its own AES, since when we started OpenSSL
 had missing/broken AES support. But now that it's gotten more mainstream,
 we should change things so we only use our bundled AES if OpenSSL doesn't
 support it natively.</li>
+<li>Tor 0.1.1.x includes support for hardware crypto accelerators via
+OpenSSL. Nobody has ever tested it, though. Does somebody want to get
+a card and let us know how it goes?</li>
 <li>Because Tor servers need to store-and-forward each cell they handle,
 high-bandwidth Tor servers end up using dozens of megabytes of memory
 just for buffers. We need better heuristics for when to shrink/expand
 buffers. Maybe this should be modelled after the Linux kernel buffer
 design, where you have many smaller buffers that link to each other,
 rather than monolithic buffers?</li>
-<li>How do ulimits work on Win32, anyway? We're having problems
+<li>How do ulimits work on Win32, anyway? We're having problems,
 especially on older Windowses with people running out of file
 descriptors, connection buffer space, etc. (We should handle
 WSAENOBUFS as needed, look at the MaxConnections registry entry,
@@ -137,19 +195,10 @@
 98</a>.)</li>
 <li>Encrypt identity keys on disk, and implement passphrase protection
 for them. Right now they're just stored in plaintext.</li>
-<li>Periodically people running servers tell us they want to have one
-BandwidthRate during some part of the day, and a different BandwidthRate
-at other parts of the day. Rather than coding this inside Tor, we
-should have a little script that speaks via the <a href="/gui/">Tor
-Controller Interface</a>, and does a setconf to change the bandwidth
-rate. Perhaps it would run out of cron, or perhaps it would sleep
-until appropriate times and then do its tweak (that's probably more
-portable). Can somebody write one for us and we'll put it into <a
-href="/cvs/tor/contrib/">tor/contrib/</a>?</li>
 <li>Patches to Tor's autoconf scripts. First, we'd like our configure.in
 to handle cross-compilation, e.g. so we can build Tor for obscure
-platforms like the Linksys WRTG54. Second, we'd like to make with-ssl-dir
-disable the search for ssl's libraries.</li>
+platforms like the Linksys WRTG54. Second, we'd like the with-ssl-dir
+option to disable the search for ssl's libraries.</li>
 <li>Implement reverse DNS requests inside Tor (already specified in
 Section 5.4 of <a href="/cvs/tor/doc/tor-spec.txt">tor-spec.txt</a>).</li>
 <li>Perform a security analysis of Tor with <a
@@ -157,42 +206,46 @@
 if there good fuzzing libraries out there for what we want. Win fame by
 getting credit when we put out a new release because of you!</li>
 <li>How hard is it to patch bind or a DNS proxy to redirect requests to
-Tor via our tor-resolve socks extension? What about to convert UDP DNS
+Tor via our <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications";>tor-resolve socks extension</a>? What about to convert UDP DNS
 requests to TCP requests and send them through Tor?</li>
-</ol>
-
-<h2>Documentation</h2>
-<ol>
-<li>Volunteer to help maintain this website: code, content, css,
-layout.</li>
-<li>We have too much documentation --- it's spread out too much and
-duplicates itself in places.</li>
-<li>Help translate the web page and documentation into other
-languages.  See the <a href="translation.html">translation
-guidelines</a> if you want to help out.</li>
-<li>Investigate privoxy vs. freecap vs. sockscap for win32 clients. Are
-there usability or stability issues that we can track down and
-resolve?</li>
-<li>Evaluate, create, and <a
-href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO";>document
-a list of programs</a> that can be routed through Tor.</li>
-<li>We have a huge list of <a href="/support.html"> potentially useful
-programs to interface to Tor</a>. Which ones are useful in which
-situations? Please help us test them out and document your results.</li>
+<li>We're not that far from having IPv6 support for destination addresses
+(at exit nodes). If you care strongly about IPv6, that's probably the
+first place to start.</li>
 </ol>
 
 <h2>Research</h2>
 <ol>
-<li>To let dissidents in remote countries use Tor without being blocked
-at their country's firewall, we need a way to get tens of thousands of
-relays, not just a few hundred. We can imagine a Tor client GUI that
-has a "help China" button at the top that opens a port and relays a
-few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too
-much hassle, and there are few abuse issues since they're not being exit
-nodes.) But how do we distribute a list of these volunteer clients to the
-good dissidents in an automated way that doesn't let the country-level
-firewalls intercept and enumerate them? Probably needs to work on a
-human-trust level.</li>
+<li>The "website fingerprinting attack": make a list of a few
+hundred popular websites, download their pages, and make a set of
+"signatures" for each site. Then observe a Tor client's traffic. As
+you watch him receive data, you quickly approach a guess about which
+(if any) of those sites he is visiting. First, how effective is
+this attack on the deployed Tor codebase? Then start exploring
+defenses: for example, we could change Tor's cell size from 512
+bytes to 1024 bytes, we could employ padding techniques like <a
+href="http://freehaven.net/anonbib/#timing-fc2004";>defensive dropping</a>,
+or we could add traffic delays. How much of an impact do these have,
+and how much usability impact (using some suitable metric) is there from
+a successful defense in each case?</li>
+<li>The "end-to-end traffic confirmation attack": by watching traffic at
+Alice and at Bob, we can compare traffic signatures and become convinced
+that we're watching the same stream. So far Tor accepts this as a fact
+of life and assumes this attack is trivial in all cases. First of all,
+is that actually true? How much traffic of what sort of distribution is
+needed before the adversary is confident he has won? Are there scenarios
+(e.g. not transmitting much) that slow down the attack? Do some traffic
+padding or traffic shaping schemes work better than others?</li>
+<li>The "routing zones attack": most of the literature thinks of
+the network path between Alice and her entry node (and between the
+exit node and Bob) as a single link on some graph. In practice,
+though, the path traverses many autonomous systems (ASes), and <a
+href="http://freehaven.net/anonbib/#feamster:wpes2004";>it's not uncommon
+that the same AS appears on both the entry path and the exit path</a>.
+Unfortunately, to accurately predict whether a given Alice, entry,
+exit, Bob quad will be dangerous, we need to download an entire Internet
+routing zone and perform expensive operations on it. Are there practical
+approximations, such as avoiding IP addresses in the same /8 network?</li>
+<!--<li>Find ideal churn rate for helper nodes; how safe is it?</li> -->
 <li>Tor doesn't work very well when servers have asymmetric bandwidth
 (e.g. cable or DSL). Because Tor has separate TCP connections between
 each hop, if the incoming bytes are arriving just fine and the outgoing
@@ -212,35 +265,19 @@
 href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php";>ssh
 throughput experiment</a>. We'll need to measure and tweak, and maybe
 overhaul if the results are good.</li>
-<li>The "website fingerprinting attack": make a list of a few
-hundred popular websites, download their pages, and make a set of
-"signatures" for each site. Then observe a Tor client's traffic. As
-you watch him receive data, you quickly approach a guess about
-which (if any) of those sites he is visiting. Do this attack on the
-deployed Tor network, and find out how effective it is. Then start
-exploring defenses: for example, we could change Tor's cell size from
-512 bytes to 1024 bytes, we could employ padding techniques like <a
-href="http://freehaven.net/anonbib/#timing-fc2004";>defensive dropping</a>,
-or we could add traffic delays. How much of an impact do these have,
-and how much usability impact (using some suitable metric) is there from
-a successful defense in each case?</li>
-<li>The "end-to-end traffic confirmation attack": by watching traffic at
-Alice and at Bob, we can compare traffic signatures and become convinced
-that we're watching the same stream. So far Tor accepts this as a fact
-of life and assumes this attack is trivial in all cases. First of all,
-is that actually true? How much traffic of what sort of distribution is
-needed before the adversary is confident he has won? Are there scenarios
-(e.g. not transmitting much) that slow down the attack? Do some traffic
-padding or traffic shaping schemes work better than others?
-</li>
-
-<li>Come up with practical approximations to picking entry and exit in
-    different routing zones.</li>
-<li>Find ideal churn rate for helper nodes; how safe is it?</li>
-<li>Is exiting from the middle of the circuit always a bad idea?</li>
-<li>IPv6 support (For exit addresses)
+<li>To let dissidents in remote countries use Tor without being blocked
+at their country's firewall, we need a way to get tens of thousands of
+relays, not just a few hundred. We can imagine a Tor client GUI that
+has a "help China" button at the top that opens a port and relays a
+few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too
+much hassle, and there are few abuse issues since they're not being exit
+nodes.) But how do we distribute a list of these volunteer clients to the
+good dissidents in an automated way that doesn't let the country-level
+firewalls intercept and enumerate them? Probably needs to work on a
+human-trust level.</li>
+<!-- <li>Is exiting from the middle of the circuit always a bad idea?</li>
 <li>It's not that hard to DoS Tor servers or dirservers. Are puzzles the
-right answer? What other practical approaches are there?</li>
+right answer? What other practical approaches are there?</li> -->
 </ol>
 
 Drop by the #tor IRC channel at irc.oftc.net or email tor-volunteer@xxxxxxxxxxxxx if you want to help out!