tor-webwml.git

@@ -1,5 +1,5 @@

 ## translation metadata

-# Based-On-Revision: 18887

+# Based-On-Revision: 18918

 # Last-Translator: mail a-t oliverknapp .de

 #include "head.wmi" TITLE="Tor: Download" CHARSET="UTF-8"

@@ -44,14 +44,15 @@ Bebilderte Anleitung</a>.</td>

 verschlüsselt. Du solltest verstehen, was Tor für dich macht und was es nicht

 macht. <a href="<page download>#Warning">Lies mehr über dieses Thema!</a>.</p></li>

-<li><p>Überprüfe die Signaturen für die Pakete! (<a href="<page verifying-signatures>">Wie das geht?</a>):

+<li><p>Überprüfe die Signaturen für die Pakete! (<a href="<page verifying-signatures>">

+Wie das geht?</a>):</p>

   <ul>

     <li><a href="torbrowser/dist/tor-im-browser-<version-torimbrowserbundle>_de.exe.asc">

     Signatur der installationsfreien Windowsversion</a></li>

     <li><a href="<package-win32-bundle-stable-sig>">Signatur des "Installationspaket für

     Windows"</a></li>

     <li><a href="<package-osx-bundle-stable-sig>">Signatur des OS X Installationspakets</a></li>

-  </ul></p></li>

+  </ul></li>

 <li><p>Du brauchst mehr Auswahl? <a href="<page download>">Hier gibt es unserer

 Downloadseite für fortgeschrittene Anwender</a>.</p></li>

@@ -1,31 +1,31 @@

 ## translation metadata

-# Based-On-Revision: 18524

+# Based-On-Revision: 18909

 # Last-Translator: mail et oliverknapp INSERT_DOT de

-#include "head.wmi" TITLE="Tor: Google Summer of Code 2008" CHARSET="UTF-8"

+#include "head.wmi" TITLE="Tor: Google Summer of Code 2009" CHARSET="UTF-8"

 <div class="main-column">

-<h2>Tor: Google Summer of Code 2008</h2>

+<h2>Tor: Google Summer of Code 2009</h2>

 <hr />

-<p> Letztes Jahr (2007) hat das Tor Projekt zusammen mit der <a

-href="https://www.eff.org/">Electronic Frontier Foundation</a>

-erfolgreich am <a href="http://code.google.com/soc/">Google Summer of Code

-2007</a> teilgenommen. Insgesamt hatten wir vier Studenten als

-Vollzeitentwickler im Sommer 2007. </p>

+<p> Doe letzten beiden Jahren, hat das Tor Projekt zusammen mit der <a

+href="https://www.eff.org/">Electronic Frontier Foundation</a> erfolgreich am

+<a href="http://code.google.com/soc/">Google Summer of Code 2007</a> und <a

+href="http://code.google.com/soc/2008/eff/about.html">2008</a> teilgenommen.

+Insgesamt hatten wir 11 Studenten als Vollzeitentwickler in den Sommern 2007

+und 2008. </p>

 <p> Google hat angekündigt, dass es auch einen <a

-href="http://code.google.com/soc/2008/">Google Summer of Code 2008</a> geben

-wird... und wir wurden <a

-href="http://code.google.com/soc/2008/eff/about.html">angenommen!</a> Diese

+href="http://code.google.com/soc/2008/">Google Summer of Code 2009</a> geben

+wird und wir wollen uns bewerben. Diese

 Seite enthält einige Informationen für interessierte Studenten. </p>

-<p> Der letztmögliche <a

+<!--<p> Der letztmögliche <a

 href="http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline">

 Zeitpunkt</a> für deine <a

 href="http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants">

-Bewerbung</a> ist der <b>7. April 2008</b> um 17 Uhr Pacific time. </p>

+Bewerbung</a> ist der <b>7. April 2008</b> um 17 Uhr Pacific time. </p>-->

 <p> Du musst unabbhängig und ohne dass wir dich ständig motivieren müssen

 arbeiten können. Wir haben eine spannende Community von interessierten

@@ -59,7 +59,17 @@ Entwicklung von Tor hat viele Fragen und Probleme im Bereich der <a

 href="http://freehaven.net/anonbib/">anonymen Systeme</a> aufgeworfen.</li>

 </ul>

+<a id="Ideas"></a>

+<h2><a class="anchor" href="#Ideas">Ideensammlung</a></h2>

+

+<p>Dieses Jahr haben wir zwei Ideen: Eine Sache wäre es <a href="<page

+volunteer>#Projects">bei der Entwicklung von Tor zu helfen</a>, die andere

+Idee ist, bei der Entwicklung des

+<a href="http://www.eff.org/testyourisp/switzerland">Switzerland Werkzeugs der

+EFF zu helfen.</a>.</p>

+

 <a id="Template"></a>

+<h2><a class="anchor" href="#Template">Application Template</a></h2>

 <p> Bitte benutze die folgende Vorlage für deine Bewerbung, damit stellst du

 sicher, dass du alle nötigen Informationen, die wir brauchen um dich und

@@ -67,13 +77,12 @@ deinen Vorschlag zu bewerten, mitlieferst. </p>

 <ol>

-<li>An welchem Projekt willst du arbeiten? Schau in <a href="<page

-volunteer>#Projects">diese Liste</a> für Ideen oder denk dir was Eigenes

-aus. Dein

-Vorschlag sollte generelle Informationen über das beinhalten, was du machen

