[or-cvs] r18944: {website} Order ideas by priority. (website/trunk/en)
kloesing at seul.org
kloesing at seul.org
Thu Mar 12 21:25:48 UTC 2009
Author: kloesing
Date: 2009-03-12 17:25:48 -0400 (Thu, 12 Mar 2009)
New Revision: 18944
Modified:
website/trunk/en/volunteer.wml
Log:
Order ideas by priority.
Modified: website/trunk/en/volunteer.wml
===================================================================
--- website/trunk/en/volunteer.wml 2009-03-12 21:05:06 UTC (rev 18943)
+++ website/trunk/en/volunteer.wml 2009-03-12 21:25:48 UTC (rev 18944)
@@ -113,36 +113,61 @@
<ol>
-<!-- Mike is already working on this.
<li>
-<b>Tor Node Scanner improvements</b>
+<b>Tor Browser Bundle for Linux/Mac OS X</b>
<br />
-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
-penalized by some ratio as well, or just get marked as Invalid. In
-addition, nodes that exhibit a very low average stream capacity but
-advertise a very high node bandwidth can also be marked as Invalid.
-Much of this statistics gathering is already done, it just needs to be
-transformed into something that can be reported to the Directory
-Authorities to blacklist/penalize nodes in such a way that clients
-will listen.
+Priority: <i>High</i>
<br />
-In addition, these same statistics can be gathered about the traffic
-through a node. Events can be added to the <a
-href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Tor Control
-Protocol</a> to
-report if a circuit extend attempt through the node succeeds or fails, and
-passive statistics can be gathered on both bandwidth and reliability
-of other nodes via a node-based monitor using these events. Such a
-scanner would also report information on oddly-behaving nodes to
-the Directory Authorities, but a communication channel for this
-currently does not exist and would need to be developed as well.
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Steven, Andrew</i>
+<br />
+The Tor Browser bundle incorporates Tor, Firefox, and the Vidalia user
+interface (and optionally Pidgin IM). Components are pre-configured to
+operate in a secure way, and it has very few dependencies on the
+installed operating system. It has therefore become one of the most
+easy to use, and popular, ways to use Tor on Windows.
+<br />
+However, there is currently no comparable package for Linux and Mac OS
+X, so this project would be to implement Tor Browser Bundle for these
+platforms. This will involve modifications to Vidalia (C++), possibly
+Firefox (C) then creating and testing the launcher on a range of
+operating system versions and configurations to verify portability.
+<br />
+Students should be familiar with application development on one or
+preferably both of Linux and Mac OS X, and be comfortable with C/C++
+and shell scripting.
+<br />
+Part of this project could be usability testing of Tor Browser Bundle,
+ideally amongst our target demographic.
+That would help a lot in knowing what needs to be done in terms of bug
+fixes or new features. We get this informally at the moment, but a more
+structured process would be better.
</li>
--->
<li>
+<b>Translation wiki for our website</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 />
+The Tor Project has been working over the past year to set up web-based
+tools to help volunteers translate our applications into other languages.
+We finally hit upon Pootle, and we have a fine web-based translation engine
+in place for Vidalia, Torbutton, and Torcheck. However, Pootle only
+translates strings that are in the "po" format, and our website uses wml
+files. This project is about finding a way to convert our wml files into po
+strings and back, so they can be handled by Pootle.
+</li>
+
+<li>
<b>Help track the overall Tor Network status</b>
<br />
Priority: <i>Medium to High</i>
@@ -172,53 +197,7 @@
Status wish list</a>.
</li>
-<!-- Is this still a useful project? If so, move it to another section.
<li>
-<b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
-<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
-<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
-in the default torrc. Consequently, Vidalia will try
-to start its own Tor process since it could not connect to the existing
-Tor, and Vidalia's Tor process will then exit with an error message
-the user likely doesn't understand since Tor cannot bind its listening
-ports — they're already in use by the original Tor daemon.
-<br />
-The current solution involves either telling the user to stop the
-existing Tor daemon and let Vidalia start its own Tor process, or
-explaining to the user how to set a control port and password in their
-torrc. A better solution on Debian would be to use Tor's ControlSocket,
-which allows Vidalia to talk to Tor via a Unix domain socket, and could
-possibly be enabled by default in Tor's Debian packages. Vidalia can
-then authenticate to Tor using filesystem-based (cookie) authentication
-if the user running Vidalia is also in the debian-tor group.
-<br />
-This project will first involve adding support for Tor's ControlSocket
-to Vidalia. The student will then develop and test Debian and Ubuntu
-packages for Vidalia that conform to Debian's packaging standards and
-make sure they work well with the existing Tor packages. We can also
-set up an apt repository to host the new Vidalia packages.
-<br />
-The next challenge would be to find an intuitive usable way for Vidalia
-to be able to change Tor's configuration (torrc) even though it is
-located in <code>/etc/tor/torrc</code> and thus immutable. The best
-idea we've come up with so far is to feed Tor a new configuration via
-the ControlSocket when Vidalia starts, but that's bad because Tor starts
-each boot with a different configuration than the user wants. The second
-best idea
-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 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>
--->
-
-<li>
<b>Improving Tor's ability to resist censorship</b>
<br />
Priority: <i>Medium to High</i>
@@ -253,74 +232,83 @@
then trading off censorship resistance with usability and robustness.
</li>
-<!-- This should be mostly done.
<li>
-<b>Tor/Polipo/Vidalia Auto-Update Framework</b>
+<b>Tuneup Tor!</b>
<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
-the Tor directory information. Currently, Vidalia simply pops
-up a little message box that lets the user know they should manually
-upgrade. The goal of this project would be to extend Vidalia with the
-ability to also fetch and install the updated Tor software for the
-user. We should do the fetches via Tor when possible, but also fall back
-to direct fetches in a smart way. Time permitting, we would also like
-to be able to update other
-applications included in the bundled installers, such as Polipo and
-Vidalia itself.
+Priority: <i>Medium to High</i>
<br />
-To complete this project, the student will first need to first investigate
-the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
-their strengths, weaknesses, security properties, and ability to be
-integrated into Vidalia. If none are found to be suitable, the student
-will design their own auto-update framework, document the design, and
-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.
+Effort Level: <i>Medium to High</i>
<br />
-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 to review and discuss
-with others prior to implementation.
+Skill Level: <i>High</i>
+<br />
+Likely Mentors: <i>Nick, Roger, Mike, Karsten</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
+<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
+relays lie about their bandwidth</a>;
+to address this, Tor currently caps the maximum bandwidth
+it's willing to believe any relay provides. This is a limited fix, and
+a waste of bandwidth capacity to boot. Instead,
+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. 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
+much communications overhead between relays and directory
+authorities.
</li>
--->
<li>
-<b>An Improved and More Usable Network Map in Vidalia</b>
+<b>Improving Polipo on Windows</b>
<br />
-Priority: <i>Low to Medium</i>
+Priority: <i>Medium to High</i>
<br />
Effort Level: <i>Medium</i>
<br />
Skill Level: <i>Medium</i>
<br />
-Likely Mentors: <i>Matt</i>
+Likely Mentors: <i>Martin</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
-Tor network. The map is currently not very interactive and has rather
-poor graphics. Instead, we implemented KDE's Marble widget such
-that it gives us a better quality map and enables improved interactivity,
-such as allowing the user to click on individual relays or circuits to
-display additional information. We want to add the ability
-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 exit
-from here."
+Help port <a
+href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
+Windows. Example topics to tackle include:
+1) the ability to asynchronously
+query name servers, find the system nameservers, and manage netbios
+and dns queries.
+2) manage events and buffers
+natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
+Windows it's whatever the config specifies). 3) some sort of GUI config
+and reporting tool, bonus if it has a systray icon with right clickable
+menu options. Double bonus if it's cross-platform compatible.
+4) allow the software to use the Windows Registry and handle proper Windows directory locations, such as "C:\Program Files\Polipo"
+</li>
+
+<li>
+<b>Implement a torrent-based scheme for downloading Thandy packages</b>
<br />
-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.
+Priority: <i>Medium to High</i>
<br />
-A person undertaking this project should have good C++ development
-experience. Previous experience with Qt and CMake is helpful, but not
-required.
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Martin, Nick</i>
+<br />
+<a
+href="http://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>
+is a relatively new software to allow assisted updates of Tor and related
+software. Currently, there are very few users, but we expect Thandy to be
+used by almost every Tor user in the future. To avoid crashing servers on
+the day of a Tor update, we need new ways to distribute new packages
+efficiently, and using libtorrent seems to be a possible solution. If you
+think of other good ideas, great - please do let us know!<br />
+We also need to investigate how to include our mirrors better. If possible,
+there should be an easy way for them to help distributing the packages.
</li>
<li>
@@ -366,6 +354,374 @@
design/Photoshop fu, since we might want/need some shiny new icons too.
</li>
+<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, Roger</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
+refactoring of some parts of Tor, in order to dissociate as much logic
+as possible from globals.
+<br />
+Additionally, we need to automate our performance testing. We've got
+buildbot to automate our regular integration and compile testing already
+(though we need somebody to set it up on Windows),
+but we need to get our network simulation tests (as built in <a
+href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
+updated for more recent versions of Tor, and designed to launch a test
+network either on a single machine, or across several, so we can test
+changes in performance on machines in different roles automatically.
+</li>
+
+<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 />
+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
+href="http://code.google.com/android/">Android</a>. The first step
+would be to port the existing code and execute it in an Android
+environment. Next, the code should be updated to support the newer Tor
+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 />
+A prospective 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. 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>New Torbutton Features</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/>
+There are several <a
+href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5&type=2">good
+feature requests</a> on the Torbutton Flyspray section. In particular, <a
+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=523">Integrating
+'New Identity' with Vidalia</a>,
+<a href="https://bugs.torproject.org/flyspray/index.php?do=details&id=940">ways of
+managing multiple cookie jars/identities</a>, <a
+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=637">preserving
+specific cookies</a> when cookies are cleared,
+<a
+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=524">better
+referrer spoofing</a>, <a
+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=564">correct
+Tor status reporting</a>, and <a
+href="https://bugs.torproject.org/flyspray/index.php?do=details&id=462">"tor://"
+and "tors://" urls</a> are all interesting
+features that could be added.
+<br />
+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>
+<b>New Thandy Features</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium to High</i>
+<br />
+Likely Mentors: <i>Martin</i>
+<br />
+Additional capabilities are needed for assisted updates of all the Tor
+related software for Windows and other operating systems. Some of the
+features to consider include:
+1) Integration of the <a
+href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
+Python library</a>
+for authenticated HTTPS downloads. 2) Adding a level of indirection
+between the timestamp signatures and the package files included in an
+update. See the "Thandy attacks / suggestions" thread on or-dev.
+3) Support locale specific installation and configuration of assisted
+updates based on preference, host, or user account language settings.
+Familiarity with Windows codepages, unicode, and other character sets
+is helpful in addition to general win32 and posix API experience and
+Python proficiency.
+</li>
+
+<li>
+<b>Simulator for slow Internet connections</b>
+<br />
+Priority: <i>Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</i>
+<br />
+Likely Mentors: <i>Steven</i>
+<br />
+Many users of Tor have poor-quality Internet connections, giving low
+bandwidth, high latency, and high packet loss/re-ordering. User
+experience is that Tor reacts badly to these conditions, but it is
+difficult to improve the situation without being able to repeat the
+problems in the lab.
+<br />
+This project would be to build a simulation environment which
+replicates the poor connectivity so that the effect on Tor performance
+can be measured. Other components would be a testing utility to
+establish what are the properties of connections available, and to
+measure the effect of performance-improving modifications to Tor.
+<br />
+The tools used would be up to the student, but dummynet (for FreeBSD)
+and nistnet (for Linux) are two potential components on which this
+project could be built. Students should be experienced with network
+programming/debugging and TCP/IP, and preferably familiar with C and a
+scripting language.
+</li>
+
+<li>
+<b>An Improved and More Usable Network Map in Vidalia</b>
+<br />
+Priority: <i>Low to Medium</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Medium</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
+Tor network. The map is currently not very interactive and has rather
+poor graphics. Instead, we implemented KDE's Marble widget such
+that it gives us a better quality map and enables improved interactivity,
+such as allowing the user to click on individual relays or circuits to
+display additional information. We want to add the ability
+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 exit
+from here."
+<br />
+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 person undertaking this project should have good C++ development
+experience. Previous experience with Qt and CMake is helpful, but not
+required.
+</li>
+
+<li>
+<b>Bring moniTor to life</b>
+<br />
+Priority: <i>Low</i>
+<br />
+Effort Level: <i>Medium</i>
+<br />
+Skill Level: <i>Low to Medium</i>
+<br />
+Likely Mentors: <i>Karsten, Jacob</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
+system information of the underlying machine. When running this tool, it
+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 />
+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
+project is one part about identifying requirements to such a
+tool and designing its interface, and one part lots of coding.
+</li>
+
+<li>
+<b>Torbutton equivalent for Thunderbird</b>
+<br />
+Priority: <i>Low</i>
+<br />
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>High</i>
+<br />
+Likely Mentors: <i>Mike</i>
+<br />
+We're hearing from an increasing number of users that they want to use
+Thunderbird with Tor. However, there are plenty of application-level
+concerns, for example, by default Thunderbird will put your hostname in
+the outgoing mail that it sends. At some point we should start a new
+push to build a Thunderbird extension similar to Torbutton.
+</li>
+
+<li>
+<b>Intermediate Level Network Device Driver</b>
+<br />
+Priority: <i>Low</i>
+<br />
+Effort Level: <i>High</i>
+<br />
+Skill Level: <i>High</i>
+<br />
+Likely Mentors: <i>Martin</i>
+<br />
+The WinPCAP device driver used by Tor VM for bridged networking does
+not support a number of wireless and non-Ethernet network adapters.
+Implementation of a intermediate level network device driver for win32
+and 64bit would provide a way to intercept and route traffic over such
+networks. This project will require knowledge of and experience with
+Windows kernel device driver development and testing. Familiarity with
+Winsock and Qemu would also be helpful.
+</li>
+
+<li>
+<b>Bring up new ideas!</b>
+<br />
+Don't like any of these? Look at the <a
+href="<svnsandbox>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development
+roadmap</a> for more ideas.
+Some of the <a href="<svnsandbox>doc/spec/proposals/">current proposals</a>
+might also be short on developers.
+</li>
+
+<!-- Mike is already working on this.
+<li>
+<b>Tor Node Scanner improvements</b>
+<br />
+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
+penalized by some ratio as well, or just get marked as Invalid. In
+addition, nodes that exhibit a very low average stream capacity but
+advertise a very high node bandwidth can also be marked as Invalid.
+Much of this statistics gathering is already done, it just needs to be
+transformed into something that can be reported to the Directory
+Authorities to blacklist/penalize nodes in such a way that clients
+will listen.
+<br />
+In addition, these same statistics can be gathered about the traffic
+through a node. Events can be added to the <a
+href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Tor Control
+Protocol</a> to
+report if a circuit extend attempt through the node succeeds or fails, and
+passive statistics can be gathered on both bandwidth and reliability
+of other nodes via a node-based monitor using these events. Such a
+scanner would also report information on oddly-behaving nodes to
+the Directory Authorities, but a communication channel for this
+currently does not exist and would need to be developed as well.
+</li>
+-->
+
+<!-- Is this still a useful project? If so, move it to another section.
+<li>
+<b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
+<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
+<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
+in the default torrc. Consequently, Vidalia will try
+to start its own Tor process since it could not connect to the existing
+Tor, and Vidalia's Tor process will then exit with an error message
+the user likely doesn't understand since Tor cannot bind its listening
+ports — they're already in use by the original Tor daemon.
+<br />
+The current solution involves either telling the user to stop the
+existing Tor daemon and let Vidalia start its own Tor process, or
+explaining to the user how to set a control port and password in their
+torrc. A better solution on Debian would be to use Tor's ControlSocket,
+which allows Vidalia to talk to Tor via a Unix domain socket, and could
+possibly be enabled by default in Tor's Debian packages. Vidalia can
+then authenticate to Tor using filesystem-based (cookie) authentication
+if the user running Vidalia is also in the debian-tor group.
+<br />
+This project will first involve adding support for Tor's ControlSocket
+to Vidalia. The student will then develop and test Debian and Ubuntu
+packages for Vidalia that conform to Debian's packaging standards and
+make sure they work well with the existing Tor packages. We can also
+set up an apt repository to host the new Vidalia packages.
+<br />
+The next challenge would be to find an intuitive usable way for Vidalia
+to be able to change Tor's configuration (torrc) even though it is
+located in <code>/etc/tor/torrc</code> and thus immutable. The best
+idea we've come up with so far is to feed Tor a new configuration via
+the ControlSocket when Vidalia starts, but that's bad because Tor starts
+each boot with a different configuration than the user wants. The second
+best idea
+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 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>
+-->
+
+<!-- This should be mostly done.
+<li>
+<b>Tor/Polipo/Vidalia Auto-Update Framework</b>
+<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
+the Tor directory information. Currently, Vidalia simply pops
+up a little message box that lets the user know they should manually
+upgrade. The goal of this project would be to extend Vidalia with the
+ability to also fetch and install the updated Tor software for the
+user. We should do the fetches via Tor when possible, but also fall back
+to direct fetches in a smart way. Time permitting, we would also like
+to be able to update other
+applications included in the bundled installers, such as Polipo and
+Vidalia itself.
+<br />
+To complete this project, the student will first need to first investigate
+the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
+their strengths, weaknesses, security properties, and ability to be
+integrated into Vidalia. If none are found to be suitable, the student
+will design their own auto-update framework, document the design, and
+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 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 to review and discuss
+with others prior to implementation.
+</li>
+-->
+
<!-- Jake already did most of this.
<li>
<b>Improvements on our active browser configuration tester</b> -
@@ -456,37 +812,6 @@
</li>
-->
-<li>
-<b>Tuneup Tor!</b>
-<br />
-Priority: <i>Medium to High</i>
-<br />
-Effort Level: <i>Medium to High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Nick, Roger, Mike, Karsten</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
-<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
-relays lie about their bandwidth</a>;
-to address this, Tor currently caps the maximum bandwidth
-it's willing to believe any relay provides. This is a limited fix, and
-a waste of bandwidth capacity to boot. Instead,
-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. 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
-much communications overhead between relays and directory
-authorities.
-</li>
-
<!--
<li>
<b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
@@ -517,90 +842,6 @@
</li>
-->
-<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, Roger</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
-refactoring of some parts of Tor, in order to dissociate as much logic
-as possible from globals.
-<br />
-Additionally, we need to automate our performance testing. We've got
-buildbot to automate our regular integration and compile testing already
-(though we need somebody to set it up on Windows),
-but we need to get our network simulation tests (as built in <a
-href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
-updated for more recent versions of Tor, and designed to launch a test
-network either on a single machine, or across several, so we can test
-changes in performance on machines in different roles automatically.
-</li>
-
-<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 />
-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
-href="http://code.google.com/android/">Android</a>. The first step
-would be to port the existing code and execute it in an Android
-environment. Next, the code should be updated to support the newer Tor
-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 />
-A prospective 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. 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>Bring moniTor to life</b>
-<br />
-Priority: <i>Low</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Low to Medium</i>
-<br />
-Likely Mentors: <i>Karsten, Jacob</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
-system information of the underlying machine. When running this tool, it
-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 />
-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
-project is one part about identifying requirements to such a
-tool and designing its interface, and one part lots of coding.
-</li>
-
<!-- Removed, unless Mike still wants this to be in.
<li>
<b>Torbutton improvements</b>
@@ -622,31 +863,6 @@
</li>
-->
-<li>
-<b>Improving Polipo on Windows</b>
-<br />
-Priority: <i>Medium to High</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Martin</i>
-<br />
-Help port <a
-href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
-Windows. Example topics to tackle include:
-1) the ability to asynchronously
-query name servers, find the system nameservers, and manage netbios
-and dns queries.
-2) manage events and buffers
-natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
-Windows it's whatever the config specifies). 3) some sort of GUI config
-and reporting tool, bonus if it has a systray icon with right clickable
-menu options. Double bonus if it's cross-platform compatible.
-4) allow the software to use the Windows Registry and handle proper Windows directory locations, such as "C:\Program Files\Polipo"
-</li>
-
<!-- Is Blossom development still happening?
<li>
<b>Rework and extend Blossom</b>
@@ -698,81 +914,6 @@
</li>
-->
-<li>
-<b>Implement a torrent-based scheme for downloading Thandy packages</b>
-<br />
-Priority: <i>Medium to High</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Martin, Nick</i>
-<br />
-<a
-href="http://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>
-is a relatively new software to allow assisted updates of Tor and related
-software. Currently, there are very few users, but we expect Thandy to be
-used by almost every Tor user in the future. To avoid crashing servers on
-the day of a Tor update, we need new ways to distribute new packages
-efficiently, and using libtorrent seems to be a possible solution. If you
-think of other good ideas, great - please do let us know!<br />
-We also need to investigate how to include our mirrors better. If possible,
-there should be an easy way for them to help distributing the packages.
-</li>
-
-<li>
-<b>Torbutton equivalent for Thunderbird</b>
-<br />
-Priority: <i>Low</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Mike</i>
-<br />
-We're hearing from an increasing number of users that they want to use
-Thunderbird with Tor. However, there are plenty of application-level
-concerns, for example, by default Thunderbird will put your hostname in
-the outgoing mail that it sends. At some point we should start a new
-push to build a Thunderbird extension similar to Torbutton.
-</li>
-
-<li>
-<b>New Torbutton Features</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/>
-There are several <a
-href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5&type=2">good
-feature requests</a> on the Torbutton Flyspray section. In particular, <a
-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=523">Integrating
-'New Identity' with Vidalia</a>,
-<a href="https://bugs.torproject.org/flyspray/index.php?do=details&id=940">ways of
-managing multiple cookie jars/identities</a>, <a
-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=637">preserving
-specific cookies</a> when cookies are cleared,
-<a
-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=524">better
-referrer spoofing</a>, <a
-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=564">correct
-Tor status reporting</a>, and <a
-href="https://bugs.torproject.org/flyspray/index.php?do=details&id=462">"tor://"
-and "tors://" urls</a> are all interesting
-features that could be added.
-<br />
-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>
-
<!-- not really suited for GSoC; integrated into TBB for Linux/Mac OS X
<li>
<b>Usability testing of Tor</b>
@@ -792,147 +933,6 @@
</li>
-->
-<li>
-<b>Translation wiki for our website</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 />
-The Tor Project has been working over the past year to set up web-based
-tools to help volunteers translate our applications into other languages.
-We finally hit upon Pootle, and we have a fine web-based translation engine
-in place for Vidalia, Torbutton, and Torcheck. However, Pootle only
-translates strings that are in the "po" format, and our website uses wml
-files. This project is about finding a way to convert our wml files into po
-strings and back, so they can be handled by Pootle.
-</li>
-
-<li>
-<b>New Thandy Features</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium to High</i>
-<br />
-Likely Mentors: <i>Martin</i>
-<br />
-Additional capabilities are needed for assisted updates of all the Tor
-related software for Windows and other operating systems. Some of the
-features to consider include:
-1) Integration of the <a
-href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
-Python library</a>
-for authenticated HTTPS downloads. 2) Adding a level of indirection
-between the timestamp signatures and the package files included in an
-update. See the "Thandy attacks / suggestions" thread on or-dev.
-3) Support locale specific installation and configuration of assisted
-updates based on preference, host, or user account language settings.
-Familiarity with Windows codepages, unicode, and other character sets
-is helpful in addition to general win32 and posix API experience and
-Python proficiency.
-</li>
-
-<li>
-<b>Intermediate Level Network Device Driver</b>
-<br />
-Priority: <i>Low</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>High</i>
-<br />
-Likely Mentors: <i>Martin</i>
-<br />
-The WinPCAP device driver used by Tor VM for bridged networking does
-not support a number of wireless and non-Ethernet network adapters.
-Implementation of a intermediate level network device driver for win32
-and 64bit would provide a way to intercept and route traffic over such
-networks. This project will require knowledge of and experience with
-Windows kernel device driver development and testing. Familiarity with
-Winsock and Qemu would also be helpful.
-</li>
-
-<li>
-<b>Tor Browser Bundle for Linux/Mac OS X</b>
-<br />
-Priority: <i>High</i>
-<br />
-Effort Level: <i>High</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Steven, Andrew</i>
-<br />
-The Tor Browser bundle incorporates Tor, Firefox, and the Vidalia user
-interface (and optionally Pidgin IM). Components are pre-configured to
-operate in a secure way, and it has very few dependencies on the
-installed operating system. It has therefore become one of the most
-easy to use, and popular, ways to use Tor on Windows.
-<br />
-However, there is currently no comparable package for Linux and Mac OS
-X, so this project would be to implement Tor Browser Bundle for these
-platforms. This will involve modifications to Vidalia (C++), possibly
-Firefox (C) then creating and testing the launcher on a range of
-operating system versions and configurations to verify portability.
-<br />
-Students should be familiar with application development on one or
-preferably both of Linux and Mac OS X, and be comfortable with C/C++
-and shell scripting.
-<br />
-Part of this project could be usability testing of Tor Browser Bundle,
-ideally amongst our target demographic.
-That would help a lot in knowing what needs to be done in terms of bug
-fixes or new features. We get this informally at the moment, but a more
-structured process would be better.
-</li>
-
-<li>
-<b>Simulator for slow Internet connections</b>
-<br />
-Priority: <i>Medium</i>
-<br />
-Effort Level: <i>Medium</i>
-<br />
-Skill Level: <i>Medium</i>
-<br />
-Likely Mentors: <i>Steven</i>
-<br />
-Many users of Tor have poor-quality Internet connections, giving low
-bandwidth, high latency, and high packet loss/re-ordering. User
-experience is that Tor reacts badly to these conditions, but it is
-difficult to improve the situation without being able to repeat the
-problems in the lab.
-<br />
-This project would be to build a simulation environment which
-replicates the poor connectivity so that the effect on Tor performance
-can be measured. Other components would be a testing utility to
-establish what are the properties of connections available, and to
-measure the effect of performance-improving modifications to Tor.
-<br />
-The tools used would be up to the student, but dummynet (for FreeBSD)
-and nistnet (for Linux) are two potential components on which this
-project could be built. Students should be experienced with network
-programming/debugging and TCP/IP, and preferably familiar with C and a
-scripting language.
-</li>
-
-<li>
-<b>Bring up new ideas!</b>
-<br />
-Don't like any of these? Look at the <a
-href="<svnsandbox>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development
-roadmap</a> for more ideas.
-Some of the <a href="<svnsandbox>doc/spec/proposals/">current proposals</a>
-might also be short on developers.
-</li>
-
</ol>
<a id="OtherCoding"></a>
More information about the tor-commits
mailing list