Tor GUI Contest
DRAFT IN PROGRESS -- ALL OF THIS STUFF IS IN FLUX AND SHOULD BE CONSIDERED WRONG.
Overview
Tor is a decentralized network of computers on the Internet that increases privacy in Web browsing, instant messaging, and other applications. We estimate there are some 20,000 Tor users currently, routing their traffic through about 150 volunteer Tor servers on five continents. However, Tor's current user interface approach --- running as a daemon in the background --- does a poor job of communicating network status and security levels to the user. The Tor project, affiliated with the Electronic Frontier Foundation, is running a UI contest to develop a vision of how Tor can work in a user's everyday anonymous browsing experience. Some of the challenges include how to make alerts and error conditions visible on screen; how to let the user configure Tor to use or avoid certain routes or nodes; how to learn about the current state of a Tor connection, including which servers it uses; and how to find out whether (and which) applications are using Tor safely.
Goals
Contestants will produce a work of Free software that will provide a user interface to the Tor system by way of the Tor Controller Protocol.
We are looking for a vision of how Tor can work in a user's everyday anonymous browsing experience.
Successful entries will:
- Allow the user to fully configure Tor without directly editing configuration files.
- Learn about the current state of their Tor connection (including which servers they are connected to, and how many of them), and find out whether and how any of their applications are using it.
- Make alerts and error conditions visible on screen.
- Run on at least one of Windows, Linux, and OS/X, on a not-unusually-configured consumer-level machine.
In addition, entries may a) Provide detailed information about which applications, ports, or packets are (or are not!) passing through Tor, including accounting for both Tor- and non-Tor traffic; and b) Provide additional statistics about the Tor connection.
Examples include:
- How much bandwidth am I using?
- What servers do I know about on the network? Where are they? How available are they?
- Provide an interface for controlling Tor connections: "show me the network from Africa by way of Asia". Think of the global satellite map from the movie Sneakers.
- Configure other running applications to use Tor (for example, by modifying or working through the network stack, and/or by altering application configurations).
- Provide an elegant installer for Tor, the GUI application, and other supporting applications.
- Provide meaningful defaults for a good Tor experience.
- Implement Privoxy-like functionality -- that is, not just paying attention to transport anonymity on the level of Tor, but also paying attention to the anonymity of the http headers, cookies, etc.
Contest categories
Three categories of interface will be awarded:
- Best usability will be awarded to the application that provides the most unobtrusive Tor experience while still covering all criteria (working, perhaps, on the "no news is good news" theory).
- Most featureful interface will be awarded to the application that provides usable, clear access to the most aspects of the Tor system, covering many or most of the goals above.
- Most flexible will be awarded to the best system that runs smoothly on all three of Windows, Linux, and Mac OS X; extra points will be awarded for additional systems.
We may decide to award other awards as the entries deserve.
Judging criteria
Awards will be granted on the basis of (in rough preference order):
- Usability (what does this mean?)
- Informativeness: can the user learn what they need to know, both in terms of using the network and also in terms of security decisions?
- Total user experience
- Aesthetics
- Responsiveness
- Stability and robustness
- Internationalization (multiple language support)
- Installation experience
Testing criteria
To check for basic acceptability, the contest will be judged with several major tests. For example, the system designer should expect:
- A minimal test: does it work?
- Several parameters, both obscure and obvious, will be configured. Is it possible and easy to do so?
- A network will be connected once the system is running. Can the user tell that the network is now live?
- The network will be disconnected or interrupted. Can the user tell that the network has an error?
Submissions
Submissions should come as:
- Source code, with appropriate makefiles or documentation explaining how to build it. Must be licensed under a free/open source license, as defined by OSI or DFSG. See this FAQ entry for clarification.
- Compiled binaries or bytecodes for at least one platform of choice.
- A design document providing an overview of what major functions to look for and what functions were implemented.
Judges
Judging will be led by a panel of five prominent specialists in usability and security (to be announced).
Prizes
TBA, hopefully including a Squeezebox for top winners.
Timeline
The contest will be announced on or around June 1, 2005. We expect the contest deadline to be on or around January 15, 2006, with judging complete by March 15, 2006.
Technical notes
Shortly before the contest begins, Tor will release a canonical code version. This is the version that will be used for judging the contest; please ensure that you use this version. Bugfixes to this version will be announced to the contest web site.
Tor will also release test rigs in both Java and Python that demonstrate Tor's controller protocol. It is acceptable to build entrants using this code as a skeleton.
The test rig will show all of the basic functionality that is necessary for the minimal features of the contest.
Questions and clarifications
We will have a public website and wiki up shortly for FAQ entries, clarifications, etc.