git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
9bcbb2f3c
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
gui-contest.html
make cvs/ links relative to / rather than . also, point gui-contest people to /cvs/control/doc/howto.txt rather than the control spec.
Roger Dingledine
commited
9bcbb2f3c
at 2005-07-16 00:19:37
gui-contest.html
Blame
History
Raw
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>Tor GUI Contest</title> <meta name="Author" content="Roger Dingledine" /> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" /> <link rel="stylesheet" type="text/css" href="stylesheet.css" /> <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" /> </head> <body> <!-- TITLE BAR & NAVIGATION --> <table class="banner" border="0" cellpadding="0" cellspacing="0"> <tr> <td class="banner-left"></td> <td class="banner-middle"> <a href="index.html">Home</a> | <a href="howitworks.html">How It Works</a> | <a href="download.html">Download</a> | <a href="documentation.html">Docs</a> | <a href="users.html">Users</a> | <a href="faq.html">FAQs</a> | <a href="volunteer.html">Volunteer</a> | <a href="developers.html">Developers</a> | <a href="research.html">Research</a> | <a href="people.html">People</a> </td> <td class="banner-right"></td> </tr> </table> <!-- END TITLE BAR & NAVIGATION --> <div class="center"> <div class="main-column"> <h2>Tor GUI Contest</h2> <hr /> <p>DRAFT IN PROGRESS -- ALL OF THIS STUFF IS IN FLUX AND SHOULD BE CONSIDERED WRONG.</p> <hr /> <h3>Overview</h3> <p> 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. </p> <p> The Tor project, affiliated with the <a href="http://www.eff.org/">Electronic Frontier Foundation</a>, 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. </p> <hr /> <h3>Goals</h3> <p>Contestants will produce a work of <a href="http://www.fsf.org/licensing/essays/free-sw.html">Free Software</a> that will provide a user interface to the Tor system by way of the <a href="/cvs/control/doc/howto.txt">Tor Controller Protocol</a>.</p> <p>We are looking for a vision of how Tor can work in a user's everyday anonymous browsing experience.</p> <p>Entries will:</p> <ul> <li>Allow the user to fully configure Tor rather than manually searching for and opening text files.</li> <li>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.</li> <li>Make alerts and error conditions visible on screen.</li> <li>Run on at least one of Windows, Linux, and OS X, on a not-unusually-configured consumer-level machine.</li> </ul> <p>In addition, they may:</p> <ul> <li>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</li> <li>Provide additional statistics about the Tor connection.</li> <li>Give users more control over how their Tor behaves at certain times of day or in other contexts (like operating as a server).</li> </ul> <p>Some examples of useful features include:</p> <ul> <li>How much bandwidth is the user using via Tor? How does this compare to the overall network traffic to/from the computer?</li> <li>Is there network traffic from ports or applications that the user intended to be anonymized?</li> <li>What Tor servers does the user know about on the network? Where are they? How available are they?</li> <li>Provide 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 <i>Sneakers</i>.</li> <li>Configure other running applications to use Tor (for example, by modifying or working through the network stack, and/or by altering application configurations).</li> <li>Provide an elegant installer for Tor, your GUI submission, and other supporting applications.</li> <li>Make your GUI manage the Tor process and other supporting applications -- start them, stop them, realize when they've died.</li> <li>Provide meaningful defaults for a good Tor experience.</li> <li>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.</li> <li>Let the user specify different config option sets depending on time of day (e.g. daytime vs. nighttime).</li> <li>Provide useful controller functions for Tor servers too -- for example, recommended bandwidth configurations.</li> <li>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.</li> <li>Provide a button or some automatically updating interface to let the user learn whether Tor is working currently; and give useful messages and recommendations if it doesn't seem to be working.</li> <li>Provide a way to automatically configure local firewalls (ipchains, Windows ones, etc) to let Tor traffic out (and in, for Tor servers).</li> </ul> <hr /> <h3>Contest categories</h3> <p> 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. </p> <p><b>Sketches:</b> 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.</p> <p> 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 <a href="http://ui.netbeans.org/docs/ui/junits/promo_f.html">the NetBeans UI for JUnit</a>. Note that it walks through multiple interfaces, highlighting the features and functions of the various buttons. </p> <ul> <li><b>Most featureful interface</b> 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.</li> <li><b>Most usable experience</b> 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).</li> <li><b>Clearest implementation guidance</b> will be awarded to the graphic design that provides the cleanest package of graphic elements and design documentation to aid would-be implementers.</li> </ul> <p><b>Code:</b> 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.</p> <p> 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. </p> <ul> <li><b>Most featureful interface</b> 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.</li> <li><b>Most usable experience</b> 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).</li> <li><b>Most flexible</b> 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.</li> </ul> <p>We reserve the right to award other awards as the entries deserve.</p> <hr /> <h3>How to Submit</h3> <p>Submissions for phase one (sketches) should come as:</p> <ul> <li>foo<li> </ul> <p>Submissions for phase two (code) should come as:</p> <ul> <li>Source code, with appropriate makefiles or documentation explaining how to build it. Must be licensed under a free/open source license, as defined by <a href="http://www.opensource.org/licenses/">OSI</a> or <a href="http://www.debian.org/social_contract#guidelines">DFSG</a>. See <a href="http://wiki.noreply.org/noreply/TheOnionRouter/ContestFAQ#DefineFree">this FAQ entry</a> for clarification.</li> <li>Compiled binaries or bytecodes for at least one platform of choice.</li> <li>A design document providing an overview of what major functions to look for and what functions were implemented.</li> </ul> <hr /> <h3>Criteria</h3> <p>Awards will be granted on the basis of (in rough preference order):</p> <ul> <li>Usability (<a href="http://wiki.noreply.org/noreply/TheOnionRouter/ContestFAQ#DefineUsable">what does this mean?</a>)</li> <li>Informativeness: can the user learn what they need to know, both in terms of using the network and also in terms of security decisions?</li> <li>Total user experience</li> <li>Aesthetics</li> <li>Responsiveness</li> <li>Stability and robustness</li> <li>Internationalization (multiple language support)</li> <li>Installation experience</li> </ul> <hr /> <h3>Judges</h3> <p>Judging will be led by a panel of N prominent specialists in usability and security (to be announced).</p> <hr /> <h3>Timeline</h3> <ul> <li>Stage 1 deadline (sketches): October 31.</li> <li>Stage 1 judging: November 31.</li> <li>Stage 2 deadline (code): January 31, 2006.</li> </ul> <p>Winners will be announced on the webpage and also at the SOUPS 2006 conference. (Here's a suggestion on <a href="http://wiki.noreply.org/noreply/TheOnionRouter/ContestFAQ#AcademicResearch">academic usability research on Tor</a>.)</p> <hr /> <h3>Questions and clarifications</h3> <p>We will have a public website and wiki up shortly for FAQ entries, clarifications, etc.</p> <!-- <hr /> <h3>Testing criteria</h3> <p>To check for basic acceptability, the contest will be judged with several major tests. For example, the system designer should expect:</p> <ul> <li>A minimal test: does it work?</li> <li>Several parameters, both obscure and obvious, will be configured. Is it possible and easy to do so?</li> <li>A network will be connected once the system is running. Can the user tell that the network is now live?</li> <li>The network will be disconnected or interrupted. Can the user tell that the network has an error?</li> </ul> --> <hr /> <h3>Technical Notes</h3> <p>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.</p> <p>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.</p> <hr /> <h3>Legal Notes</h3> <p>By submitting your entry to be considered in the Tor GUI contest, you hereby:</p> <ul> <li>(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</li> <li>(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 (http://www.opensource.org/docs/definition.php), such as the 3-clause BSD, MIT, or GPL licenses, or (where applicable) the Creative Commons Attribution (http://creativecommons.org/licenses/by/2.5/) license. If you provide the entry pursuant to such a license, you must include the applicable information in your submission.</li> </ul> </div><!-- #main --> </div> <div class="bottom" id="bottom"> <i><a href="mailto:tor-webmaster@freehaven.net" class="smalllink">Webmaster</a></i> - $Id$ </div> </body> </html>