-willst, wobei du Bereiche in denen du Probleme erwartest genauer ausführen

-solltest. In deinem Vorschlag solltest du das Projekt auch in kleinere Etappen

-zerlegen und uns davon überzeugen, dass du planst es fertig zu bekommen.</li>

+<li>An welchem Projekt willst du arbeiten? Nutze unsere Ideen als ein Anfang

+und entwickle eine eigene Idee an der du arbeiten möchtest. Dein Vorschlag

+sollte generelle Informationen über das beinhalten, was du machen willst,

+wobei du Bereiche in denen du Probleme erwartest genauer ausführen solltest.

+In deinem Vorschlag solltest du das Projekt auch in kleinere Etappen zerlegen

+und uns davon überzeugen, dass du planst es fertig zu bekommen.</li>

 <li>Zeig uns ein Code-Beispiel: Etwas Schickes und Sauberes, damit wir sehen

 dass du weißt was du so treibst, am Besten von einem bestehenden Projekt.</li>

@@ -107,8 +116,9 @@ Forschungsgruppe bist, welche ist das?</li>

 </ol>

-<p> Wir haben für dieses Jahr 11 Mentoren ausgewählt &mdash; die meisten

+<p> Wir haben für dieses Jahr 12 Mentoren ausgewählt &mdash; die meisten

 stammen aus dem <a href="<page people>#Core">Kernentwickler-Team von Tor</a>

+und ein paar Leute von der <a href="http://www.eff.org/about/staff">EFF</a>

 — daher sollten wir in der Lage sein ein breites Spektrum an Projekten

 zu begleiten; neben der Arbeit an Tor selbst zum Beispiel auch Projekte an

 zusätzlichen Komponenten oder anderen, mit Tor verbundenen Programmen. Wir

@@ -1,5 +1,5 @@

 ## translation metadata

-# Based-On-Revision: 18276

+# Based-On-Revision: 18807

 # Last-Translator: mail (a.t) oliverknapp. de

@@ -1,5 +1,5 @@

 ## translation metadata

-# Based-On-Revision: 18874

+# Based-On-Revision: 18921

 # Last-Translator: mail 11 oliverknapp 22 de

 #include "head.wmi" TITLE="Tor: Mithelfen" CHARSET="UTF-8"

@@ -75,17 +75,15 @@

   dies zu erreichen, wäre alle Daten zu Google zu schicken und diese

   machen dann die Karte für uns. Wie sehr beeinflusst dies die

   Privatsphäre und haben wir noch andere gute Optionen?</li>

-  <li>Tor bietet anonyme Verbindungen. Wenn du jedoch verschiedene

-    Pseudonyme haben möchtest (z.B. rufst du desöfteren zwei Webseiten

-    auf und wenn das jemand weiß, kann er auf dich schliessen.),

-    unterstützen wir das nicht sehr gut.  Wir sollten einen guten

-    Ansatz und eine Schnittstelle zur Handhabung von pseudonymen

-    Profilen finden. Schaue dir

-    den <a

-    href="http://archives.seul.org/or/talk/Dec-2004/msg00086.html">Beitrag

-    </a> und den <a

-    href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html">Followup</a>

-    für mehr Details an.</li>

+</ol>

+

+<a id="Advocacy"></a>

+<h2><a class="anchor" href="#Advocacy">Tor-Botschafter</a></h2>

+<ol>

+<li>Baue ein Communitylogo unter einer Creative Commons Lizenz, das alle benutzen und verändern dürfen</li>

+<li>Mache eine Präsentation die weltweit für Talks und Diskusionen über Tor verwendet werden kann.</li>

+<li>Dreh ein Video über deine positiven Einsätze von Tor. Es haben schon ein paar auf Seesmic angefangen.</li>

+<li>Entwickle ein Poster oder ein Set von Postern rund um ein Thema wie z.B. "Freiheit dank Tor!"</li>

 </ol>

 <a id="Documentation"></a>

@@ -162,6 +160,14 @@ currently does not exist and would need to be developed as well.

 <li>

 <b>Help track the overall Tor Network status</b>

 <br />

+Priority: <i>Medium to High</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium</i>

+<br />

+Likely Mentors: <i>Karsten</i>

+<br />

 It would be great to set up an automated system for tracking network

 health over time, graphing it, etc. Part of this project would involve

 inventing better metrics for assessing network health and growth. Is the

@@ -230,6 +236,14 @@ experience with Qt is helpful, but not required.

 <li>

 <b>Improving Tor's ability to resist censorship</b>

 <br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>High</i>

+<br />

+Skill Level: <i>High</i>

+<br />

+Likely Mentors: <i>Nick</i>

+<br />

 The Tor 0.2.0.x series makes <a

 href="<svnsandbox>doc/design-paper/blocking.html">significant

 improvements</a> in resisting national and organizational censorship.

@@ -290,20 +304,27 @@ with others prior to implementation.

 </li>

 -->

-<!-- Matt already made good progress on this.

 <li>

 <b>An Improved and More Usable Network Map in Vidalia</b>

 <br />

+Priority: <i>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 would like to leverage KDE's Marble widget

-that gives us a better quality map and enables improved interactivity,

+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 might also consider adding the ability

+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 foo.com to exit

+more Tor exit relays and say, "I want my connections to exit

 from here."

 <br />

 This project will first involve getting familiar with Vidalia

@@ -316,11 +337,18 @@ 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>Tor Controller Status Event Interface</b>

 <br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium</i>

