de/volunteer.wml (c09a61737) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 18874
# Last-Translator: mail 11 oliverknapp 22 de

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

<h2>Einige Dinge, die jeder tun kann</h2>

<ol>
 <li>Bitte überlege dir,
 einen <a href="<page docs/tor-doc-relay>">Server zu
 betreiben</a>, damit das Netzwerk weiter wächst.</li>
 <li>Erzähl es deinen Freunden! Bringe sie dazu, auch Server zu
 betreiben. Bringe sie dazu, auch versteckte Services zu
 betreiben. Bringe sie dazu, es wieder ihren Freunden zu
 erzählen.</li>
 <li>Wenn du die Ziele von Tor magst, bitte nimm dir einen Moment
 Zeit, um für das <a href="<page donate>">Projekt zu spenden</a>. Wir
 sind auch auf der Suche nach weiteren Sponsoren &mdash; wenn du
 Firmen, NGOs oder andere Organisationen kennst, die Anonymität,
 Privatsphäre und die Sicherheit der Kommunikation schätzen, dann
 lass sie von uns wissen.</li>
 <li>Wir suchen nach weiteren <a href="<page torusers>">guten
 Beispielen für Nutzer von Tor oder von Anwendungsfällen</a>. Falls
 du Tor für ein bestimmtes Szenario verwendest und uns davon erzählen
 möchtest, freuen wir uns, darüber zu hören.</li>
 </ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">unterstützende Anwendungen</a></h2>

<ol>
 <li>Wir brauchen mehr und bessere Methoden, um DNS-Abfragen abzufangen, damit diese
 nicht an einen lokalen Beobachter dringen, während wir versuchen, anonym zu
 bleiben. (Dies passiert, weil die Anwendung selbst DNS-Anfragen
 stellt, anstatt diese über Tor zu leiten.).
 <ul>
 <li>Wir müssen <a
 href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">all
 unsere Patches für tsocks</a> einspielen und einen Fork
 betreuen. Wir würden diesen auch auf unserem Server mit anbieten, wenn
 du möchtest.</li>
 <li>Wir sollten das Programm dsocks von Dug Song patchen, so dass es
 das Kommando <code>mapaddress</code> von der Controllerschnittstelle
 nutzt. Somit verschwenden wir nicht einen gesamten Round-trip
 innerhalb von Tor, um die Auflösung vor der Verbindung zu
 machen.</li>
 <li>Wir müssen unser <kbd>torify</kbd>-Skript so umgestalten, dass
 es erkennt, welches tsocks oder dsocks installiert ist und dieses
 dann richtig aufruft. Das bedeutet wahrscheinlich, dass deren
 Schnittstellen vereinheitlicht werden müssen und führt wahrscheinlich
 dazu, dass Code zwischen beiden geteilt werden muss oder dass eines
 komplett nicht mehr benutzt wird.</li>
 </ul></li>
 <li>Leute, die einen Server betreiben, teilen uns immer wieder mit,
 dass sie <var>BandwidthRate</var> in Abhängigkeit von der Uhrzeit setzen
 wollen. Anstatt das
 direkt in Tor zu implementieren, sollten wir lieber ein kleines
 Skript haben, das über die <a href="<page gui/index>">Torschnittstelle</a>
 spricht und ein <code>setconf</code> macht, um die Änderungen
 herbeizuführen. Natürlich würde es durch Cron ausgeführt oder es
 schläft eine bestimmte Zeit und macht dann die Änderungen. Kann
 das jemand für uns schreiben und wir packen das dann
 nach <a href="<svnsandbox>contrib/">contrib</a>? Das wäre
 eine gute Möglichkeit für den <a href="<page gui/index>">Tor GUI
 Wettbewerb</a>.</li>
 <li>Wenn wir gerade bei Geolocation sind, wäre es schön, wenn
 jemand eine Karte anfertigt, die die Standorte der Torserver
 anzeigt. Bonuspunkte gibt es, wenn es sich bei Änderungen am
 Netzwerk auf den neuesten Stand bringt. Der leichteste Weg, um
 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="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Dokumentation</a></h2>

<ol>
 <li>Bitte hilf Matt Edman mit der Dokumentation und HOWTOs für
 seinen <a href="http://vidalia-project.net/">Vidalia</a>.</li>
 <li>Kommentiere und dokumentiere unsere <a
 href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">Liste
 von Programmen, die durch Tor geroutet werden können</a>.</li>
 <li>Wir brauchen bessere Dokumentation für Programme, die dynamisch
 in Verbindungen eingreifen und diese durch Tor schicken. Für Linux
 und Windows scheinen tsocks (Linux), dsocks (BSD), und freecap gute Kandidaten.</li>
 <li>Wir haben eine riesige
 Liste <a href="<page support>">potentiell nützlicher Programme,
 die eine Schnittstelle zu Tor haben</a>. Welche sind in welchen
 Situationen gut? Bitte hilf uns, diese zu testen und dokumentiere
 die Ergebnisse.</li>
 <li>Hilf, die Webseite und die Dokumentation in andere Sprachen zu
 übersetzen. Schaue dir die <a href="<page translation>">Richtlinien
 zur Übersetzung</a> an, wenn du gern helfen möchtest. Wir brauchen
 auch Leute, um die Seiten in Arabisch oder Farsi zu übersetzen. Einen
 Überblick gibt
 es bei der <a href="<page translation-status>">Statusseite der
 Übersetzungen</a>.</li>
 </ol>

