de/volunteer.wml (7904aa1ba) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 17898
# Last-Translator: jens@kubieziel.de, peter@palfrader.org

#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 gute 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>Wir haben eine Vielzahl von Wegen, um
 das <a
 href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">Tornetzwerk
 in einem bestimmten Land zu verlassen</a>. Aber all diese Wege
 brauchen den Namen eines speziellen Torservers. Es wäre schön,
 wenn man nur ein Land angeben muss und automatisch wird ein
 Server ausgewählt. Der beste Weg ist wahrscheinlich, Blossoms
 Verzeichnis herunterzuladen und einen lokalen Blossomclient laufen
 zu lassen, der die Verzeichnisse sicher lädt, die
 <code>.country.blossom</code>-Hostnamen mitschneidet und dann das
 richtige tut.</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 2008</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>
Tor Node Scanner improvements
 
Similar to the SoaT exit scanner (or perhaps even during exit scanning),
statistics can be gathered about the reliability of nodes. Nodes that
fail too high a percentage of their circuits should not be given
Guard status. Perhaps they should have their reported bandwidth
penalized by some ratio as well, or just get marked as Invalid. In
addition, nodes that exhibit a very low average stream capacity but
advertise a very high node bandwidth can also be marked as Invalid.
Much of this statistics gathering is already done, it just needs to be
transformed into something that can be reported to the Directory
Authorities to blacklist/penalize nodes in such a way that clients
will listen.
 
In addition, these same statistics can be gathered about the traffic
through a node. Events can be added to the <a
href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Tor Control
Protocol</a> to
report if a circuit extend attempt through the node succeeds or fails, and
passive statistics can be gathered on both bandwidth and reliability
of other nodes via a node-based monitor using these events. Such a
scanner would also report information on oddly-behaving nodes to
the Directory Authorities, but a communication channel for this
currently does not exist and would need to be developed as well.
</li>

<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" item above, 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>
Better Debian/Ubuntu Packaging for Tor+Vidalia
 
Vidalia currently doesn't play nicely on Debian and Ubuntu with the
default Tor packages. The current Tor packages automatically start Tor
as a daemon running as the debian-tor user and (sensibly) do not have a
<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
in the default torrc. Consequently, Vidalia will try
to start its own Tor process since it could not connect to the existing
Tor, and Vidalia's Tor process will then exit with an error message
the user likely doesn't understand since Tor cannot bind its listening
ports &mdash; they're already in use by the original Tor daemon.
 
The current solution involves either telling the user to stop the
existing Tor daemon and let Vidalia start its own Tor process, or
explaining to the user how to set a control port and password in their
torrc. A better solution on Debian would be to use Tor's ControlSocket,
which allows Vidalia to talk to Tor via a Unix domain socket, and could
possibly be enabled by default in Tor's Debian packages. Vidalia can
then authenticate to Tor using filesystem-based (cookie) authentication
if the user running Vidalia is also in the debian-tor group.
 
This project will first involve adding support for Tor's ControlSocket
to Vidalia. The student will then develop and test Debian and Ubuntu
packages for Vidalia that conform to Debian's packaging standards and
make sure they work well with the existing Tor packages. We can also
set up an apt repository to host the new Vidalia packages.
 
The next challenge would be to find an intuitive usable way for Vidalia
to be able to change Tor's configuration (torrc) even though it is
located in <code>/etc/tor/torrc</code> and thus immutable. The best
idea we've come up with so far is to feed Tor a new configuration via
the ControlSocket when Vidalia starts, but that's bad because Tor starts
each boot with a different configuration than the user wants. The second
best idea
we've come up with is for Vidalia to write out a temporary torrc file
and ask the user to manually move it to <code>/etc/tor/torrc</code>,
but that's bad because users shouldn't have to mess with files directly.
 
A person undertaking this project should have prior knowledge of
Debian package management and some C++ development experience. Previous
experience with Qt is helpful, but not required.
</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/Polipo/Vidalia Auto-Update Framework
 
We're in need of a good authenticated-update framework.
Vidalia already has the ability to notice when the user is running an
outdated or unrecommended version of Tor, using signed statements inside
the Tor directory information. Currently, Vidalia simply pops
up a little message box that lets the user know they should manually
upgrade. The goal of this project would be to extend Vidalia with the
ability to also fetch and install the updated Tor software for the
user. We should do the fetches via Tor when possible, but also fall back
to direct fetches in a smart way. Time permitting, we would also like
to be able to update other
applications included in the bundled installers, such as Polipo and
Vidalia itself.
 
To complete this project, the student will first need to first investigate
the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
their strengths, weaknesses, security properties, and ability to be
integrated into Vidalia. If none are found to be suitable, the student
will design their own auto-update framework, document the design, and
then discuss the design with other developers to assess any security
issues. The student will then implement their framework (or integrate
an existing one) and test it.
 