+<br />

+Likely Mentors: <i>Matt</i>

+<br />

 There are a number of status changes inside Tor of which the user may need

 to be informed. For example, if the user is trying to set up his Tor as a

 relay and Tor decides that its ports are not reachable from outside

@@ -386,7 +414,7 @@ href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal

 The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>

 is written by our fabulous anonymous

 contributer Tup. It's a DNS server written in Haskell that supports part of our <a

-href="https://<svnsandbox>doc/contrib/torel-design.txt">exitlist

+href="<svnsandbox>doc/contrib/torel-design.txt">exitlist

 design document</a>. Currently, it is functional and it is used by

 check.torproject.org and other users. The issues that are outstanding

 are mostly aesthetic. This wonderful service could use a much better

@@ -446,6 +474,14 @@ Also tricky will be adding rate-limiting to Libevent.

 <li>

 <b>Tuneup Tor!</b>

 <br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium to High</i>

+<br />

+Likely Mentors: <i>Nick, Roger, Mike</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

@@ -499,6 +535,14 @@ changes in performance on machines in different roles automatically.

 <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</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

@@ -508,8 +552,8 @@ as possible from globals.

 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>)

+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.

@@ -518,6 +562,14 @@ changes in performance on machines in different roles automatically.

 <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

@@ -528,7 +580,8 @@ 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 perspective developer should be able to understand and write new Java code, including

+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

@@ -539,6 +592,14 @@ to a small degree about design.

 <li>

 <b>Bring moniTor to life</b>

 <br />

+Priority: <i>Medium</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

@@ -577,22 +638,28 @@ with not too much involvement in the Tor internals.

 -->

 <li>

-<b>Porting Polipo to Windows</b>

+<b>Improving Polipo on Windows</b>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Low</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) handle spaces in path names and understand the filesystem

-namespace — that is, where application data, personal data,

-and program data typically reside in various versions of Windows. 2) the

-ability to handle ipv6 communications. 3) the ability to asynchronously

+1) the ability to asynchronously

 query name servers, find the system nameservers, and manage netbios

-and dns queries. 4) use native regex capabilities of Windows, rather

-than using 3rd party GNU regex libraries. 5) manage events and buffers

+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). 6) some sort of GUI config

+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.

+3) 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?

@@ -648,9 +716,17 @@ the core of the Blossom effort.

 <li>

 <b>Implement a torrent-based scheme for downloading Thandy packages</b>

 <br />

+Priority: <i>Medium</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 automatic updates of Tor and related

+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

@@ -663,6 +739,14 @@ there should be an easy way for them to help distributing the packages.

 <li>

 <b>Torbutton equivalent for Thunderbird</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 />

 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

@@ -673,22 +757,29 @@ push to build a Thunderbird extension similar to Torbutton.

 <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

+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

+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

+<a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;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,

+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

+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

+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://"

+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 />

@@ -700,6 +791,14 @@ with not too much involvement in the Tor internals.

 <li>

 <b>Usability testing of Tor</b>

 <br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Low to Medium</i>

+<br />

+Likely Mentors: <i>Andrew</i>

+<br />

 Especially the 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

@@ -709,6 +808,14 @@ structured process would be better.

 <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

@@ -718,259 +825,337 @@ 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</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.

+</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/roadmap/2008-12-19-roadmap-full.pdf">Tor development

+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>

+<h2><a class="anchor" href="#OtherCoding">Other Coding and Design related ideas</a></h2>

+<ol>

+<li>Tor relays don't work well on Windows XP. On

+Windows, Tor uses the standard <tt>select()</tt> system

+call, which uses space in the non-page pool. This means

+that a medium sized Tor relay will empty the non-page pool, <a

+href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">causing

+havoc and system crashes</a>. We should probably be using overlapped IO

+instead. One solution would be to teach <a

+href="http://www.monkey.org/~provos/libevent/">libevent</a> how to use

+overlapped IO rather than select() on Windows, and then adapt Tor to

+the new libevent interface. Christian King made a

+<a href="https://svn.torproject.org/svn/libevent-urz/trunk/">good

+start</a> on this in the summer of 2007.</li>

-<h2><a class="anchor" href="#Coding">Andere Ideen zu Programmierung und Design</a></h2>

+<li>We need to actually start building our <a href="<page

+documentation>#DesignDoc">blocking-resistance design</a>. This involves

+fleshing out the design, modifying many different pieces of Tor, adapting

+<a href="http://vidalia-project.net/">Vidalia</a> so it supports the

+new features, and planning for deployment.</li>

-<ol>

-  <li>Torserver funktionieren unter Windows XP nicht sehr gut. Wir

-  verwenden auf Windows den standardmäßigen <code>select</code>-Systemaufruf.

-  Dies bereitet gerade auf mittelgroßen Servern <a

-  href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">Probleme</a>.

-  Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine Lösung

-  wäre, <a href="http://www.monkey.org/~provos/libevent/">libevent</a>

-  beizubringen, Overlapped I/O statt <code>select()</code> zu wählen. Tor muss

-  dann an die neue libevent-Schnittstelle angepasst werden. Christian

-  King hat

-  <a href="https://svn.torproject.org/svn/libevent-urz/trunk/">einen guten

-  Anfang</a> gemacht.</li>

-  <li>Wie können wir die <a

-  href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> leichter

-  zu warten, verbessern und zu dokumentieren machen?</li>

