fr/volunteer.wml (874967385) - tor-webwml.git

volunteer.wml

## translation metadata
# Revision: $Revision$
# Translation-Priority: 4-optional
#include "head.wmi" TITLE="Tor: Volunteer" CHARSET="UTF-8"
<div class="main-column">

<h2>Un certain nombre de choses que vous pouvez faire:</h2>
<ol>
<li>Pensez à <a href="<page docs/tor-doc-relay>">héberger un noeud</a> pour
aider à la croissance du réseau Tor.</li>
<li>Informez vos amis ! Faites-leur héberger des serveurs. Faites-leur utiliser
les services
cachés. Encouragez-les à informer leurs propres amis.</li>
<li>Si vous adhérez aux objectifs de Tor, prenez s'il-vous-plaît un moment <a
href="<page donate>">pour faire un don et aider le développement futur de
Tor</a>. Nous recherchons également plus de sponsors &mdash; si vous
connaissez des entreprises, des ONG, ou d'autres organisations qui veulent
un anonymat,une protection de la vie privée, sécurité dans leurs
communications, parlez-leur de nous.</li>
<li>Nous sommes recherchons plus <a href = "<page torusers>"> de bons exemples
d'utilisateurs de Tor et des cas d'utilisation Tor</a>. Si vous utilisez Tor
dans un scénario ou le but, non encore décrits sur cette page, et vous êtes
à l'aise pour le partager avec nous,nous aimerions que vous nous en parliez.</li>
</ol>

Tor has <a href="<page open-positions>">two open positions</a>. Please <a
href="<page contact>">contact us</a> if you are qualified!

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
<ol>
<li>Aidez-nous à traduire le site et la documentation dans d'autres
langues. Allez voir les <a href="<page translation>">conseils de
traduction</a> si vous souhaitez le faire. Nous avons besoin plus
spécialement de personnes pour traduire en Arabe ou en Persan pour les
utilisateurs Tor situés dans les zones censurées.</li>
<li>Évaluez et documentez <a
href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">notre
liste de programmes</a> pouvant être utilisés avec Tor.</li>
<li>Nous avons toute une liste de <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programmes
potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles
et dans quelles situations ? Contribuez à les tester et à documenter les
résultats.</li>
</ol>

<a id="Advocacy"></a>
<h2><a class="anchor" href="#Advocacy">Plaidoyer</a></h2>
<ol>
<li>Créer un <a href="https://wiki.torproject.org/noreply/CommunityLogos">logo
communautaire</a> sous licence Creative commons que chacun puisse utiliser
et modifier</li>
<li>Créer une présentation qui puisse être utilisée lors des nombreux meetings
de groupe sur toute la planète.</li>
<li>Créer une vidéo sur les utilisations positives de Tor, sur ce qu'est Tor ou
comment l'utiliser. Quelques personnes ont déjà commencé sur <a
href="http://media.torproject.org/video/">le serveur Média de Tor</a>, <a
href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>,
et <a href="http://www.youtube.com/freedom4internet">Youtube</a>.</li> 
<li>Créer un poster ou un jeu de posters autour d'un thème tel que "Tor pour la
Liberté !"</li>
</ol>

<a id="Coding"></a> <a id="Summer"></a> <a id="Projects"></a>
<h2><h2><a class="anchor" href="#Projects">Bons Projets de code</a></h2></h2>

You may find some of these projects to be good <a href="<page gsoc>">Google
Summer of Code 2010</a> ideas. We have labelled each idea with how useful it
would be to the overall Tor project (priority), how much work we expect it
would be (effort level), how much clue you should start with (skill level),
and which of our <a href="<page people>#Core">core developers</a> would be
good mentors. If one or more of these ideas looks promising to you, please
<a href="<page contact>">contact us</a> to discuss your plans rather than
sending blind applications. You may also want to propose your own project
idea &mdash; which often results in the best applications.

<ol>

<li>
Tor Browser Bundle for Linux/Mac OS X Priority: High
 Effort Level: High Skill Level: Medium 
