[or-cvs] r21922: {website} some more cleanups on the ideas list (website/trunk/en)

Thu Mar 11 09:45:29 UTC 2010

Author: arma
Date: 2010-03-11 09:45:29 +0000 (Thu, 11 Mar 2010)
New Revision: 21922

Modified:
   website/trunk/en/volunteer.wml
Log:
some more cleanups on the ideas list


Modified: website/trunk/en/volunteer.wml
===================================================================

--- website/trunk/en/volunteer.wml	2010-03-11 08:53:42 UTC (rev 21921)
+++ website/trunk/en/volunteer.wml	2010-03-11 09:45:29 UTC (rev 21922)
@@ -72,7 +72,7 @@
 If one or more of these ideas looks promising to you, please <a
 href="<page contact>">contact us</a> to discuss your plans rather than
 sending blind applications. You may also want to propose your own project
-idea which often results in the best applications.
+idea &mdash; which often results in the best applications.
 </p>
 
 <ol>
@@ -165,15 +165,15 @@
 <a href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">a
 proposal to address this limitation</a> and allow clients to connect
 to any given Tor on multiple addresses and ports, but it needs more
-work.  Another anti-censorship project is to try to make Tor
-more scanning-resistant.  Right now, an adversary can identify <a
-href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
-just by trying to connect to them, following the Tor protocol,
-and seeing if they respond.  To solve this, bridges could <a
-href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">act like
-webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
-and not act like bridges until the user provides a bridge-specific key.
+work.
 <br />
+Another area that needs work is our <a
+href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
+service. See e.g. <a
+href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's
+or-dev post</a> from December for details &mdash; lots of design work
+remains.
+<br />
 This project involves a lot of research and design. One of the big
 challenges will be identifying and crafting approaches that can still
 resist an adversary even after the adversary knows the design, and
@@ -290,7 +290,7 @@
 <br />
 Skill Level: <i>Medium</i>
 <br />
-Likely Mentors: <i>Nick, Roger</i>
+Likely Mentors: <i>Nick, Erinn</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
@@ -317,7 +317,7 @@
 <br />
 Skill Level: <i>Medium to High</i>
 <br />
-Likely Mentors: <i>Karsten, Nick</i>
+Likely Mentors: <i>Bruce, Nathan</i>
 <br />
 Others are currently working on Tor clients for Java, Android, and Maemo
 environments.  The first step is to get a handle on the current state of
@@ -336,7 +336,7 @@
 to a small degree about design.
 </li>
 
-<li>
+<!--<li>
 <b>New Torbutton Features</b>
 <br />
 Priority: <i>Medium</i>
@@ -368,7 +368,7 @@
 This work would be independent coding in Javascript and the fun world of <a
 href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
 with not too much involvement in the Tor internals.
-</li>
+</li>-->
 
 <!-- <li>
 <b>New Thandy Features</b>
@@ -535,6 +535,14 @@
 <li>
 <b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
 <br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Erinn, Peter</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
@@ -613,6 +621,14 @@
 <li>
 <b>Improving the Tor QA process: Continuous Integration for builds</b>
 <br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Erinn</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
@@ -723,7 +739,8 @@
 <br />
 Don't like any of these? Look at the <a
 href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development
-roadmap</a> for more ideas.
+roadmap</a> for more ideas, or just try out Tor, Vidalia, and Torbutton,
+and find out what you think needs fixing.
 Some of the <a href="<gittree>doc/spec/proposals">current proposals</a>
 might also be short on developers.
 </li>
@@ -797,6 +814,20 @@
 href="http://amnesia.boum.org/">amnesia LiveCD/USB</a> and the <a
 href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
 </li>
+
+<li>
+Another anti-censorship project is to try to make Tor
+more scanning-resistant.  Right now, an adversary can identify <a
+href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
+just by trying to connect to them, following the Tor protocol,
+and seeing if they respond.  To solve this, bridges could <a
+href="<gitblob>doc/design-paper/blocking.html#tth_sEc9.3">act like
+webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
+and not act like bridges until the user provides a bridge-specific key.
+To start, check out Shane Pope's <a
+href="http://dl.dropbox.com/u/37735/index.html">thesis and prototype</a>.
+</li>
+
 </ol>
 
 <a id="Research"></a>