-  <li>Wir sollten damit anfangen unser <a href="<page

-  documentation>#DesignDoc">gegen Blockierungen geschütztes Design</a> zu

-  implementieren. Dies beinhaltet die Ausarbeitung des Designs, die

-  Modifizierung diverser Teile von Tor, die Arbeit an einer <a

-  href="http://vidalia-project.net/">GUI</a>, die intuitiv ist und die Planung

-  für den Einsatz.</li>

-  <li>Wir brauchen ein flexibles Gerüst, um Ende-zu-Ende Attacken des

-  Netzverkehrs zu simulieren. Viele Forscher haben Simulatoren geschaffen, die

-  ihre Intuition, ob ein Angriff oder Verteidigung funktioniert, unterstützt.

-  Können wir einen Simulator bauen, der offen und gut dokumentiert ist? Dies

-  wird eine Menge neuer Forschung anregen. Schaue auch auf den <a

-  href="#Research">Eintrag unten</a>, um Details zu dieser Aufgabe zu entdecken.

-  Wenn es fertig ist, könntest du helfen, eine Veröffentlichung  dazu zu schreiben.</li>

-  <li>Momentan werden die Deskriptoren der versteckten Services nur

-  auf einigen wenigen Verzeichnisservern gespeichert. Dies ist

-  schlecht für die Privatsphäre und die Robustheit. Um mehr Robustheit

-  zu erlangen, sollten wir die privaten Daten aus den Deskriptoren

-  entfernen, um diese auf verschiedenen Plätzen spiegeln zu

-  können. Idealerweise hätten wir gern ein Speicher-/Backupsystem, das

-  verschieden zu den Verzeichnisservern ist. Das erste Problem ist,

-  das wir Format für die versteckten Services schaffen müssen, welches

-  a) ASCII statt binär ist, b) die Liste der Introductionpoints

-  verschlüsselt, solange man nicht die <tt>.onion</tt>-Adresse kennt

-  und c) den Verzeichnissen erlaubt, den Zeitstempel und die Signatur

-  eines Deskriptors zu verifizieren, so dass diese nicht mit falschen

-  überrumpelt werden. Zweitens wird es jedes verteilte Speichersystem

-  tun, solange es authentifizierte Updates erlaubt.</li>

-  <li>Torversionen ab 0.1.1.x unterstützen Cryptohardwarebeschleuniger

-    via OpenSSL. Bisher hat das niemand getestet. Möchte jemand gern

-    eine Karte haben und schauen, ob das funktioniert?</li>

-  <li>Eine Sicherheitsanalyse mit

-    "<a href="http://en.wikipedia.org/wiki/Fuzz_testing">Fuzz</a>"

-    machen.  Herausfinden, ob es da draußen gute Bibliotheken dafür

-    gibt. Gewinne Ruhm und Ehre, wenn wir nur wegen dir ein neues

-    Release herausbringen!</li>

-  <li>Tor nutzt TCP für den Transport und TLS für die Verschlüsselung

-    der Verbindungen. Dies ist einfach. Es bedeutet aber auch, dass

-    alle Zellen Verspätungen erfahren, wenn nur ein Paket verworfen

-    wird. Daher können wir nur bedingt TCP-Streams unterstützen. Es

-    gibt eine <a

-    href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">Liste

-    von Gründen</a>, warum wir nicht zu Transport per UDP gewechselt

-    sind. Es wäre schön, wenn diese Liste kürzer werden würde. Wir

-  haben auch eine <a

-  href="<svnsandbox>doc/100-tor-spec-udp.txt">Spezifikation für Tor

-  und UDP</a> &mdash; bitte lass uns wissen, wenn damit etwas nicht

-  stimmt.</li>

-  <li>Wir sind nicht weit davon entfernt, Unterstützung für IPv6 bei

-    Exitknoten zu haben. Falls du dich stark um IPv6 kümmerst, ist

-    das wahrscheinlich der Platz, um zu starten.</li>

-    

-<li>Wir brauchen einen Weg die Diagramme auf der Webseite aus Quellcode zu