Likely Mentors: Steven, Erinn, Jacob, Andrew The Tor Browser
Bundle incorporates Tor, Firefox, Polipo, and the Vidalia user interface
(and optionally the <a href="http://pidgin.im/">Pidgin</a> Instant Messaging
client). 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. However, there is currently no released package for
Linux and Mac OS X, so this project would be to implement Tor Browser Bundle
for OS X and continue work on the Tor Browser Bundle for Linux. 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. Some work on this was completed as
part of the Google Summer of Code 2009. Another part of this project is to
identify all of the traces left behind by using a Tor Browser Bundle on Mac
OS X or Linux. Developing ways to stop, counter, or remove these traces is
a final step. 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. Part of this project
could be usability testing of Tor 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>
Aider à mesurer l'état général du réseau Tor Priorité:
Moyenne à Haute Effort à fournir: Moyen 
Compétences requises: Moyennes Tuteurs potentiels: Karsten,
Roger Il serait bon de mettre en place un système automatisé pour
rendre compte de la santé du réseau au cours du temps, avec des graphiques,
etc... Une partie de ce projet consisterait à trouver un système de mesure
adéquat pour évaluer la santé du réseau et sa croissance. Est-ce-que sa
durée de fonctionnement augmente ? Combien de relais sont en cours de
qualification pour adopter l'état Guard ce mois-ci comparé au mois précédent
? Comment est le turnover entre les nouveaux relais qui apparaissent et ceux
qui s'éteignent ? Régulièrement, des personnes collectes de brèves photos
d'état mais il est plus intéressant de le faire sur une longue période. Les données peuvent être collectées depuis les scanners du réseau Tor
dans <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>,
depuis les descripteurs de serveurs publiés par chaque relais et ailleurs
également. Les résultats sur le long terme pourraient être présentés sur
l'une des pages web de <a href="https://torstatus.blutmagie.de/">Tor
Status</a> ou éventuellement ailleurs. En parlant des pages Tor Status,
prenez le temps de consulter <a
href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">la
"whish-list" Tor Status</a> de Roger.
</li>

<li>
Improving Tor's ability to resist censorship Priority:
Medium to High Effort Level: Medium Skill Level:
High Likely Mentors: Nick, Roger, Steven The Tor
0.2.1.x series makes <a
href="<gitblob>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="<gitblob>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 area
that needs work is our <a
href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
service. See e.g. <a
href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's or-dev
post</a> from December for details &mdash; lots of design work remains. 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>

Tuneup Tor!
 
Priority: Medium to High
 
Effort Level: Medium to High
 
Skill Level: High
 
Likely Mentors: Nick, Roger, Mike, Karsten
 
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>
Améliorer Polipo sous Windows Priorité: Moyenne à Haute
 Effort à fournir: Moyen Compétences requises:
Moyennes Tuteurs potentiels: Chris Il faut nous
aider à porter <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> sous
Windows. Quelques exemples de sujets à retenir:
<ol><li> la possibilité d'interroger de manière asynchrone les serveurs de noms,
trouver les serveurs de noms utilisés par le système et gérer les requêtes
netbios et dns.</li>
<li> gérer nativement les tampons et les évènement (i.e. sous les OS de type
Unix, Polipo occupe 25% de la ram, sous Windows, c'est selon la
configuration).</li>
<li> un outil graphique de configuration et de rapport, avec en bonus, une icône
de barre système avec un menu d'option par clic-droit. Double-bonus si c'est
multiplateforme.</li>
<li> permettre au logiciel d'utiliser le registre Windows et de gérer
correctement les emplacements de répertoire Windows tels que "C:\Program
Files\Polipo"</li>
</ol>
</li>

<li>
Tor Controller Status Event Interface for Vidalia Priority:
Medium Effort Level: Medium Skill Level: Low
to Medium Likely Mentors: Matt 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>
Improve our unit testing process Priority: Medium Effort Level: Medium Skill Level: Medium 
Likely Mentors: Nick, Erinn 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 with independent Tor client implementations Priority:
Medium Effort Level: High Skill Level: Medium
to High Likely Mentors: Bruce, Nathan Others are
currently working on Tor clients for Java, Android, and Maemo environments.
The first step is to get a handle on the current state of the project in
which you are interested in helping; <a
href="http://github.com/brl/JTor">Tor for Java</a>, <a
href="https://svn.torproject.org/svn/projects/android/trunk/">Android/Orbot</a>
, or Tor for Maemo. Check out the repository and familiarlize yourself with
the source code. Further, support for requesting or even providing Tor
hidden services would be neat, but not required. 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 when things are underdocumented. This
project is mostly about coding and to a small degree about design.
</li>

