remove the old gsoc 2008 stuff from the volunteer page. patch from aleksei. (090590bd5)

en/volunteer.wml
@@ -97,73 +97,17 @@ Farsi translations, for the many Tor users in censored areas.</li>
 <h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>
 
 <p>
-You may find some of these projects to be good <a href="<page
-gsoc>">Google Summer of Code 2008</a> ideas. We have labelled each idea
-with how useful it would be to the overall Tor project
-(priority), how much work we expect it would be (effort level), how much
-clue you should start with (skill level), and which of our <a href="<page
-people>#Core">core developers</a> would be good mentors. There are plenty
-of other good ideas to work on too &mdash; see for example the <a
-href="<svnsandbox>doc/spec/proposals/">current proposals</a> list, or
-just make up your own ideas.
+Here is a list of ideas that were proposed for the <a href="<page gsoc>">Google Summer of Code 2008</a>
+but have not been put into practice. Some of the <a href="<svnsandbox>doc/spec/proposals/">current proposals</a> 
+might also be short on developers. If you think you can help out, <a href="<page contact>"> let us know!</a> 
 </p>
 
 <ol>
 
-<li>
-<b>Tor Exit Scanner improvements</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Mike</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>5</i>
-<br />
-The Tor exit node scanner 'SoaT', part of the <a
-href="<svnsandbox>../torflow/">Torflow project</a>, makes connections out
-of each Tor exit node and compares the content it gets back with what it
-"should" get back. The goal is to notice misconfigured, broken, and even
-malicious exit relays. Alas, the code is
-currently written in rather rickety perl and relies on MD5sums of
-entire documents in order to determine if exit nodes are modifying
-content. The problem with this is threefold: 1) Perl sucks at life.
-2) The scanner can't verify pages that are dynamic, and attackers can
-focus malicious content injection on only those dynamic pages. 3)
-Pages change after a while (or based on GeoIP) and begin generating
-false positives.
-<br />
-Ideally, soat.pl would be reimplemented in a sane language with a
-robust html parser library (since the rest of Torflow is in Python
-that would be nice, but it is not required), and calculate signatures only for
-tags and content likely to be targeted by a malicious attacker (script
-tags, object links, images, css). It should also be robust in the face of
-changes to content outside of Tor, and ultimately even GeoIP localized
-content.
-<br />
-This scanner would likely be run by the Directory Authorities and
-report its results to the control port via the AuthDirBadExit config
-setting.
-<br />
-</li>
-
 <li>
 <b>Tor Node Scanner improvements</b>
 <br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium to High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Mike</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>1</i>
-<br />
-Similar to the exit scanner (or perhaps even during exit scanning),
+Similar to the SoaT exit scanner (or perhaps even during exit scanning),
 statistics can be gathered about the reliability of nodes. Nodes that
 fail too high a percentage of their circuits should not be given
 Guard status. Perhaps they should have their reported bandwidth
@@ -190,14 +134,6 @@ currently does not exist and would need to be developed as well.
 <li>
 <b>Help track the overall Tor Network status</b>
 <br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Roger, Nick, Mike</i>
-<br />
 It would be great to set up an automated system for tracking network
 health over time, graphing it, etc. Part of this project would involve
 inventing better metrics for assessing network health and growth. Is the
@@ -216,87 +152,9 @@ kept separate. Speaking of the Tor Status pages, take a look at Roger's
 Status wish list</a>.
 </li>
 
-<li>
-<b>Tor path selection improvements</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Low to Medium</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Roger, Nick, Mike</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>3</i>
-<br />
-Some simple improvements can be made to Tor's path selection to vastly
-improve Tor speed. For instance, some of the (unofficial) <a
-href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
-Performance Recommendations</a> on the wiki are to increase the number of
-guards and decrease the CircuitBuildTimeout. Ideally, the client would
-<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn
-these values by gathering statistics on circuit construction
-time</a> (and/or using values gained from Torflow), and set the timeouts
-low enough such that some high percentile (75%, 90%, 1-stddev?) of
-circuits succeed, yet extremely slow nodes are avoided. This would
-involve some statistics gathering+basic research, and some changes to
-Tor path selection code.
-<br />
-In addition, to improve path security, some elements from the <a
-href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
-Hop Paths proposal</a> could be done as part of this (since it will
-likely touch the same code anyways), regardless of the adoption of
-that proposal. In particular, clients probably should avoid guards that
-seem to fail an excessive percentage of their circuits through them,
-and non-firewalled clients should issue a warning if they are only able
-to connect to a limited set of guard nodes. See also
-<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this
-or-dev post</a>.
-</li>
-
-<li>
-<b>Translation Wiki</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Jacob</i>
-<br />
-We need a way to edit and translate sections of the website. Currently
-the website is made up of a bunch of <a href="<svnwebsite>en/">wml
-files</a>, and <a href="<page translation>">translators</a> fetch these
-wml files, translate them in an editor, and either send us the translation
-or use svn to commit them back. The current "cost" of publication of
-website changes is quite high even for English language users. For a
-single word change or any type of
-minor change, the page may never be corrected or translated. It would
-be nice to have a wiki that was specifically geared towards translation
-and would somehow track the upstream (English) versions to indicate when
-a fresh translation is needed, like our current
-<a href="<page translation-status>">translation status page</a>. This
-seems mostly like a job for a wiki
-integrator or wiki software author. Certainly the person would need to
-be interested in human languages and translation. They should at least
-be minimally familiar with what Tor is; but they would not have to interact
-with the software, only the documentation and the website.
-</li>
-
 <li>
 <b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
 <br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Peter, Matt</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>1</i>