-generieren (zum Beispiel das "How Tor Works" Bild auf der <a href="<page

-overview>">Übersichtsseite</a>), damit wir das Bild als UTF-8 text übersetzen

-können, statt es händisch mit Gimp zu ändern. Wir würden dies gerne als

-wml-Datei einbinden, damit die Übersetzung einfach ist und die Bilder in

-verschiedenen Sprachen erzeugt werden, wenn wir die Webseite erstellen.</li>

-

-<li>Wie können wir die <a

+<li>We need a flexible simulator framework for studying end-to-end

+traffic confirmation attacks. Many researchers have whipped up ad hoc

+simulators to support their intuition either that the attacks work

+really well or that some defense works great. Can we build a simulator

+that's clearly documented and open enough that everybody knows it's

+giving a reasonable answer? This will spur a lot of new research.

+See the entry <a href="#Research">below</a> on confirmation attacks for

+details on the research side of this task — who knows, when it's

+done maybe you can help write a paper or three also.</li>

+

+<li>Tor 0.1.1.x and later include support for hardware crypto accelerators

+via OpenSSL. It has been lightly tested and is possibly very buggy.  We're looking for more rigorous testing, performance analysis, and optimally, code fixes to openssl and Tor if needed.</li>

+

+<li>Perform a security analysis of Tor with <a

+href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determine

+if there are good fuzzing libraries out there for what we want. Win fame by

+getting credit when we put out a new release because of you!</li>

+

+<li>Tor uses TCP for transport and TLS for link

+encryption. This is nice and simple, but it means all cells

+on a link are delayed when a single packet gets dropped, and

+it means we can only reasonably support TCP streams. We have a <a

+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">list

+of reasons why we haven't shifted to UDP transport</a>, but it would

+be great to see that list get shorter. We also have a proposed <a

+href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">specification

+for Tor and

+UDP</a> &mdash; please let us know what's wrong with it.</li>

+

+<li>We're not that far from having IPv6 support for destination addresses

+(at exit nodes). If you care strongly about IPv6, that's probably the

+first place to start.</li>

+

+<li>We need a way to generate the website diagrams (for example, the "How

+Tor Works" pictures on the <a href="<page overview>">overview page</a>

+from source, so we can translate them as UTF-8 text rather than edit

+them by hand with Gimp. We might want to

+integrate this as an wml file so translations are easy and images are

+generated in multiple languages whenever we build the website.</li>

+

+<li>How can we make the <a

 href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>

-leichter warten, verbessern und dokumentieren?</li>

+easier to maintain, improve, and document?</li>

 </ol>

 <a id="Research"></a>

-<h2><a class="anchor" href="#Research">Forschung</a></h2>

-

+<h2><a class="anchor" href="#Research">Research</a></h2>

 <ol>

-  <li>Die Fingerprintattacken gegen Webseiten machen eine Liste von

-    einigen wenigen populären Webseiten, laden die Inhalte herunter

-    und machen einen Satz von Signaturen für jede Seite. Danach

-    beobachten sie den Verkehr des Torclients. Währenddessen gelangen sie

-    schnell zu einer Vermutung, welche Seite gerade besucht wird. Wie

-    effektiv ist dieser Angriff bezüglich der aktuellen Codebasis von

-    Tor? Beginne danach Verteidigungsmöglichkeiten auszuloten. Wir

-    könnten beispielsweise die Zellgröße von 512 Bytes auf 1024 Bytes

-    anheben und Techniken wie <a

-    href="http://freehaven.net/anonbib/#timing-fc2004">defensives

-    Verwerfen</a> anwenden. Wir könnten auch künstliche Verspätungen

-    einarbeiten. Welchen Einfluss haben diese Massnahmen und wie groß

-    ist der Einfluss auf die Benutzbarkeit?</li>

-  <li>Eine weitere Angriffsmöglichkeit (end-to-end traffic

-    confirmation attack) basiert darauf, dass der Verkehr zwischen

-    Alice und Bob beobachtet wird. Durch den <a

-    href="http://freehaven.net/anonbib/#danezis:pet2004">Vergleich

-    der Signaturen des Netzverkehrs kann man herausfinden, on man

-    denselben Stream verfolgt</a>. Bis jetzt akzeptiert Tor dies als

-    Fakt und nimmt an, dass dies in allen Fällen trivial ist. Ist das

-    wahr? Wieviel Verkehr von welcher Sorte braucht man, um sicher zu

-    sicher, dass es funktioniert? Gibt es Szenarien, die die Attacke

-    ausbremsen? Funktioniert Padding besser als anderes?</li>

-    <li>Eine verwandte Frage: Bringt der Betrieb eines Relays oder

-  eines Brückenservers zusätzlichen Schutz gegen Timingangriffe? Kann

-  ein externer Angreifer individuelle Ströme erkennen, obwohl er nicht

-  in die TLS-Ströme sehen kann? Hat die Höhe des durchgeleiteten

-  Verkehrs Einfluss? Was wäre, wenn der Client anderen Verkehr

-  verlangsamt, um es so aussehen zu lassen, dass er auch

-  weitergeleitet wird? Die selbe Queue könnte auch zur Maskierung der

-  Timings mit Techniken von <a

-  href="http://www.freehaven.net/anonbib/#ShWa-Timing06" >adaptivem

-  Padding</a> genutzt werden, aber ohne zusätzlich Traffic zu

-  erzeugen. Würde das das Timing für externe Angreifer verschleiern?

-  Müssten die Strategien für assymetrische Knoten angepasst werden?

-  Wäre es dort beispielsweise möglich, den Clienttraffic von anderem

-  zu unterscheiden? Oder ist das vielleicht für symmetrische

-  Verbindungen leichter?</li>

-  <li>Wiederhole die <a

-  href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta"

-  >Angriffe von Murdoch und Danezis von der Oakland 05</a> im

-  aktuellen Tor-Netzwerk. Schaue, ob du herausfinden kannst, warum das

-  bei einigen gut und bei anderen schlecht funktioniert. (Meine

-  Theorie ist, dass schnelle Knoten mit Restkapazität dem Angriff

-  besser widerstehen.) Wenn das wahr ist, experimentiere mit

-  <var>RelayBandwidthRate</var> und

-  <var>RelayBandwidthBurst</var>. Dabei betreibst du ein Relay,

-  welches als Client genutzt wird, um den Verkehr des Angreifers

-  weiterzuleiten. Was ist das richtige Verhältnis von

-  <var>RelayBandwidthRate</var> zu aktueller Kapazität? Gibt es

-  überhaupt ein Verhältnis? Wenn wir dabei sind, erhöht eine große

-  Zahl von Relays die Fehlerrate des Angriffs? (Das Tor-Netzwerk ist

-  nun fast zwei Größenordnungen gewachsen, seit die Veröffentlichung

-  geschrieben wurde.) Lies auf jeden Fall auch <a

-  href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the

-  Queue</a>.</li>

-  <li>Die Attacke auf die Routingzonen ist der Netzpfad zwischen

-    Alice und dem Eingangsknoten (bzw. zwischen dem Exitknoten und

-    Bob). In der Literatur wird dies als einfache Verbindung auf

-    einem Graph dargestellt. In der Praxis durchquert der Pfad viele

-    autonome Systeme. Es ist nicht ungewöhnlich, dass dasselbe

-    <a href="http://freehaven.net/anonbib/#feamster:wpes2004">autonome

-    System sowohl beim Eingangs- wie auch beim Ausgangspfad

-    erscheint</a>. Um nun herauszufinden, ob ein spezielles Alice-,

-    Eingangs-, Ausgangs-, Bobviereck gefährlich ist, müssten wir die

-    gesamte Routingzone des Internet herunterladen und Operationen

-    darauf ausführen. Gibt es praktische Abschätzungen, die die

-    Arbeit erleichtern können?</li>

-    <li>Andere Fragen in der Forschung, die die geografische

-    Verteilung betreffen, betrachten einen Kompromiss zwischen der Wahl

-    einer effizienten Route und einer zufälligen Route. Wirf einen Blick

-    auf das <a

-    href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">Positionspapier</a>

-    von Stephen Rollyson. Es diskutiert, wie man langsame Leitungen

-    auschalten kann, ohne die Anonymität zu stark einzuschränken. Die

-    Begründungen machen einen guten Eindruck, brauchen aber noch mehr

-    Arbeit.</li>

-  <li>Tor funktioniert nicht sehr gut, wenn Server eine asymmetrische

-    Bandbreite (Kabel oder DSL) haben. Tor hat separate

-    TCP-Verbindungen zwischen jedem Hop. Wenn nun die einkommenden

-    Pakete gut ankommen und die ausgehenden alle verworfen werden,

-    übertragen die die TCP-Pushback-Mechanismen diese Informationen

-    nicht gut hin zu den eingehenden Verbindungen. Eventuell sollte

-    Tor feststellen, wenn eine Menge an ausgehenden Verbindungen

-    verworfen werden und dann die eigehenden Verbindungen selbst

-    herunterregeln? Ich könnte mir ein Schema vorstellen, wo wir ein

-    konservatives Ratelimit suchen und das langsam vergrößern, bis

-    Pakete verworfen werden. Wir brauchen jemanden, der sich gut mit

-    Netzwerken auskennt, um dies zu simulieren und eine Lösung zu

-    finden. Wir müssen die Erosion in der Performance verstehen und

-    das als Motivation für Transport per UDP verstehen.</li>

-  <li>Ein verwandtes Thema ist die Kontrolle bei Netzüberlastung. Ist

-    unser Design ausreichend, um hohe Netzlast auszuhalten?

-    Vielleicht sollten wir mit Fenstern von variabler Größe

-    experimentieren? Das schien im <a

-    href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">Experiment

-    mit dem SSH-Durchsatz</a> gut zu funktionieren. Wir müssen das

-    messen und verbessern und bei guten Resultaten Tor überholen.</li>

-  <li>Unsere Ziele zum Schutz vor Zensur schließen ein, dass ein

-    Angreifer Tor-Verkehr von <a

-    href="<svnsandbox>doc/design-paper/blocking.html#sec:network-fingerprint">normalem

-    SSL-Verkehr unterscheiden</a> kann. Offensichtlich können wir keine

-    perfekte Steganographie erreichen und dabei benutzbar bleiben. Aber

-    wir möchten gern Angriffen, die nur wenige Pakete betrachten,

-    überwinden. Eine der verbliebenen Angriffe, die wir nicht sehr geprüft

-    haben, ist das Verhältnis von der Größe der Tor-Zellen (512 Byte)

-    zum restlichen Verkehr. Wieviel erkennt man davon, haben die

-    Leerungsmechanismen der Buffer einen Einfluss, könnte Padding helfen?</li>

-  <li>Tor-Verbindungen werden schrittweise aufgebaut, ein Knoten nach

-    dem anderen.  Also haben wir theoretisch die Möglichkeit, manche

-    Ströme schon nach dem zweiten Knoten die Tor-Wolke verlassen zu

-    lassen, andere nach dem dritten Knoten, und so weiter.  Dies erscheint

-    nett, weil es die Menge der austretenden Ströme, welcher ein bestimmter

-    Server sieht, begrenzt.  Wenn wir diesen Strom jedoch sicher haben wollen,

-    dann, laut unserer aktuellen Logik,  sollte der kürzeste Pfad mindestens 3

-    Knoten lang sein.  Das heisst, die anderen Ströme wären noch länger.  Wir

-    müssen diese Performance/Sicherheitsabwägung untersuchen.</li>

-   <li>Es ist nicht schwer, DoS Angriffe auf Tor-Server oder

-    Tor-Verzeischnisserver erfolgreich durchzuführen.  Sind Client-Puzzles die

-    richtige Anwort?  Welche anderen praktischen Herangehensweisen gibt es?

-    Bonuspunkte, wenn diese mit dem aktuellen Tor-Protokoll abwärtskompatibel

-    sind.</li>

-  <li>Programme, wie <a

-    href="<page torbutton/index>">Torbutton</a>,

-    versuchen den User-Agent des Browsers zu verstecken, indem sie

-    diesen durch eine gewöhnliche Angabe ersetzen. Dadurch kann ein

-    Angreifer Tor-Nutzer nicht durch einen Blick auf die

-    Nachrichtenköpfe erkennen. Die Software versucht einen, allgemein

-    genutzten Wert zu nehmen. Frage 1: Wie sehr schaden wir uns, wenn

-    wir die Firefox-Version periodisch anpassen? Wenn wir zu oft

-    updaten, kann man es unterscheiden. Machen wir es nicht, findet man

-    Tor-Nutzer heraus, da sie sehr alte Versionen nutzen. Die Antwort

-    hängt wahrscheinlich von den Firefox-Versionen, die es gibt,

-    ab. Frage 2: Die Leute fragen immer wieder, zwischen n verschiedenen

-    User-Agents zu wechseln. Hilft der Ansatz oder macht das keinen

-    Unterschied? Betrachte dabei Cookies und Tor-Nutzer, die periodisch

-    den User-Agent wechseln. Bösartige Webseiten greifen nur bestimmte

-    Browser an. Wie beeinflussen die Antworten auf diese Fragen diese

-    Antwort.</li>

-  <li>Momentan benutzen Tor-Clients eine aufgebaute Verbindungsstrecke

-    für zehn Minuten, nachdem diese aufgebaut wurde. Das Ziel hierfür

-    ist, das Netzwerk nicht mit Nachrichten zum Verbindungsaufbau zu

-    überlasten. Außerdem kann der Austrittsknoten dadurch kein Profil

-    über den Nutzer bilden. Es hat sich herausgestellt, dass zehn

-    Minuten zu lang sind. Insbesondere dann, wenn Verbindungen von

-    verschiedenen Protokollen (IM und HTTP) benutzt werden. Wenn wir

-    die Gesamtzahl an Erweiterungen der Verbindungsstrecke beibehalten,

-    gibt es effizientere/sichere Wege, Streams zu den

-    Verbindungsstrecken zu alloziieren oder präemptiv Strecken

-    aufzubauen? Natürlich muss dieser Punkt damit beginnen, dass

-    erforscht wird, welche Verbindungen die Programme typischerweise

-    benutzen. Damit hast du dann einen realistischen Ansatz, den du

-    optimierst.</li>

-  <li>Wie viele Brückenserver benötigt man, um die Verfügbarkeit zu

-    garantieren? Wir sollten die Abwanderung unseren Brückenservern messen.

-    Wenn es viel davon gibt, gibt es Möglichkeiten, dass die Nutzer

-    länger verbunden bleiben?</li>

+<li>The "website fingerprinting attack": make a list of a few

+hundred popular websites, download their pages, and make a set of

+"signatures" for each site. Then observe a Tor client's traffic. As

+you watch him receive data, you quickly approach a guess about which

+(if any) of those sites he is visiting. First, how effective is

+this attack on the deployed Tor codebase? Then start exploring

+defenses: for example, we could change Tor's cell size from 512

+bytes to 1024 bytes, we could employ padding techniques like <a

+href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>,

+or we could add traffic delays. How much of an impact do these have,

+and how much usability impact (using some suitable metric) is there from

+a successful defense in each case?</li>

+<li>The "end-to-end traffic confirmation attack":

+by watching traffic at Alice and at Bob, we can <a

+href="http://freehaven.net/anonbib/#danezis:pet2004">compare

+traffic signatures and become convinced that we're watching the same

+stream</a>. So far Tor accepts this as a fact of life and assumes this

+attack is trivial in all cases. First of all, is that actually true? How

+much traffic of what sort of distribution is needed before the adversary

+is confident he has won? Are there scenarios (e.g. not transmitting much)

+that slow down the attack? Do some traffic padding or traffic shaping

+schemes work better than others?</li>

+<li>A related question is: Does running a relay/bridge provide additional

+protection against these timing attacks? Can an external adversary that can't

+see inside TLS links still recognize individual streams reliably?

+Does the amount of traffic carried degrade this ability any? What if the

+client-relay deliberately delayed upstream relayed traffic to create a queue

+that could be used to mimic timings of client downstream traffic to make it

+look like it was also relayed? This same queue could also be used for masking

+timings in client upstream traffic with the techniques from <a

+href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptive padding</a>,

+but without the need for additional traffic. Would such an interleaving of

+client upstream traffic obscure timings for external adversaries? Would the

+strategies need to be adjusted for asymmetric links? For example, on

+asymmetric links, is it actually possible to differentiate client traffic from

+natural bursts due to their asymmetric capacity? Or is it easier than

+symmetric links for some other reason?</li>

+<li>Repeat Murdoch and Danezis's <a

+href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">attack from

+Oakland 05</a> on the current Tor network. See if you can learn why it

+works well on some nodes and not well on others. (My theory is that the

+fast nodes with spare capacity resist the attack better.) If that's true,

+then experiment with the RelayBandwidthRate and RelayBandwidthBurst

+options to run a relay that is used as a client while relaying the

+attacker's traffic: as we crank down the RelayBandwidthRate, does the

+attack get harder? What's the right ratio of RelayBandwidthRate to

+actually capacity? Or is it a ratio at all? While we're at it, does a

+much larger set of candidate relays increase the false positive rate

+or other complexity for the attack? (The Tor network is now almost two

+orders of magnitude larger than it was when they wrote their paper.) Be

+sure to read <a href="http://freehaven.net/anonbib/#clog-the-queue">Don't

+Clog the Queue</a> too.</li>

+<li>The "routing zones attack": most of the literature thinks of

+the network path between Alice and her entry node (and between the

+exit node and Bob) as a single link on some graph. In practice,

+though, the path traverses many autonomous systems (ASes), and <a

+href="http://freehaven.net/anonbib/#feamster:wpes2004">it's not uncommon

+that the same AS appears on both the entry path and the exit path</a>.

+Unfortunately, to accurately predict whether a given Alice, entry,

+exit, Bob quad will be dangerous, we need to download an entire Internet

+routing zone and perform expensive operations on it. Are there practical

+approximations, such as avoiding IP addresses in the same /8 network?</li>

+<li>Other research questions regarding geographic diversity consider

+the tradeoff between choosing an efficient circuit and choosing a random

+circuit. Look at Stephen Rollyson's <a

+href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">position

+paper</a> on how to discard particularly slow choices without hurting

+anonymity "too much". This line of reasoning needs more work and more

+thinking, but it looks very promising.</li>

+<li>Tor doesn't work very well when relays have asymmetric bandwidth

+(e.g. cable or DSL). Because Tor has separate TCP connections between

+each hop, if the incoming bytes are arriving just fine and the outgoing

+bytes are all getting dropped on the floor, the TCP push-back mechanisms

+don't really transmit this information back to the incoming streams.

+Perhaps Tor should detect when it's dropping a lot of outgoing packets,

+and rate-limit incoming streams to regulate this itself? I can imagine

+a build-up and drop-off scheme where we pick a conservative rate-limit,

+slowly increase it until we get lost packets, back off, repeat. We

+need somebody who's good with networks to simulate this and help design

+solutions; and/or we need to understand the extent of the performance

+degradation, and use this as motivation to reconsider UDP transport.</li>

+<li>A related topic is congestion control. Is our

+current design sufficient once we have heavy use? Maybe

+we should experiment with variable-sized windows rather

+than fixed-size windows? That seemed to go well in an <a

+href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh

+throughput experiment</a>. We'll need to measure and tweak, and maybe

+overhaul if the results are good.</li>

+<li>Our censorship-resistance goals include preventing

+an attacker who's looking at Tor traffic on the wire from <a

+href="<svnsandbox>doc/design-paper/blocking.html#sec:network-fingerprint">distinguishing

+it from normal SSL traffic</a>. Obviously we can't achieve perfect

+steganography and still remain usable, but for a first step we'd like to

+block any attacks that can win by observing only a few packets. One of

+the remaining attacks we haven't examined much is that Tor cells are 512

+bytes, so the traffic on the wire may well be a multiple of 512 bytes.

+How much does the batching and overhead in TLS records blur this on the

+wire? Do different buffer flushing strategies in Tor affect this? Could

+a bit of padding help a lot, or is this an attack we must accept?</li>

+<li>Tor circuits are built one hop at a time, so in theory we have the

+ability to make some streams exit from the second hop, some from the

+third, and so on. This seems nice because it breaks up the set of exiting

+streams that a given relay can see. But if we want each stream to be safe,

+the "shortest" path should be at least 3 hops long by our current logic, so

+the rest will be even longer. We need to examine this performance / security

+tradeoff.</li>

+<li>It's not that hard to DoS Tor relays or directory authorities. Are client

+puzzles the right answer? What other practical approaches are there? Bonus

+if they're backward-compatible with the current Tor protocol.</li>

+<li>Programs like <a

+href="<page torbutton/index>">Torbutton</a> aim to hide

+your browser's UserAgent string by replacing it with a uniform answer for

+every Tor user. That way the attacker can't splinter Tor's anonymity set

+by looking at that header. It tries to pick a string that is commonly used

+by non-Tor users too, so it doesn't stand out. Question one: how badly

+do we hurt ourselves by periodically updating the version of Firefox

+that Torbutton claims to be? If we update it too often, we splinter the

+anonymity sets ourselves. If we don't update it often enough, then all the

+Tor users stand out because they claim to be running a quite old version

+of Firefox. The answer here probably depends on the Firefox versions seen

+in the wild. Question two: periodically people ask us to cycle through N

+UserAgent strings rather than stick with one. Does this approach help,

+hurt, or not matter? Consider: cookies and recognizing Torbutton users

+by their rotating UserAgents; malicious websites who only attack certain

+browsers; and whether the answers to question one impact this answer.

+</li>

+<li>Right now Tor clients are willing to reuse a given circuit for ten

+minutes after it's first used. The goal is to avoid loading down the

+network with too many circuit extend operations, yet to also avoid having

+clients use the same circuit for so long that the exit node can build a

+useful pseudonymous profile of them. Alas, ten minutes is probably way

+too long, especially if connections from multiple protocols (e.g. IM and

+web browsing) are put on the same circuit. If we keep fixed the overall

+number of circuit extends that the network needs to do, are there more

+efficient and/or safer ways for clients to allocate streams to circuits,

+or for clients to build preemptive circuits? Perhaps this research item

+needs to start with gathering some traces of what connections typical

+clients try to launch, so you have something realistic to try to optimize.

+</li>

+<li>How many bridge relays do you need to know to maintain

+reachability? We should measure the churn in our bridges. If there is

+lots of churn, are there ways to keep bridge users more likely to stay

+connected?

+</li>

 </ol>

 <p><a href="<page contact>">Lass uns wissen</a>, wenn du bei einem