<!--<li>

New Torbutton Features
 
Priority: Medium
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Mike
 
There are several <a
href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">good
feature requests</a> on the Torbutton Flyspray section. In particular, <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">Integrating
'New Identity' with Vidalia</a>,
<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&amp;id=637">preserving
specific cookies</a> when cookies are cleared,
<a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">better
referrer spoofing</a>, <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">correct
Tor status reporting</a>, and <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;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>

New Thandy Features
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium to High
 
Likely Mentors: Martin
 
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:
<ol>
<li> Integration of the <a
href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
Python library</a>
for authenticated HTTPS downloads.</li>
<li> 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.</li>
<li> 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>
</ol>
</li> -->
<li>
Simulateur pour les connexion Internet lentes Priorité:
Moyenne Effort à fournir: Moyen Compétences
requises: Moyennes Tuteurs potentiels: Steven De
nombreux utilisateurs de Tor disposent de connexions à Internet de qualité
médiocre avec une faible bande passante, beaucoup de latence et de
nombreuses pertes ou tris de paquets. A l'usage, Tor ne se comporte pas très
bien dans ces conditions mais il est difficile d'améliorer la situation sans
pouvoir reproduire le problème en laboratoire. Ce projet consiste à
élaborer un environnement de simulation d'une connection médiocre de manière
à ce que l'effet sur Tor puisse être mesuré. D'autres composants à mettre en
place pourraient être des utilitaires de test des propriétés des connexions
disponibles pour mesurer l'effet sur les performance des modifications
apportées à Tor. Le responsable du projet peut utiliser les outils
de son choix mais dummynet (pour FreeBSD) et nisnet (pour Linux) sont deux
composants sur lesquels le projet peut être construit. Les étudiants
devraient avoir de l'expérience en programmation réseau et en TCP/IP, de
préférence compétents en C et en langage de script.
</li>

<li>
Une meilleure et plus utile carte du réseau dans Vidalia 
Priorité: Faible à Moyenne Effort à fournir: Moyen Compétences requises: Moyennes Tuteurs potentiels:
Matt Une des fonctionnalités courantes de Vidalia est la carte
du réseau qui montre à l'utilisateur l'emplacement approximatif des relais
du réseau Tor et qui trace les chemins empruntés par le trafic qui y est
injecté. La carte n'est pas très interactive pour le moment et est de
médiocre qualité graphique. A la place, nous avons implémenté le widget KDE
Marble pour nous donner une carte de meilleure qualité et nous permettre une
meilleure interactivité tel que l'affichage des informations d'un relais ou
d'un chemin lorsqu'on clique dessus. Nous voulons ajouter la possibilité
pour les utilisateurs de cliquer sur un relais ou un pays contenant un ou
plusieurs relais de sortie Tor et dire "Je veux que mes connexions de sortie
se fasse à partir d'ici.". Ce projet implique d'abord d'être
familiarisé avec Vidalia et l'API du widget Marble. On pourra ensuite
intégrer le widget dans Vidalia et adapter Marble à notre application, comme
rendre les circuits cliquables, l'enregistrement du cache des données de la
carte dans le répertoire de Vidalia et l'adaptation de certaines des
interfaces du widget. Une personne intéressée par ce projet devrait
disposer d'une bonne expérience de développement en C++. Une expérience avec
Qt et Cmake serait un vrai plus.
</li>

<li>
Torbutton equivalent for Thunderbird Priority: Medium
 Effort Level: High Skill Level: High 
Likely Mentors: Mike 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>

Intermediate Level Network Device Driver
 