-<br />
 Vidalia currently doesn't play nicely on Debian and Ubuntu with the
 default Tor packages. The current Tor packages automatically start Tor
 as a daemon running as the debian-tor user and (sensibly) do not have a
@@ -333,7 +191,7 @@ we've come up with is for Vidalia to write out a temporary torrc file
 and ask the user to manually move it to <code>/etc/tor/torrc</code>,
 but that's bad because users shouldn't have to mess with files directly.
 <br />
-A student undertaking this project should have prior knowledge of
+A person undertaking this project should have prior knowledge of
 Debian package management and some C++ development experience. Previous
 experience with Qt is helpful, but not required.
 </li>
@@ -341,14 +199,6 @@ experience with Qt is helpful, but not required.
 <li>
 <b>Improving Tor's ability to resist censorship</b>
 <br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Nick</i>
-<br />
 The Tor 0.2.0.x series makes <a
 href="<svnsandbox>doc/design-paper/blocking.html">significant
 improvements</a> in resisting national and organizational censorship.
@@ -376,14 +226,6 @@ then trading off censorship resistance with usability and robustness.
 <li>
 <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Matt, Jacob</i>
-<br />
 We're in need of a good authenticated-update framework.
 Vidalia already has the ability to notice when the user is running an
 outdated or unrecommended version of Tor, using signed statements inside
@@ -406,26 +248,18 @@ then discuss the design with other developers to assess any security
 issues. The student will then implement their framework (or integrate
 an existing one) and test it.
 <br />
-A student undertaking this project should have good C++ development
-experience. Previous experience with Qt is helpful, but not required. The
-student should also have a good understanding of common security
+A person undertaking this project should have good C++ development
+experience. Previous experience with Qt is helpful, but not required. One
+should also have a good understanding of common security
 practices, such as package signature verification. Good writing ability
 is also important for this project, since a vital step of the project
-will be producing a design document for others to review and discuss
-with the student prior to implementation.
+will be producing a design document to review and discuss
+with others prior to implementation.
 </li>
 
 <li>
 <b>An Improved and More Usable Network Map in Vidalia</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Matt</i>
-<br />
 One of Vidalia's existing features is a network map that shows the user
 the approximate geographic location of relays in the Tor network and
 plots the paths the user's traffic takes as it is tunneled through the
@@ -438,13 +272,13 @@ for users to click on a particular relay or a country containing one or
 more Tor exit relays and say, "I want my connections to foo.com to exit
 from here."
 <br />
-This project will first involve the student getting familiar with Vidalia
-and the Marble widget's API. The student will then integrate the widget
+This project will first involve getting familiar with Vidalia
+and the Marble widget's API. One will then integrate the widget
 into Vidalia and customize Marble to be better suited for our application,
 such as making circuits clickable, storing cached map data in Vidalia's
 own data directory, and customizing some of the widget's dialogs.
 <br />
-A student undertaking this project should have good C++ development
+A person undertaking this project should have good C++ development
 experience. Previous experience with Qt and CMake is helpful, but not
 required.
 </li>
@@ -452,14 +286,6 @@ required.
 <li>
 <b>Tor Controller Status Event Interface</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Matt, Roger</i>
-<br />
 There are a number of status changes inside Tor of which the user may need
 to be informed. For example, if the user is trying to set up his Tor as a
 relay and Tor decides that its ports are not reachable from outside
@@ -480,10 +306,10 @@ little badge on Vidalia's tray icon that alerts the user to new status
 events they should look at. Double-clicking the icon could bring up a
 dialog that summarizes recent status events in simple terms and maybe
 suggests a remedy for any negative events if they can be corrected by
-the user. Of course, this is just an example and the student is free to
+the user. Of course, this is just an example and one is free to
 suggest another approach.
 <br />
