Tor GUI Contest

DRAFT IN PROGRESS

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 rather than manually 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 connections they have), and find out whether any of their applications are using it.
Make alerts and error conditions visible to the user.
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.
Give users more control over how their Tor behaves at certain times of day or in other contexts (like operating as a server).

Some examples of useful features include:

How much bandwidth is Tor using? How does this compare to the overall network traffic to/from the computer?
Is there network traffic from ports or applications that the user intended to be anonymized?
What Tor servers does the user know about on the network? Where are they? How available are they?
An interface for displaying or 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, your GUI submission, and other supporting applications.
Make your GUI manage the Tor process and other supporting applications -- start them, stop them, realize when they've died.
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.
Let the user specify different Tor config option sets depending on time of day (e.g. daytime vs. nighttime).
Provide useful controller functions for Tor servers too -- for example, walk the user through recommended bandwidth configurations and exit policies.
Have a "minimized view" of your GUI for common use, and then a more detailed view or set of windows when the user wants more detail.
Provide a button or some automatically updating interface to let the user learn whether Tor is working currently, perhaps by accessing an external what's-my-IP site and seeing if it thinks you're a Tor server; and give useful messages and recommendations if it doesn't seem to be working.
Provide a way to automatically configure local firewalls (ipchains, Windows firewalls, etc) to let Tor traffic out (and in, for Tor servers). As a bonus, configure it to prevent non-Tor traffic from leaving (and notify when it tries).

Contest Categories

The design contest will proceed in two stages: first sketches and then working 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 sketches and working implementations will be published on the Tor website.

Sketches: the goal of this stage is to produce a mock-up of a functioning interface. This should include design documents describing how the interface should function. If you want, it should also include graphical elements that can be used by programmers.

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). One 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 "useful features" 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), or you can make your own.

An acceptable entry will be a package of free software that builds and runs. It can be a stand-alone application, or it can act as an extension or plugin to other broadly-available free software. The entry will demonstrate the points in the Goals 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:

TBD (please help me decide what this should say)

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 (txt, html, pdf, or ps) 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 on the webpage and also at the SOUPS 2006 conference. (Here's a suggestion on one approach to academic usability research on Tor.)

Questions and Clarifications

Check back here periodically, and look at the Contest FAQ wiki, for FAQ entries, clarifications, etc.

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. You can check out the development versions of these libraries now.

Legal Notes

By submitting your entry to be considered in the Tor GUI contest, you hereby:

(A) represent and warrant that (1) the entry was created by you and that you own all rights to the entry or have the authorized rights to submit such entry and grant the licenses below; and (2) that the entry does not infringe on any third party copyright or other intellectual property rights; AND
(B) EITHER (1) grant us a worldwide, royalty-free, non-exclusive, perpetual license to reproduce, edit, perform, display, publish, make derivative works, and otherwise use the entry as we see fit, including without limitation, incorporating (in whole or in part) into the Tor software, and to sublicense such rights; OR, (2) provide the entry pursuant to a license that complies with the Open Source Definition, such as the 3-clause BSD, MIT, or GPL licenses, or (where applicable) provide the entry licensed under the Creative Commons Attribution license. If you provide the entry pursuant to such a license, you must include the applicable information in your submission.