Priority: Low
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Martin
 
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>
Améliorer Tor Weather Priorité: Moyenne Effort à
fournir: Moyen Compétences requises: moyennes 
Tuteurs potentiels: Christian, Roger <a
href="https://weather.torproject.org/">Tor weather</a> est un outil qui
permet de recevoir un email indiquant le moment où le relais que vous
désirez tracer s'arrête. Actuellement, il n'est pas vraiment utile pour les
personnes qui utilisent la fonctionnalité d'hibernation de Tor ou pour ceux
qui doivent éteindre régulièrement leur relais. Au cours du projet, Tor
weather pourrait être enrichi pour permettre des configurations plus
souples. D'autres améliorations sont également envisageables: Weather
pourrait vous envoyer des avertissements lorsque votre relais fonctionne
avec une version périmée de Tor ou lorsque votre bande passante atteint un
seuil limite. Il pourrait être également un outil sympathique pour vous
indiquer si votre relais vous permet d'avoir un <a href="<page
tshirt>">T-Shirt</a> ou envoyer des rappels au autorités d'annuaire que
leurs clefs vont bientôt expirer. Soyez créatifs et n'oubliez pas que ce
projet vous permet de juger de l'état du réseau dans le but de vous aider à
terminer votre travail plus rapidement ! Consultez également son <a
href="https://svn.torproject.org/svn/weather/trunk/README">README</a> et <a
href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.
</li>

<li>
Better Debian/Ubuntu Packaging for Tor+Vidalia Priority:
Medium Effort Level: Medium Skill Level:
Medium Likely Mentors: Erinn, Peter 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="<gitblob>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>

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>
Improving the Tor QA process: Continuous Integration for builds Priority: Medium Effort Level: Medium Skill
Level: Medium Likely Mentors: Erinn It would be
useful to have automated build processes for Windows and probably other
platforms. The purpose of having a continuous integration build environment
is to ensure that Windows isn't left behind for any of the software projects
used in the Tor project or its accompanying. Buildbot may be a good
choice for this as it appears to support all of the platforms Tor does. See
the <a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
buildbot</a>. There may be better options and the person undertaking
this task should evaluate other options. Any person working on this
automatic build process should have experience or be willing to learn how to
build all of the respective Tor related code bases from
scratch. Furthermore, the person should have some experience building
software in Windows environments as this is the target audience we want to
ensure we do not leave behind. It would require close work with the Tor
source code but probably only in the form of building, not authoring. 
Additionally, we need to automate our performance testing for all
platforms. We've got buildbot (except on Windows &mdash; as noted above) to
automate our regular integration and compile testing already, but we need to
get our network simulation tests (as built in torflow) 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>

Usability testing of Tor
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Low to Medium
 
Likely Mentors: Andrew
 
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>
Un proxy IRC d'authentification Priorité: Moyenne Effort à fournir: Moyen à Important Compétences requises:
Moyennes à Hautes Tuteurs potentiels: Sebastian, Weasel,
Roger Le monde entier a besoin d'un proxy IRC
d'authentification. Comme nous le rappelle régulièrement la bande dessinée
web Penny Arcade: "Utilisateur Internet+ anonymat = abruti". Toutefois, Tor
n'a pas de problème avec le sites web car ces derniers permettent à leurs
utilisateurs de connecter en utilisant des systèmes d'authentification
situés à un autre niveau. Mais les serveurs IRC sont bien plus mauvais car
pour la majorité d'entre-eux, le code source est écrit de manière médiocre:
difficile à maintenir et plus difficile encore à modifier. De nombreux
réseaux IRC bloquent maintenant les connexions depuis Tor et nous sommes
quasiment acceptés seulement sur deux réseaux (OFTC et Freenode). Cet état
signifie qu'un grand nombre de personnes dans le monde affirment "je vous
l'avais bien dit" lorsqu'ils évoquent l'anonymat en ligne alors que c'est
simplement dû à un manque de technologie pour rendre le problème
gérable. Nous avons besoin d'un moyen pour les réseaux IRC de distinguer
quels sont les utilisateurs qui ont prouvé leur réputation et qui sont les
abrutis, de manière à bien séparer les deux. Il existe quels concepts de
recherche comme <a href="http://www.cs.dartmouth.edu/~nymble/">Nymble</a>
qui permet aux sites web de blacklister les utilisateurs sans avoir besoin
de connaître leur identité. Mais Nymble est conçu pour les interactions sur
le web. Nous avons besoin de féderer nos efforts sur le protocole IRC afin
de monter un projet semblable à Nymble (ou un plus simple pour démarrer en
tant que preuve de concept). Un des moyens d'y parvenir serait de construire
un proxy IRC sachant comment écouter les clients IRC et comment parler aux
serveurs IRC et bien sûr qui disposerait d'une couche permettant aux
utilisateurs de s'authentifier.
</li>