<a id="Coding"></a>
 Die untenstehenden Angaben wurden in der Originalsprache
 belassen. Da diese sich ausschließlich auf englischsprachige
 Bewerber beziehen.

<a id="Summer"></a>
<a id="Projects"></a>
<h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>

Here is a list of ideas that were proposed for the <a href="<page gsoc>">Google Summer of Code 2009</a>
but have not been put into practice. Some of the <a href="<svnsandbox>doc/spec/proposals/">current proposals</a> 
might also be short on developers. If you think you can help out, <a href="<page contact>"> let us know!</a>

<ol>

 
<li>
Help track the overall Tor Network status
 
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
average uptime of the network increasing? How many relays are qualifying
for Guard status this month compared to last month? What's the turnover
in terms of new relays showing up and relays shutting off? Periodically
people collect brief snapshots, but where it gets really interesting is
when we start tracking data points over time.
 
Data could be collected from the "Tor Node Scanner" in
<a href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, from
the server descriptors that each relay publishes, and from other
sources. Results over time could be integrated into one of the <a
href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be
kept separate. Speaking of the Tor Status pages, take a look at Roger's
<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
Status wish list</a>.
</li>

<li>
Improving Tor's ability to resist censorship
 
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.
But Tor still needs better mechanisms for some parts of its
anti-censorship design. For example, current Tors can only listen on a
single address/port combination at a time. There's
<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
proposal to address this limitation</a> and allow clients to connect
to any given Tor on multiple addresses and ports, but it needs more
work. Another anti-censorship project (far more difficult) is to try
to make Tor more scanning-resistant. Right now, an adversary can identify
<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
just by trying to connect to them, following the Tor protocol, and
seeing if they respond. To solve this, bridges could
<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
and not act like bridges until the user provides a bridge-specific key.
 
This project involves a lot of research and design. One of the big
challenges will be identifying and crafting approaches that can still
resist an adversary even after the adversary knows the design, and
then trading off censorship resistance with usability and robustness.
</li>

<li>
Tor Controller Status Event Interface
 
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
the user's network, we should alert the user. Currently, all the user
gets is a couple log messages in Vidalia's 'message log' window, which they
likely never see since they don't receive a notification that something
has gone wrong. Even if the user does actually look at the message log,
most of the messages make little sense to the novice user.
 
Tor has the ability to inform Vidalia of many such status changes, and
we recently implemented support for a couple of these events. Still,
there are many more status events the user should be informed of and we
need a better UI for actually displaying them to the user.
 
The goal of this project then is to design and implement a UI for
displaying Tor status events to the user. For example, we might put a
little badge on Vidalia's tray icon that alerts the user to new status
events they should look at. Double-clicking the icon could bring up a
dialog that summarizes recent status events in simple terms and maybe
suggests a remedy for any negative events if they can be corrected by
the user. Of course, this is just an example and one is free to
suggest another approach.
 
A person undertaking this project should have good UI design and layout
and some C++ development experience. Previous experience with Qt and
Qt's Designer will be very helpful, but are not required. Some
English writing ability will also be useful, since this project will
likely involve writing small amounts of help documentation that should
be understandable by non-technical users. Bonus points for some graphic
design/Photoshop fu, since we might want/need some shiny new icons too.
</li>

<li>
Tuneup Tor!
 
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
<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
relays lie about their bandwidth</a>;
to address this, Tor currently caps the maximum bandwidth
it's willing to believe any relay provides. This is a limited fix, and
a waste of bandwidth capacity to boot. Instead,
Tor should possibly measure bandwidth in a more distributed way, perhaps
as described in the
<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
Tor"</a> paper
by Snader and Borisov. One could use current testing code to
double-check this paper's findings and verify the extent to which they
dovetail with Tor as deployed in the wild, and determine good ways to
incorporate them into their suggestions Tor network without adding too
much communications overhead between relays and directory
authorities.
</li>

<li>
Improve our unit testing process
 
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
refactoring of some parts of Tor, in order to dissociate as much logic
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>)
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.
</li>