A person undertaking this project should have good C++ development
experience. Previous experience with Qt is helpful, but not required. One
should also have a good understanding of common security
practices, such as package signature verification. Good writing ability
is also important for this project, since a vital step of the project
will be producing a design document to review and discuss
with others prior to implementation.
</li>

<li>
An Improved and More Usable Network Map in Vidalia
 
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,
such as allowing the user to click on individual relays or circuits to
display additional information. We might also consider adding 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
from here."
 
This project will first involve getting familiar with Vidalia
and the Marble widget's API. One will then integrate the widget
into Vidalia and customize Marble to be better suited for our application,
such as making circuits clickable, storing cached map data in Vidalia's
own data directory, and customizing some of the widget's dialogs.
 
A person undertaking this project should have good C++ development
experience. Previous experience with Qt and CMake is helpful, but not
required.
</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>
Improvements on our active browser configuration tester -
<a href="https://check.torproject.org/">https://check.torproject.org/</a>
 
We currently have a functional web page to detect if Tor is working. It
has a few places where it falls short. It requires improvements with
regard to default languages and functionality. It currently only responds
in English. In addition, it is a hack of a perl script that should have
never seen the light of day. It should probably be rewritten in python
with multi-lingual support in mind. It currently uses the <a
href="http://exitlist.torproject.org/">Tor DNS exit list</a>
and should continue to do so in the future. It currently result in certain
false positives and these should be discovered, documented, and fixed
where possible. Anyone working on this project should be interested in
DNS, basic perl or preferably python programming skills, and will have
to interact minimally with Tor to test their code.
 
If you want to make the project more exciting
and involve more design and coding, take a look at <a
href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
131-verify-tor-usage.txt</a>.
</li>

<li>
Improvements on our DNS Exit List service -
<a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
 
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
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
website using the common Tor theme. It would be best served with better
documentation for common services that use an RBL. It could use more
publicity. A person working on this project should be interested in DNS,
basic RBL configuration for popular services, and writing documentation.
The person would require minimal Tor interaction &mdash; testing their
own documentation at the very least. Furthermore, it would be useful
if they were interested in Haskell and wanted to implement more of the
torel-design.txt suggestions.
</li>

<li>
Testing integration of Tor with web browsers for our end users
 
The Tor project currently lacks a solid test suite to ensure that a
user has a properly and safely configured web browser. It should test for as
many known issues as possible. It should attempt to decloak the
user in any way possible. Two current webpages that track these
kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
with their proof of concept code, bug issues, etc</a>. HD Moore runs
the <a href="http://metasploit.com/research/projects/decloak/">metasploit
decloak website</a>. A person interested in defending Tor could start
by collecting as many workable and known methods for decloaking a
Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
be helpful as a start.) One should be familiar with the common pitfalls but
possibly have new methods in mind for implementing decloaking issues. The
website should ensure that it tells a user what their problem is. It
should help them to fix the problem or direct them to the proper support
channels. The person should also be closely familiar with using Tor and how
to prevent Tor information leakage.
</li>

<li>
Libevent and Tor integration improvements
 
Tor should make better use of the more recent features of Niels
Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
library. Tor already uses Libevent for its low-level asynchronous IO
calls, and could also use Libevent's increasingly good implementations
of network buffers and of HTTP. This wouldn't be simply a matter of
replacing Tor's internal calls with calls to Libevent: instead, we'll
need to refactor Tor to use Libevent calls that do not follow the
same models as Tor's existing backends. Also, we'll need to add
missing functionality to Libevent as needed &mdash; most difficult likely
will be adding OpenSSL support on top of Libevent's buffer abstraction.
Also tricky will be adding rate-limiting to Libevent.
</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 TorFlow: see
the "Tor Node Scanner improvements" item)
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>
Torbutton improvements
 
Torbutton has a number of improvements that can be made in the post-1.2
timeframe. Most of these are documented as feature requests in the <a
href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">Torbutton
flyspray section</a>. Good examples include: stripping off node.exit on http
headers, more fine-grained control over formfill blocking, improved referrer
spoofing based on the domain of the site (a-la <a
href="https://addons.mozilla.org/en-US/firefox/addon/953">refcontrol extension</a>),
tighter integration with Vidalia for reporting Tor status, a New Identity
button with Tor integration and multiple identity management, and anything
else you might think of.
 
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>
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>

<li>
Make our diagrams beautiful and automated
 
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>
Improve the LiveCD offerings for the Tor community
 
How can we make the <a
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
easier to maintain, improve, and document?
</li>

<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>
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>Du magst keinen von den obigen Punkten? Schaue dir die <a
 href="<svnsandbox>doc/design-paper/roadmap-future.pdf">weiteren Pläne</a> für
 weitere Ideen an.</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 volunteer page to r17898