<li>
Make torsocks/dsocks work on OS X Priority: Medium Effort Level: Medium Skill Level: Medium 
Likely Mentors: ? <a
href="http://code.google.com/p/torsocks/">Torsocks</a> and <a
href="http://code.google.com/p/dsocks/">dsocks</a> are wrappers that will
run applications, intercept their outgoing network connections, and push
those connections through Tor. The goal is to handle applications that don't
support proxies (or don't supporting them well). To get it right, they need
to intercept many system calls. The syscalls you need to intercept on Linux
differ dramatically from those on BSD. So Torsocks works fine on Linux,
dsocks works ok on BSD (though it may be less maintained and thus might miss
more syscalls), and nothing works well on both. First, we should patch
dsocks to use Tor's mapaddress commands from the controller
interface, so we don't waste a whole round-trip inside Tor doing the resolve
before connecting. Second, we should make our torify script detect
which of torsocks or dsocks is installed, and call them appropriately. This
probably means unifying their interfaces, and might involve sharing code
between them or discarding one entirely.
</li>

<li>
Bring up new ideas! Don't like any of these? Look at the <a
href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development
roadmap</a> for more ideas, or just try out Tor, Vidalia, and Torbutton, and
find out what you think needs fixing. Some of the <a
href="<gittree>doc/spec/proposals">current proposals</a> might also be short
on developers.
</li>

</ol>

<a id="OtherCoding"></a>
<h2><a class="anchor" href="#OtherCoding">Autres idées de spécifications et de
code</a></h2>
<ol>
<li>Les serveurs de Tor ne fonctionnent pas parfaitement sur Windows
XP. SurWindows, Tor utilise l'appel système standard <tt>select()</tt>, qui
utilise l'espace non paginé dans le pool. Ce qui implique que les serveurs
de taille moyenne vont vider l'espace non paginé, <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">provocant
l'instabilité et le plantage du système</a>. Nous devrions probablement
utiliser des E/S recouvrables à la place. Une solution pourrait-être
d'apprendre à la <a
href="http://www.monkey.org/~provos/libevent/">libevent</a> comment utiliser
les E/S recouvrables à la place de select() sous Windows, et alors d'adapter
Tor à la nouvelle interface libevent. Christian King à <a
href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">bien
démarré</a> sur ce point l'été 2007.</li>

<li>Nous avons besoin maintenant de commencer l'élaboration de notre <a
href="<page documentation>#DesignDoc">conception de résistance au
blocage</a>. Ceci implique une refonte de la conception, une modification de
différents aspects de Tor, une adaptation de <a href="<page
vidalia/index>">Vidalia</a> pour qu'il supporte les nouvelles
fonctionnalités, et planifier le deploiement.</li>

<li>Nous avons besoin d'un ensemble d'outils flexibles de simulation pour
étudier de bout en bout les trafics de confirmation d'attaque. Beaucoups de
chercheurs ont conçu des simulateurs ad hoc pour confirmer leurs intuitions
comme quoi soit l'attaque marche vraiment bien ou que les défenses
fonctionnent. Pouvons nous construire un simulateur qui soit clairement
documenté et suffisament ouvert pour que tout le monde sache qu'il donne une
réponse raisonnable ? Ceci stimulera un grand nombre de nouvelles
recherches. Voyez l'entrée <a href="#Research">suivante</a> sur les
confirmations d'attaque pour les détails sur le coté recherche de cette
tâche &mdash; qui sait, quand ceci sera fait peut-être pourrez aider en
écrivant un rapport ou deux.</li>

<li>Tor 0.1.1.x inclut le support d'accélérateurs matériels de chiffrage via
OpenSSL. Cependant, personne ne l'a jamais testé. Est-ce que quelqu'un
voudrait se procurer une carte et nous dire ce qu'il en est ?</li>

<li>Faire une analyse de sureté de Tor avec <a
href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer
s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons
faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir
le jour !</li>

<li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est
simple et efficace, mais cela implique que toutes les unités (cellules) d'un
lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie
que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons
dressé une <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
liste de raisons pour lesquelles nous n'avons pas bifurqué vers le transport
par UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous
avons aussi proposé <a href="<gitblob>tor/doc/100-tor-spec-udp.txt">une
spécification pour Tor et UDP</a> &mdash; lisez-la et faites-nous part de
vos remarques et critiques, s'il-vous-plaît.</li>

<li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les
serveurs de sorties et les adresses finales. Si IPV6 vous tient à cœur,
partir de là est sans doute un premier pas.</li>

<li>Nous avons besoin de générer les diagrammes du site web (par exemple les
images de "Comment fonctionne Tor ?" sur <a href="<page overview>">la page
d'aperçu</a> à partir d'une source de manière à pouvoir les traduire comme
du texte UTF-8 plutôt que de les éditer à la main avec Gimp. Nous voudrions
intégrer ce processus dans un fichier wml pour faciliter les traductions et
regénérer les images en plusieurs langues lorsque nous construisons le site
web.</li>

<li>Comment pouvons-nous maintenir, améliorer et documenter plus facilement les
différents systèmes LiveCD/USB ? <a href="http://amnesia.boum.org/">Le
LiveCD/USB amnesia</a>et <a
href="http://anonymityanywhere.com/incognito/">le LiveCD Incognito</a> sont
quelques exemples.
</li>

<li>
Another anti-censorship project is to try to make Tor more
scanning-resistant. Right now, an adversary can identify <a
href="<gitblob>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="<gitblob>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. To
start, check out Shane Pope's <a
href="http://dl.dropbox.com/u/37735/index.html">thesis and prototype</a>.
</li>

</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Recherche</a></h2>
<ol>
<li>"L'attaque par empreinte de sites": faire une liste de quelques centaines de
sites populaires, en télécharger les pages, et faire des "signatures" pour
chaque site. Ensuite, observer le trafic d'un client Tor. L'analyse de ses
réceptions de données donne rapidement une idée des sites qu'il
visite. Premièrement, quelle est l'efficacité de cette attaque sur le code
actuellement utilisé dans Tor ? Ensuite, tester les défenses possibles : par
exemple, changer la taille des cellules de Tor de 512 octets à 1024,
utiliser des techniques de remplissage comme <a
href="http://freehaven.net/anonbib/#timing-fc2004">le lâcher défensif</a>,
ou ajouter des délais de trafic. Quel impact ces stratégies de défense
ont-elles, et, dans les cas où elles sont efficaces en défense, quel impact
ont-elles en terme de perte d'utilisabilité de Tor (à quantifier) ?</li>
<li>"L'attaque par corrélation des trafics aux extrémités": par l'observation
des trafics de Alice et Bob, il est possible de <a
href="http://freehaven.net/anonbib/#danezis:pet2004">comparer les signatures
des trafics et d'en déduire qu'il s'agit du même flux</a>. Jusqu'ici, Tor
considère ce type d'attaque comme intrinsèque et donc inévitable. Tout
d'abord, est-ce réellement vrai ? Quelle quantité de trafic - et avec quelle
distribution - est-elle nécessaire pour que l'adversaire soit certain
d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un
trafic faible) pour ralentir cette attaque ? Est-ce que certains types de
remplissage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>
<li>On peut relier la question qui vient: Est-ce-que le fait de faire tourner un
relais/passerelle offre une protection supplémentaire contre ces attaques
basées sur les timings ? Un attaquant externe qui ne peut voir l'intérieur
des flux TLS peut-il reconnaître de manière fiable les flux individuels ?
Est-ce-que le volume de trafic transféré dégrade cette possibilité ? Que
faire si le relais du client retarde délibérément le trafic montant pour
former une queue pouvant être utilisée pour mimer les timings du trafic
descendant du client pour le faire passer pour du trafic egalement relayé ?
Cette queue identique pourrait être également utilisée pour masquer les
temps du trafic montant du client à l'aide des techniques dites <a
href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptative
padding</a> sans avoir besoin de trafic supplémentaire. Est-ce-qu'un tel
entrelacement du trafic montant du client osbcurcit les temps pour des
attaquants externes ? Les stratégies doivent-elles être ajustées pour les
liens symétriques ? Ou bien est-ce plus évident que pour les liens
symétriques ?</li>
<li><a href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">L'attaque
d'Oakland 05</a> par Repeat Murdoch et Danezi sur le réseau Tor
acutel. Essayez de comprendre pourquoi elle fonctionne bien sur certains
noeuds et pas sur les autres. (Ma théorie est que les noeuds rapides avec
davantage de capacité résistent mieux à l'attaque). On peut expérimenter
cette attaque avec la gestion des options RelayBandwithRate et
RelayBandwithBurst pour faire tourner un relais utilisé comme client tout en
relayant le traffic de l'attaquant: si nous limitons fortement le
RelayBandwithRate, est-ce-que l'attaque est plus difficile ? Quel est le
ratio correct de RelayBandwithRate par rapport à la capacité ? D'ailleurs,
est-ce-que le ratio joue un rôle dans cette attaque ? Pendant qu'on y est,
est-ce-qu'un plus grand nombre de relais candidats augmente le taux de faux
positifs ou une autre complexité dans l'attaque ? (Le réseau Tor est
maintenant deux fois plus étendu qu'il ne l'était au moment de la rédaction
de leur papier). Prenez également le temps de consulter le document <a
href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the
Queue</a>.</li>
<li>L'attaque "routing zones": la majorité de ce qui est écrit sur Tor modélise
le chemin réseau entre Alice et son noeud d'entrée (et entre Bob et le noeud
de sortie) comme un simple lien sur un graphe. En pratique, le chemin
traverse de nombreux systèmes automomes (SA) et <a
href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas rare que
le même SA apparaissent à la fois sur le chemin d'entrée comme sur le chemin
de retoure</a>. Malheureusement, pour être sûr de prédire si un quartet
Alice, noeud d'entrée, noeud de sortie, Bob sera dangereux, il faut
télécharger entièrement une zone de routage Internet et effectuer de
couteuses opérations dessus. Existe-t-il des approximations pratiques comme
éviter les adresse IP situées dans le même réseau /8 ?</li>
<li>D'autres points de recherche se pose la question de savoir, d'un point de
vue diversité géographique, s'il est mieux d'avoir un circuit efficace ou de
choisir un circuit au hasard. Consultez <a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">les
travaux de Stephen Rollyson</a> qui expliquent comment éviter les choix
particulièrement inefficaces sans "trop" compromettre l'anonymat. Cet angle
d'attaque a besoin d'être creusé et travaillé mais il a l'air très
prometteur.</li>
<li>Tor ne fonctionne pas bien lorsque les relais disposent d'une bande passante
asymétrique (ex: câble ou ADSL). Etant donné que Tor sépare les connexions
entre chaque hop, si les octets entrants arrivent trop vite et que du coup,
les octets sortants arrivent plus lentement, les mécanismes de push-back de
TCP ne retournent pas cette information aux flux entrants. Peut-être que
Tor devrait détecter les rejets de paquets sortants et réguler les flux
entrants de lui-même ? J'imagine un schéma d'ouverture/fermeture où l'on
récupère un taux de transfert limite donné qu'on incrémente lentement
jusqu'à perdre des paquets, moment où l'on diminuerait le taux, etc... Nous
avons besoin de quelqu'un disposant de sérieuses compétences réseau pour
simuler cela et apporter son aide pour la mise en place de ces
fonctionnalités. Nous avons besoin de comprendre l'importance de la
dégradation des performances et de l'utiliser comme élément moteur en vue de
reconsidérer le transport par UDP.</li>
<li>Le contrôle de la congestion est un sujet proche. Est-ce-que notre
spécification permet de gérer les fortes charges ? Peut-être devrions-nous
expérimenter des fenêtres de tailles variables plutôt que des fenêtres fixes
? Cela semble prometteur dans <a
href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">cette
expérimentation autour de ssh</a>. Nous avons besoin de mesurer, de corriger
et peut-être de refondre quelquechose si les résultats s'avèrent bons.</li>
<li>Nos objectifs de résistance à la censure incluent l'impossibilité pour un
attaquant qui observe le trafic Tor de <a
href="<gitblob>doc/design-paper/blocking.html#sec:network-fingerprint">le
distinguer d'un trafic SSL normal</a>. Néanmoins, nous ne pouvons pas
recréer une stéganographie parfaire tout en restant utilisable mais, dans un
premier temps, nous aimerions pouvoir bloquer toute attaque qui pourrait
réussir en observant quelques paquets seulement. Une des attaques qu'il nous
reste à examiner est basée sur le fait que les paquets Tor font 512 octets
et que par conséquence, les paquets du trafic réseau sont également des
multiples de 512 octets. En quoi le fait de modifier les enregistrements
TLS et leur en-tête pourrait brouiller ce trafic ? Différentes stratégies de
fermeture de tampon dans Tor peuvent-elles avoir un impact sur ce sujet ?
Est-ce-qu'un peu de remplissage ferait l'affaire ou bien est-ce-une attaque
que nous pouvons accepter ?</li>
<li>Les circuits Tor sont construit pas à pas. Ainsi, il est théoriquement
possible de faire sortir des flux à partir du second pas, d'autres à partir
du troisième et ainsi de suite. Cela semble une alternative séduisante car
elle permet de passer outre la limite en sortie de chaque relais. Mais si
nous voulons que chaque flux soit sécurisé, le chemin "le plus court" doit
obligatoirement avoir au moins 3 pas selon notre logique actuelle. Nous
devons examiner cette alternative sur l'aspect performance en balance de la
sécurité</li>
<li>Il n'est pas si difficile de faire du dénis de service sur les relais Tor ou
les autorités d'annuaire. Les clients forment-ils la meilleure réponse ?
Quelles sont les autres approches possibles ? Il serait bien qu'elles soient
compatibles avec le protocole Tor actuel.</li>
<li>Les programmes tels que <a href="<page torbutton/index>">Torbutton</a> ont
pour objectif de masquer le champ UserAgent de votre navigateur web en le
replaçant par une réponse uniforme pour tous les utilisateurs Tor. Ainsi, un
attaquant ne peut rien déduire de vous en regardant cet en-tête. Il essaye
de récupérer une chaîne communément utilisée par les utilisateurs
non-Tor. Première question: comment révélons-nous l'utilisation de Tor en
mettant à jour régulièrement ce champ ? Si nous le mettons à jour trop
souvent, nous supprimons nous-même de l'anonymat. Si nous ne le mettons pas
à jour souvent alors tous les utilisateurs de Tor se dévoileront car leur
navigateur web indiquera qu'ils utilisent tous une assez vieille version de
Firefox. La réponse à la question dépend certainement des versions de
Firefox utilisés dans la nature. Deuxième question: régulièrement, les gens
nous demande de modifier le champ UserAgent selon un cycle de N chaînes de
caractères différentes plutôt que de mettre toujours la même. Est-ce-que
cette approche est vraiment utile, malfaisante ou neutre ? A prendre en
considération: les cookies et le fait de reconnaître les utilisateurs de
Torbutton par leur rotation de UserAgents; les sites webs malicieux qui
n'attaque qu'un seul type de navigateur web; la réponse à la question un
impact la réponse à la question deux.
</li>
<li>Actuellement, les clients Tor réutilisent un circuit donné pendant les dix
minutes qui suivent sa première utilisation. L'objectif est d'éviter de
surcharger le réseau avec des opérations de circuits étendus et également
pour éviter que les clients utilisent le même circuit pendant trop longtemps
ce qui permettrait au noeud de sortie de les profiler. Hélas, dix minutes
est une période de temps sans doute trop longue, spécialement si des
connexions vers des protocoles différents (ex messagerie instantanée et
navigation internet) utilisent le même circuit. Si nous continuons à fixer
le nombre global de la taille des circuits que le réseau a besoin d'établir,
existe-t-il de meilleurs et/ou de plus sûrs moyens pour les clients
d'affecter des flux aux circuits ou bien pour que les clients construisent
des circuits préemptifs ? Peut-être que cet élément de recherche doit
commencer par récupérer des traces sur les connexions typiques que les
clients initient afin de disposer de données réalistes ?
</li>
<li>De combien de passerelles avez-vous besoin pour maintenir un bon niveau
d'accessibilité ? Nous devrions mesurer le contenu de nos passerelles. Si ce
contenu est bien fourni, existe-t-il des moyens de faire en sorte que les
utilisateurs de passerelles restent connectés plus longtemps ?
</li>
</ol>

<a href="<page contact>">Contactez-nous</a> si vous avez avancé sur ces
points !

</div>

#include <foot.wmi>

tor-webwml.git

updated translations for the website