<li>
Help revive an independent Tor client implementation
 
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
href="http://code.google.com/android/">Android</a>. The first step
would be to port the existing code and execute it in an Android
environment. Next, the code should be updated to support the newer Tor
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.
 
A perspective 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
when things are underdocumented. This project is mostly about coding and
to a small degree about design.
</li>

<li>
Bring moniTor to life
 
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
system information of the underlying machine. When running this tool, it
would dynamically update its content like top does for Linux processes.
<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
or-dev post</a> might be a good first read.
 
A person interested in this should be familiar
with or willing to learn about administering a Tor relay and configuring
it via its control port. As an initial prototype is written in Python,
some knowledge about writing Python code would be helpful, too. This
project is one part about identifying requirements to such a
tool and designing its interface, and one part lots of coding.
</li>

<li>
Porting Polipo to Windows
 
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 &mdash; 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
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
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
and reporting tool, bonus if it has a systray icon with right clickable
menu options. Double bonus if it's cross-platform compatible.
</li>

<!-- Is Blossom development still happening?
<li>
Rework and extend Blossom
 
Rework and extend Blossom (a tool for monitoring and
selecting appropriate Tor circuits based upon exit node requirements
specified by the user) to gather data in a self-contained way, with
parameters easily configurable by the user. Blossom is presently
implemented as a single Python script that interfaces with Tor using the
Controller interface and depends upon metadata about Tor nodes obtained
via external processes, such as a webpage indicating status of the nodes
plus publically available data from DNS, whois, etc. This project has
two parts: (1) Determine which additional metadata may be useful and
rework Blossom so that it cleanly obtains the metadata on its own rather
than depend upon external scripts (this may, for example, involve
additional threads or inter-process communication), and (2) develop a
means by which the user can easily configure Blossom, starting with a
configuration file and possibly working up to a web configuration engine.
Knowledge of Tor and Python are important; knowledge of
TCP, interprocess communication, and Perl will also be helpful. An
interest in network neutrality is important as well, since the
principles of evaluating and understanding internet inconsistency are at
the core of the Blossom effort.
</li>

<li>
Improve Blossom: Allow users to qualitatively describe exit nodes they desire
 
Develop and implement a means of affording Blossom
users the ability to qualitatively describe the exit node that they
want. The Internet is an inconsistent place: some Tor exit nodes see
the world differently than others. As presently implemented, Blossom (a
tool for monitoring and selecting appropriate Tor circuits based upon
exit node requirements specified by the user) lacks a sufficiently rich
language to describe how the different vantage points are different.
For example, some exit nodes may have an upstream network that filters
certain kinds of traffic or certain websites. Other exit nodes may
provide access to special content as a result of their location, perhaps
as a result of discrimination on the part of the content providers
themselves. This project has two parts: (1) develop a language for
describing characteristics of networks in which exit nodes reside, and
(2) incorporate this language into Blossom so that users can select Tor
paths based upon the description.
Knowledge of Tor and Python are important; knowledge of
TCP, interprocess communication, and Perl will also be helpful. An
interest in network neutrality is important as well, since the
principles of evaluating and understanding internet inconsistency are at
the core of the Blossom effort.
</li>
-->
<li>
Implement a torrent-based scheme for downloading Thandy packages
 
<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
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
efficiently, and using libtorrent seems to be a possible solution. If you
think of other good ideas, great - please do let us know! 
We also need to investigate how to include our mirrors better. If possible,
there should be an easy way for them to help distributing the packages.
</li>

<li>
Torbutton equivalent for Thunderbird
 
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
the outgoing mail that it sends. At some point we should start a new
push to build a Thunderbird extension similar to Torbutton.
</li>

<li>
New Torbutton Features
 
There are several <a
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
'New Identity' with Vidalia</a>,
<a href="https://bugs.torproject.org/flyspray/index.php?do=details&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,
<a
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
Tor status reporting</a>, and <a
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.
 
This work would be independent coding in Javascript and the fun world of <a
href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
with not too much involvement in the Tor internals.
</li>

<li>
Usability testing of Tor
 
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
structured process would be better.
</li>

<li>
Translation wiki for our website
 
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
in place for Vidalia, Torbutton, and Torcheck. However, Pootle only
translates strings that are in the "po" format, and our website uses wml
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>
Bring up new ideas!
 
Don't like any of these? Look at the <a
href="<svnsandbox>doc/roadmap/2008-12-19-roadmap-full.pdf">Tor development
roadmap</a> for more ideas.
</li>

</ol>

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

<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
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
leichter warten, verbessern und dokumentieren?</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Forschung</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>
 </ol>

<a href="<page contact>">Lass uns wissen</a>, wenn du bei einem
 dieser Punkte Fortschritte gemacht hast.

</div>

#include <foot.wmi>

tor-webwml.git

Update german translation of: trunk/de/volunteer.wml