-A student undertaking this project should have good UI design and layout
+A person undertaking this project should have good UI design and layout
 and some C++ development experience. Previous experience with Qt and
 Qt's Designer will be very helpful, but are not required. Some
 English writing ability will also be useful, since this project will
@@ -496,16 +322,6 @@ design/Photoshop fu, since we might want/need some shiny new icons too.
 <b>Improvements on our active browser configuration tester</b> -
 <a href="https://check.torproject.org/">https://check.torproject.org/</a>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Low</i>
-<br />
-Skill Level: <i>Low to Medium</i>
-<br />
-Likely Mentors: <i>Jacob, Steven</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>1</i>
-<br />
 We currently have a functional web page to detect if Tor is working. It
 has a few places where it falls short. It requires improvements with
 regard to default languages and functionality. It currently only responds
@@ -529,14 +345,6 @@ href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
 <b>Improvements on our DNS Exit List service</b> -
 <a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Low</i>
-<br />
-Skill Level: <i>Low</i>
-<br />
-Likely Mentors: <i>Jacob, Tup</i>
-<br />
 The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
 is written by our fabulous anonymous
 contributer Tup. It's a DNS server written in Haskell that supports part of our <a
@@ -557,16 +365,6 @@ torel-design.txt suggestions.
 <li>
 <b>Testing integration of Tor with web browsers for our end users</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Jacob, Mike, Greg</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>1</i>
-<br />
 The Tor project currently lacks a solid test suite to ensure that a
 user has a properly and safely configured web browser. It should test for as
 many known issues as possible. It should attempt to decloak the
@@ -575,29 +373,20 @@ kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
 href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
 with their proof of concept code, bug issues, etc</a>. HD Moore runs
 the <a href="http://metasploit.com/research/projects/decloak/">metasploit
-decloak website</a>. A student interested in defending Tor could start
+decloak website</a>. A person interested in defending Tor could start
 by collecting as many workable and known methods for decloaking a
 Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
-be helpful as a start.) The student should be familiar with the common
-pitfalls but
+be helpful as a start.) One should be familiar with the common pitfalls but
 possibly have new methods in mind for implementing decloaking issues. The
 website should ensure that it tells a user what their problem is. It
 should help them to fix the problem or direct them to the proper support
-channels. The student should be closely familiar with using Tor and how
+channels. The person should also be closely familiar with using Tor and how
 to prevent Tor information leakage.
 </li>
 
 <li>
 <b>Libevent and Tor integration improvements</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Nick</i>
-<br />
 Tor should make better use of the more recent features of Niels
 Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
 library.  Tor already uses Libevent for its low-level asynchronous IO
@@ -614,14 +403,6 @@ Also tricky will be adding rate-limiting to Libevent.
 <li>
 <b>Tuneup Tor!</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Nick, Roger, Mike</i>
-<br />
 Right now, Tor relays measure and report their own bandwidth, and Tor
 clients choose which relays to use in part based on that bandwidth.
 This approach is vulnerable to
@@ -634,7 +415,7 @@ Tor should possibly measure bandwidth in a more distributed way, perhaps
 as described in the
 <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
 Tor"</a> paper
-by Snader and Borisov. A student could use current testing code to
+by Snader and Borisov. One could use current testing code to
 double-check this paper's findings and verify the extent to which they
 dovetail with Tor as deployed in the wild, and determine good ways to
 incorporate them into their suggestions Tor network without adding too
@@ -646,14 +427,6 @@ authorities.
 <li>
 <b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
 <br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Jacob, Andrew</i>
-<br />
 It would be useful to have automated build processes for Windows and
 probably other platforms. The purpose of having a continuous integration
 build environment is to ensure that Windows isn't left behind for any of
@@ -683,14 +456,6 @@ changes in performance on machines in different roles automatically.
 <li>
 <b>Improve our unit testing process</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Nick</i>
-<br />
 Tor needs to be far more tested. This is a multi-part effort. To start
 with, our unit test coverage should rise substantially, especially in
 the areas outside the utility functions. This will require significant
@@ -710,16 +475,6 @@ changes in performance on machines in different roles automatically.
 <li>
 <b>Help revive an independent Tor client implementation</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Karsten, Nick</i>
-<br />
-Applications as of 1 Apr 00::00 UTC: <i>4</i>
-<br />
 Reanimate one of the approaches to implement a Tor client in Java,
 e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
 project</a>, and make it run on <a
@@ -730,59 +485,17 @@ protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
 directory protocol</a>. Further, support for requesting or even
 providing Tor hidden services would be neat, but not required.
 <br />
-The student should be able to understand and write new Java code, including
+A perspective developer should be able to understand and write new Java code, including
 a Java cryptography API. Being able to read C code would be helpful,
