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 50,000 Tor users currently, routing their traffic through about 250 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.

Entries will:

Allow the user to fully configure Tor without directly searching for and opening text files.
Let users 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 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, they may:

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
Provide additional statistics about the Tor connection.

including:

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 paths: "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.
Provide application-level anonymity -- 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

The design contest will proceed in two stages: first sketches and then code. For each stage, our panel of judges will recognize the best submissions. All qualifying entries will receive an EFF Tor t-shirt, subject to availability. The best functional implementations will be published on the Tor website.

Sketches: the goal of this stage is to produce a mock-up of a functioning interface, with graphical elements that can be used by programmers and design documents describing how the interface should function.

A qualifying sketch will present an informal specification for a design. That is, it will present with some degree of thoroughness all of the major interfaces that we might expect to encounter, all of the major functionality for the interface, and a reasonable story about how it would be integrated into currently-existing tools (if, indeed, it would be). An example, with more detail than we would require, is the NetBeans UI for JUnit. Note that it walks through multiple interfaces, highlighting the features and functions of the various buttons.

Most featureful interface will be awarded to the graphic design that would provide usable, clear access to the most aspects of the Tor system, covering many or most of the categories on the "additional" list.
Most usable experience will be awarded to the graphic design that would provide the most unobtrusive Tor experience while still covering all criteria (working, perhaps, on the "no news is good news" theory).
Clearest implementation guidance will be awarded to the graphic design that provides the cleanest package of graphic elements and design documentation to aid would-be implementers.

Code: the goal of this stage is to produce a working implementation. You may use any of the sketches, graphics, or ideas from the first stage, with appropriate credit to their authors.

An acceptable entry will be a package of free software that builds and runs. It can be a standalone application, or it can act as an extension or plugin to other broadly-available free software. The entry will demonstrate the points in the judging section: that is, it will be able to control, display, and maintain awareness as discussed above.

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 categories on the "additional" list.
Most usable experience 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 flexible will be awarded to the best system that runs smoothly on all three of Windows, Linux, and OS X; extra points will be awarded for additional systems.

We reserve the right to award other awards as the entries deserve.

How to Submit

Submissions for phase one (sketches) should come as:

Submissions for phase two (code) 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.

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

Judges

Judging will be led by a panel of N prominent specialists in usability and security (to be announced).

Timeline

Stage 1 deadline (sketches): October 31.
Stage 1 judging: November 31.
Stage 2 deadline (code): January 31, 2006.

Winners will be announced at the SOUPS 2006 conference.

Questions and clarifications

We will have a public website and wiki up shortly for FAQ entries, clarifications, etc.

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?

Technical Notes

Shortly before phase two begins, the Tor developers 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.

The Tor developers will also release test rigs (libraries) in both Java and Python that demonstrate Tor's controller protocol. Code submissions may be able to save a lot of time by using this code as a skeleton.