-too. The student should be willing to read the existing documentation,
+too. One should be willing to read the existing documentation,
 implement code based on it, and refine the documentation
 when things are underdocumented. This project is mostly about coding and
 to a small degree about design.
 </li>
 
-<li>
-<b>Automatic system tests and automatically starting private Tor networks</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Karsten, Nick, Roger</i>
-<br />
-Applications as of 1 Apr 00:00 UTC: <i>2</i>
-<br />
-Write a tool that runs automatic system tests in addition
-to the existing unit tests. The Java-based Tor simulator <a
-href="https://svn.torproject.org/svn/puppetor/trunk/">PuppeTor</a>
-might be a good start for starting up a private Tor network, using it
-for a while, and verifying that at least parts of it are working. This
-project requires to conceive a blueprint for performing system tests
-of private Tor networks, before starting to code. Typical types of
-tests range from performing single requests over the private network to
-manipulating exchanged messages and see if nodes handle corrupt messages
-appropriately.
-<br />
-The student should be able to obtain a good understanding
-of how Tor works and what problems and bugs could arise to design good
-test cases. Understanding the existing Tor code structure and documentation is
-vital. If PuppeTor is used, the student should also be able to understand
-and possibly extend an existing Java application. This project is partly
-about design and partly about coding.
-</li>
-
 <li>
 <b>Bring moniTor to life</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Low to Medium</i>
-<br />
-Likely Mentors: <i>Karsten, Jacob</i>
-<br />
-Applications as of 1 Apr 00::00 UTC: <i>2</i>
-<br />
 Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
 management tool for Tor relays. The purpose of such a tool would be
 to monitor a local Tor relay via its control port and include useful
@@ -791,7 +504,7 @@ would dynamically update its content like top does for Linux processes.
 <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
 or-dev post</a> might be a good first read.
 <br />
-The student should be familiar
+A person interested in this should be familiar
 with or willing to learn about administering a Tor relay and configuring
 it via its control port. As an initial prototype is written in Python,
 some knowledge about writing Python code would be helpful, too. This
@@ -802,14 +515,6 @@ tool and designing its interface, and one part lots of coding.
 <li>
 <b>Torbutton improvements</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Mike</i>
-<br/>
 Torbutton has a number of improvements that can be made in the post-1.2
 timeframe. Most of these are documented as feature requests in the <a
 href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">Torbutton
@@ -829,14 +534,6 @@ with not too much involvement in the Tor internals.
 <li>
 <b>Porting Polipo to Windows</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Andrew, Steven, Roger</i>
-<br />
 Help port <a
 href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
 Windows. Example topics to tackle include:
@@ -856,34 +553,17 @@ menu options. Double bonus if it's cross-platform compatible.
 <li>
 <b>Make our diagrams beautiful and automated</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Low</i>
-<br />
-Skill Level: <i>Low</i>
-<br />
-Likely Mentors: <i>Andrew</i>
-<br />
 We need a way to generate the website diagrams (for example, the "How
 Tor Works" pictures on the <a href="<page overview>">overview page</a>
 from source, so we can translate them as UTF-8 text rather than edit
 them by hand with Gimp. We might want to
 integrate this as an wml file so translations are easy and images are
-generated in multiple languages whenever we build the website. See the
-"Translation Wiki" idea above.
+generated in multiple languages whenever we build the website. 
 </li>
 
 <li>
 <b>Improve the LiveCD offerings for the Tor community</b>
 <br />
-Priority: <i>Low</i>
-<br />
-Effort Level: <i>Low</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Anonym, Jacob, Roger</i>
-<br />
 How can we make the <a
 href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
 easier to maintain, improve, and document?
@@ -892,14 +572,6 @@ easier to maintain, improve, and document?
 <li>
 <b>Rework and extend Blossom</b>
 <br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium to High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Goodell</i>
-<br />
 Rework and extend Blossom (a tool for monitoring and
 selecting appropriate Tor circuits based upon exit node requirements
 specified by the user) to gather data in a self-contained way, with
@@ -924,14 +596,6 @@ the core of the Blossom effort.
 <li>
 <b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
 <br />
-Priority: <i>Low</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Goodell</i>
-<br />
 Develop and implement a means of affording Blossom
 users the ability to qualitatively describe the exit node that they
 want.  The Internet is an inconsistent place: some Tor exit nodes see
@@ -964,7 +628,7 @@ roadmap</a> for more ideas.
 
 </ol>
 
-<h2><a class="anchor" href="#Coding">Coding and Design</a></h2>
+<h2><a class="anchor" href="#Coding">Other Coding and Design related ideas</a></h2>
 <ol>
 <li>Tor relays don't work well on Windows XP. On
 Windows, Tor uses the standard <tt>select()</tt> system

tor-webwml.git
