fr/volunteer.wml (506f0d51b) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 15882
# Last-Translator: mfr(ä]misericordia.be, fredzupy@gmail.com

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

<h2>Un certain nombre de choses que vous pouvez faire:</h2>
<ol>
<li>Pensez à <a href="<page docs/tor-doc-relay>">héberger 
un relais</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>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Supporting Applications</a></h2>
<ol>
<li>Nous avons besoin de méthodes plus efficaces d'interception des requêtes DNS, pour qu'elles ne laissent pas transparaitre d'informations à un observateur local pendant que nous tentons d'être anonymes. (Ce qui 
arrive lorsque l'application fait sa résolution DNS avant de passer par 
le proxy SOCKS.)</li>
<li>Éléments tsocks/dsocks :
<ul>
<li>Nous avons besoin <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">d'appliquer 
tout nos patchs à tsocks</a> et d'en maintenir une nouvelle branche. Nous l'hébergerons si 
vous le souhaitez.</li>
<li>Nous devrions patcher le programme « dsocks » développé par Dug Song pour utiliser les commandes 
mapaddress de Tor depuis l'interface de contrôle, de manière à ne pas faire 
inutilement un aller-retour complet dans Tor pour faire la résolution avant la 
connexion.</li>
<li>Notre script torify doit détecter lequel de tsocks ou 
dsocks est installé pour l'appeler correctement. Cela nécessite certainement 
d'unifier leurs interfaces, et peut amener à faire un mix des deux 
voire à en éliminer un des deux.</li>
</ul>
</li>
<li>Les gens qui hébergent des serveurs nous signalent qu'ils aimeraient avoir une passante allouée 
durant une partie de la journée, et une autre bande passante à d'autre moment de la journée.
Plutôt que de coder ceci dans Tor, nous aimerions utiliser un petit 
script qui communique avec <a href="<page gui/index>">l'interface de contrôle de Tor</a>, 
et ferait un setconf pour changer la valeur de la bande passante.
Il en existe dejà un pour Unix et Mac (qui utilise bash et cron),
mais les utilisateurs de Windows ont encore besoin d'une solution.
</li>
<li>Tor peut <a 
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">quitter 
le réseau Tor par un noeud de sortie particulier</a>, mais il serait pratique 
de n'avoir qu'à spécifier un pays, et que le serveur de sortie soit choisi automatiquement. Le 
meilleur moyen est probablement de récupérer le répertoire de Blossom, et d'utiliser en local un client 
qui récupère ce répertoire de manière sûre (via Tor et en vérifiant sa 
signature), lise les noms des machines <tt>.country.blossom</tt> et se charge
 ensuite de choisir le serveur.</li>
<li>En parlant de géolocalisation, quelqu'un devrait faire une carte de
 la Terre indiquant chaque serveur Tor par un point. La cerise sur le gâteau 
	serait la mise à jour dynamique de la carte à mesure que le réseau Tor évolue
 et grandit. Malheureusement, les moyens aisés de faire cela passent par l'envoi
 de toutes les données à Google pour qu'il trace cette carte pour vous.
 Dans quelle mesure cela jouerait-il sur la confidentialité, et par ailleurs, 
	existe-t-il des solutions de remplacement valables ?</li>
</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
<ol>
<li>Aidez Matt Edman à documenter et à écrire des tutoriaux pour son 
contrôleur Tor,
<a href="http://vidalia-project.net/">Vidalia</a>.</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 besoin d'une meilleure documentation traitant de l'interception dynamique de 
connexions et de leur envoi à travers Tor. tsocks (Linux), dsocks (BSD), 
et freecap (Windows) semblent être de bons candidats, et utiliserait au mieux
notre nouvelle fonctionnalité Transport.</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>
<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>
</ol>

<a id="Coding"></a>
<a id="Summer"></a>
<a id="Projects"></a>
<h2><a class="anchor" href="#Projects">Bons Projets de codage</a></h2>
Vous pouvez trouver que certains de ces projets sont de bonnes idées pour le <a href="<page
 	 gsoc>">Google Summer of Code 2008</a>. Nous avons marqué chaque idée en fonction de l'utilité qu'il apporte à l'ensemble du projet Tor (priorité), de la quantité de travail que nous estimons (niveau d'effort), du l'expérience que vous devriez avoir pour commencer (niveau de qualification), et qui de <a href="<page
 	 people>#Core">nos principaux développeurs</a> pourrait être de bons tuteurs. Il ya plein d'autres bonnes idées pour travailler - voir par exemple la liste des <a
 	 href="<svnsandbox>doc/spec/proposals/">propositions actuelles</a>, ou tout simplement vos propres idées.
<ol>

<li>
Amélioration du scanneur des sorties Tor
 
Priorité : élevée
 
Niveau d'effort : élevé
 
Niveau de compétence: élevé
 
Mentors supposés : Mike
 
Demandes au premier Avril 00:00 UTC: 5

Le scanner des nœuds de sortie Tor 'SoaT', partie du <a
href="<svnsandbox>torflow/">projet Torflow</a>, est
pour l'instant écrit dans un perl plutôt bancal et s'appuie sur des MD5sums de
documents entiers dans le but de savoir si un nœud de sortie modifie les contenus. 
The problem with this is threefold: 1) Perl sucks at life.
2) The scanner can't verify pages that are dynamic, and attackers can
focus malicious content injection on only those dynamic pages. 3)
Pages change after a while (or based on GeoIP) and begin generating
false positives.
 
Ideally, soat.pl would be reimplemented in a sane language with a
robust html parser library (since the rest of Torflow is in Python
that would be nice, but it is not required), and calculate signatures only for
tags and content likely to be targeted by a malicious attacker (script
tags, object links, images, css). It should also be robust in the face of
changes to content outside of Tor, and ultimately even GeoIP localized
content.
 
This scanner would likely be run by the Directory Authorities and
report its results to the control port via the AuthDirBadExit config
setting.
 
</li>

<li>
Amélioration du scanner de noeux Tor
 
Priorité: élevé
 
Niveau d'effort : moyen à élevé
 
Niveau de difficulté : moyen à élevé
 
Mentors supposés : Mike
 
Demandes au premier Avril 00:00 UTC: 1
 
Similar to the 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://www.torproject.org/svn/torctl/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
 
Priorité: élevé
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen
 
Mentors supposés : Roger, Nick, Mike
 
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>
Tor path selection improvements
 
Priorité: élevé
 
Niveau d'effort : faible à moyen
 
Niveau de difficulté : élevé
 
Mentors supposés : Roger, Nick, Mike
 
Demandes au premier Avril 00:00 UTC: 3
 
Some simple improvements can be made to Tor's path selection to vastly
improve Tor speed. For instance, some of the (unofficial) <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
Performance Recommendations</a> on the wiki are to increase the number of
guards and decrease the CircuitBuildTimeout. Ideally, the client would
<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn
these values by gathering statistics on circuit construction
time</a> (and/or using values gained from Torflow), and set the timeouts
low enough such that some high percentile (75%, 90%, 1-stddev?) of
circuits succeed, yet extremely slow nodes are avoided. This would
involve some statistics gathering+basic research, and some changes to
Tor path selection code.
 
In addition, to improve path security, some elements from the <a
href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
Hop Paths proposal</a> could be done as part of this (since it will
likely touch the same code anyways), regardless of the adoption of
that proposal. In particular, clients probably should avoid guards that
seem to fail an excessive percentage of their circuits through them,
and non-firewalled clients should issue a warning if they are only able
to connect to a limited set of guard nodes. See also
<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this
or-dev post</a>.
</li>

<li>
Translation Wiki
 
Priorité: élevé
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen
 
Mentors supposés : Jacob
 
Nous avons besoin d'un moyen d'éditer et traduire le éléments du site web. 
Actuellement le site web est fait d'un lot de <a href="<svnwebsite>en/">fichiers wml
</a>, et <a href="<page translation>">les traducteurs</a> vont chercher ces
fichiers wml, les traduisent dans un éditeur, et soit nous envoient la traduction
ou utilisent svn pour valider leur traduction.
L'actuel «coût» de la publication des modifications apportées au site Web 
est assez élevé, même pour l'anglais.
Pour changer un seul mot ou n'importe quel type de changement mineur, 
la page peut ne jamais être corrigée ou traduite. Il serait
bien d'avoir un wiki qui a été spécialement conçu pour la traduction
et qui pourrait traquer à partir de la version officielle (anglaise) si
une nouvelle traduction est nécessaire, comme notre actuelle 
<a href="<page translation-status>">page d'état de traduction</a>.
Cela semble être le travail d'un intégrateur wiki
ou un auteur de logiciel wiki. Certes, la personne devra
être intéressées par les langues et la traduction. Il devrait au moins
à minima être familier avec ce que Tor est mais n'aurait pas d'interaction
avec le logiciel, seulement la documentation sur le site.
</li>

<li>
Améliorer la mise en paquet Debian/Ubuntu pour Tor+Vidalia
 
Priorité: élevé
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen
 
Mentors supposés : Peter, Matt
 
Demandes au premier Avril 00:00 UTC: 1
 
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 student 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>
Accroitre la capacité de Tor à résister à la censure.
 
Priorité: élevé
 
Niveau d'effort : élevé
 
Niveau de difficulté : élevé
 
Mentors supposés : Nick
 
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
 
Priorité: moyen
 
Niveau d'effort : élevé
 
Niveau de difficulté : élevé
 
Mentors supposés : Matt, Jacob
 
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 student undertaking this project should have good C++ development
experience. Previous experience with Qt is helpful, but not required. The
student 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 for others to review and discuss
with the student prior to implementation.
</li>

<li>
Une carte du réseau dans Vidalia, améliorée et plus pratique
 
Priorité: moyen
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen à élevé
 
Mentors supposés : Matt
 
L'une des composantes existantes de Vidalia est une carte du réseau qui montre 
la localisation géographique approximative du relais dans le réseau Tor et
trace le chemin du trafic utilisateur tel qu'il est tunnellisé à travers le
réseau Tor. La carte n'est pour l'instant pas très interactive et est plutôt 
pauvre graphiquement. À la place, nous aimerions profiter du widget Marble de KDE
qui nous apporterait une carte de meilleur qualité et étendrait l'interactivité,
en permettant à l'utilisateur de cliquer sur des relais ou circuit pour 
obtenir des informations supplémentaires. Il serait aussi souhaitable de permettre
à l'utilisateur de cliquer sur un relais particulier ou un pays contenant un ou
plusieurs relais Tor de sortie et dire « je souhaite que mes connexions à truc.com sortent
par là ».
 
Ce projet nécessite d'abord que l'étudiant soit à l'aise avec Vidalia
et l'API de l'objet Marble. L'étudiant devra alors intégrer l'objet dans 
Vidalia et configurer Marble pour s'indapter dans notre application,
comme faire des circuits cliquable, stocker des données cartes dans le répertoire
de donnée de Vidalia, et adapter quelques une des boites de dialogue.
 
L'étudiant prenant en charge ce projet devra avoir une bonne expérience en 
développement C++. Une expérience avec Qt et CMake est utile, mais non
requise.
</li>

<li>
Tor Controller Status Event Interface
 
Priorité: moyen
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen
 
Mentors supposés : Matt, Roger
 
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 the student is free to
suggest another approach.
 
A student 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>
Améliorations de notre testeur de configuration active de navigateur -
<a href="https://check.torproject.org/">https://check.torproject.org/</a>
 
Priorité: moyen
 
Niveau d'effort : faible
 
Niveau de difficulté : faible à moyen
 
Mentors supposés : Jacob, Steven
 
Demandes au premier Avril 00:00 UTC: 1
 
Actuellement, nous avons une page Web fonctionnelle pour détecter si Tor fonctionne. Il 	 
ya des manques à quelques endroits. Il nécessite quelques améliorations s'agissant
des langues par défaut et des fonctionnalités. Il répond pour l'instant qu'en
Anglais. De plus, c'est un hack d'un script perl qui n'aurait
jamais dû voir le jour. Il devrait être réécrit en python
avec un support multi-langues. Il utilise actuellement <a
href="http://exitlist.torproject.org/">la liste de sortie DNS 
Tor</a> et devrait continuer à faire de même dans le futur. Il peut y avoir de temps en temps
des faux positifs et ceci devrait être découvert, documenté et corrigé lorsque 
c'est possible. Toute personne travaillant sur ce projet devrait être interessée par 
DNS, les bases de perl ou de préférence python et auront un peu à interagir avec
Tor pour tester leur 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>
Amélioration de notre liste de sortie DNS -
<a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
 
Priorité: moyen
 
Niveau d'effort : faible
 
Niveau de difficulté : faible
 
Mentors supposés : Jacob, Tup
 
Le <a href="http://p56soo2ibjkx23xo.onion/">logiciel exitlist</a> est écrit par notre fabuleux contributeur anonyme Tup. C'est un serveur DNS écrit en Haskell qui supporte 
une partie de notre <a
href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">document
de conception exitlist</a>. Actuellement, c'est fonctionnel et utilisé par
check.torproject.org et d'autres utilisateurs. Les problèmes qui sont en suspens
sont pour la plupart esthétiques. Ce service merveilleux pourrait bien mieux utiliser
le site web en utilisant la charte graphique Tor. It serait mieux servi avec une meilleure
documentation pour les services communs qui utilisent une RBL. Il pourrait y'avoir d'avantage
de publicité. La personne travaillant sur ce projet devrait être interessée par les DNS,
la configuration basique de RBL pour des services populaires, et écrire de la documentation.
La personne devrait avoir un peu d'interaction avec Tor &mdash; tester leur propre
documentation au minimum. De plus, ce serait utile
qu'il soit interessé par Haskell et souhaite implémenter d'avantages des suggestions du 
torel-design.txt.
</li>

<li>
Tester l'intégration de Tor avec les navigateurs pour nos utilisateurs finaux
 
Priorité: moyen
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen
 
Mentors supposés : Jacob, Mike, Greg
 
Demandes au premier Avril 00:00 UTC: 1
 
Le Projet Tor manque actuellement d'un ensemble de tests efficaces pour s'assurer que 
l'utilisateur a proprement configuré son navigateur. Il devrait tester la plupart
des problèmes connus autant que possible. Il devrait essayer de découvrir 
l'utilisateur par tous les moyens possibles. Deux pages web qui tracent ces
type de problèmes sont fournies par Greg et HD Moore. Greg conserve une bonne <a
href="http://pseudo-flaw.net/tor/torbutton/">liste de problèmes avec 
leur code de preuve de concept, les bugs, etc</a>. HD Moore fournit
le <a href="http://metasploit.com/research/misc/decloak/">site
decloak</a>. Une personne interessée par l'attaque de Tor peut commencer
par collecter autant de solutions fonctionnelles et de méthodes connues pour révèler
un utilisateur Tor. La personne devrait être familière des écueils courants mais pourrait
avoir d'autres méthodes en tête pour implémenter des outils de désanonymisation. Le
site web devrait s'assurer d'informer l'utilisateur de ce que sont ses problèmes. Il
devra l'aider à les résoudre ou les renvoyer directement sur le bon canal de 
soutien. La personne devra être très familière dans l'utilisation de Tor et comment
palier aux fuites de Tor.
</li>

<li>
Amélioration de l'intégration Libevent et Tor
 
Priorité: moyen
 
Niveau d'effort : élevé
 
Niveau de difficulté : moyen à élevé
 
Mentors supposés : Nick
 
Tor devrait faire un meilleur usage des récentes options de Niels Provos dans
la bibliothèque <a href="http://monkey.org/~provos/libevent/">Libevent</a>.
Tor utilise dejà Libevent apour ces appels IO bas niveau, et peut aussi utiliser Libevent 
plus pour l'HTTP et les tampons de socket.
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. Et nous aurons à améliorer le code
de libevent autant que nécessaire ; particulièrement, pour 
ajouter un bon support openssl au dessus de la couche d'abstraction 
des tampons de libevent.
Also tricky will be adding rate-limiting to Libevent.
</li>

<li>
Accroitre les performances de Tor!
 
Priorité: moyen
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen à élevé
 
Mentors supposés : Nick, Roger, Mike
 
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. A student 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élioration de nos tests unitaires
 
Priorité: moyen
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen
 
Mentors supposés : Nick
 
Tor doit être bien plus testé. C'est un effort multi-partie. Pour commencer,
Notre unité de couverture de test devrait augmenter substantiellement, spécialement dans
les zones en dehors des fonctions utilitaires. Ceci devra conduire à une refonte
significative des certaines parties de Tor, dans le but de dissocier autant de logique
que possible de la globalité.
 
De plus, nous avons besoin d'automatiser nos tests de performance pour toutes les plateformes.
Nous avons buildbot (excepté sous Windows &mdash; comme dit au dessus) pour automatiser
notre intégration régulièrement et tester la compilation déjà,
mais nous avons besoin d'avoir notre test de simulation de réseau (comme dans torflow)
mis à jour pour des versions plus récentes de Tor, et faites pour lancer un test
de réseau à la fois sur une seule machine, et sur plusieurs, afin que nous puissions tester
les changements de performance sur des machins de roles différents automatiquement. 
</li>

<li>
Aider à ranimer une implémentation indépendante de Tor
 
Priorité: moyen
 
Niveau d'effort : élevé
 
Niveau de difficulté : moyen à élevé
 
Mentors supposés : Karsten, Nick
 
Applications as of 1 Apr 00::00 UTC: 4
 
Réanimer l'une des approches d'implématation d'un client Tor en Java,
p.e. le <a href="http://onioncoffee.sourceforge.net/">Projet
OnionCoffee</a>, et le faire tourner sur <a
href="http://code.google.com/android/">Android</a>. La première étape
pourrait être de porter le code existant et l'exécuter dans un environnement
Android. Ensuite, le code pourrait être mis à jour pour supporter les nouvelles
version de protocole comme la <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
des protocole d'annuaire</a>. Ensuite, le support pour les requêtes ou même
apporter des services cachés serait sympa, mais non requis. L'étudiant
devrait être capable de comprendre et écrire du code Java, comprenant
une API de cryptographie Java. Capable de lire du code C serait utile,
également. L'étudiant devrait être prêt à lire la documentation existante,
implémenter du code de celle ci, et, si nécessaire, refaire la documentation
si des éléments ne sont pas documentés. Ce projet est principalement du codage et
à un degré moindre, de la conception.
</li>

<li>
Automatic system tests and automatically starting private Tor networks
 
Priorité: moyen
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen
 
Mentors supposés : Karsten, Nick, Roger
 
Demandes au premier Avril 00:00 UTC: 2
 
Écrire un outil qui lance un système de tests automatique en plus
des test unitaires existants. Le simulateur Tor en Java <a
href="https://svn.torproject.org/svn/puppetor/trunk/">PuppeTor</a>
devrait être un bon départ pour commencer un réseau privé Tor, l'utiliser 
quelque temps, et vérifier qu'au moins quelques parties fonctionnent. Ce
projet nécessite de concevoir un plan pour effectuer les tests système
du réseau privé Tor, avant de commencer à coder. Les tests typiques
vont de la simple requête dans le réseau privé à la
manipulation des messages échangés et voir si les nœuds peuvent 
correctement prendre en compte les messages corrompus.
 
L'étudiant devrait pouvoir obtenir une bonne comprehension de comment Tor 
fonctionne et quels problèmes ou bugs peuvent survenir pour concevoir de bons
bancs de tests. Comprendre le code Tor et la documentation existante est
vital. Si PuppeTor est utilisé, l'étudiant devrait aussi être en mesure de comprendre
et éventuellement étendre une application Java existante. Ce projet est en partie
de la conception et en partie du codage.
</li>

<li>
Donner vie à moniTor
 
Priorité: moyen
 
Niveau d'effort : moyen
 
Niveau de difficulté : faible à moyen
 
Mentors supposés : Karsten, Jacob
 
Applications as of 1 Apr 00::00 UTC: 2
 
Implémenter un outil <a href="http://www.ss64.com/bash/top.html">comme top</a>
d'administration pour les relais Tor. Le but de cet outil serait de
superviser un relais Tor local via son port de control et inclure des informations
système utiles de la machine. Lorsque l'outil tourne, il 
devrait dynamiquement se mettre à jour comme top le fait pour les processus Linux.
<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">Ce
post sur or-dev</a> devrait être une bonne première base.
 
L'étudiant devra être familier ou prêt à apprendre l'administration 
d'un relais Tor et sa configuration à travers son port de contrôle.
Du fait qu'un prototype existe en Python quelques connaissances en Python
 serait intéressantes. Ce projet porte sur l'identification des nécessités 
	pour un tel outil et sur la conception d'une interface ;
et d'un autre coté nécessite beaucoup de codage.
</li>

<li>
Torbutton improvements
 
Priorité: moyen
 
Niveau d'effort : élevé
 
Niveau de difficulté : élevé
 
Mentors supposés : Mike
 
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
 
Priorité: moyen
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen à élevé
 
Mentors supposés : Andrew, Steven, Roger
 
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
 
Priorité: moyen
 
Niveau d'effort : faible
 
Niveau de difficulté : faible
 
Mentors supposés : Andrew
 
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. See the
"Translation Wiki" idea above.
</li>

<li>
Improve the LiveCD offerings for the Tor community
 
Priorité: faible
 
Niveau d'effort : faible
 
Niveau de difficulté : moyen à élevé
 
Mentors supposés : Anonym, Jacob, Roger
 
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
 
Priorité: moyen
 
Niveau d'effort : moyen à élevé
 
Niveau de difficulté : moyen à élevé
 
Mentors supposés : Goodell
 
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
 
Priorité: faible
 
Niveau d'effort : moyen
 
Niveau de difficulté : moyen
 
Mentors supposés : Goodell
 
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>
Proposer de nouvelles idées !
 
Don't like any of these? Look at the <a
href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
roadmap</a> for more ideas.
</li>

</ol>

<h2><a class="anchor" href="#Coding">Conception et Code</a></h2>
<ol>
<li>Les serveurs de Tor ne fonctionnent pas parfaitement sur Windows XP. Sur
Windows, 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="http://vidalia-project.net/">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="<svnsandbox>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>
</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>A related question is: Does running a relay/bridge provide additional
protection against these timing attacks? Can an external adversary that can't
see inside TLS links still recognize individual streams reliably?
Does the amount of traffic carried degrade this ability any? What if the
client-relay deliberately delayed upstream relayed traffic to create a queue
that could be used to mimic timings of client downstream traffic to make it
look like it was also relayed? This same queue could also be used for masking
timings in client upstream traffic with the techniques from <a
href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptive padding</a>,
but without the need for additional traffic. Would such an interleaving of
client upstream traffic obscure timings for external adversaries? Would the
strategies need to be adjusted for asymmetric links? For example, on
asymmetric links, is it actually possible to differentiate client traffic from
natural bursts due to their asymmetric capacity? Or is it easier than
symmetric links for some other reason?</li>
<li>Repeat Murdoch and Danezis's <a
href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">attack from
Oakland 05</a> on the current Tor network. See if you can learn why it
works well on some nodes and not well on others. (My theory is that the
fast nodes with spare capacity resist the attack better.) If that's true,
then experiment with the RelayBandwidthRate and RelayBandwidthBurst
options to run a relay that is used as a client while relaying the
attacker's traffic: as we crank down the RelayBandwidthRate, does the
attack get harder? What's the right ratio of RelayBandwidthRate to
actually capacity? Or is it a ratio at all? While we're at it, does a
much larger set of candidate relays increase the false positive rate
or other complexity for the attack? (The Tor network is now almost two
orders of magnitude larger than it was when they wrote their paper.) Be
sure to read <a href="http://freehaven.net/anonbib/#clog-the-queue">Don't
Clog the Queue</a> too.</li>
<li>"L'attaque par zones de routage" : la littérature spécialisée considère 
le plus souvent que le chemin réseau entre Alice et son noeud d'entrée 
(et entre le noeud de sortie et Bob) comme un lien unique dans un graphe. 
En pratique, cependant, le chemin passe par de nombreux systèmes autonomes
 (Autonomous Systems : ASes), et <a
href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas inhabituel 
de retrouver le même AS sur les chemins d'entrée et de sortie</a>.
Malheureusement, pour prévoir précisément si le chemin "Alice, entrée, 
sortie, Bob" sera dangereux, nous devrions télécharger une zone de routage 
internet complète et faire dessus des calculs lourds. Est-ce qu'il existe 
des approximations utilisables, comme par exemple d'ignorer les adresses IP d'un réseau /8 ?</li>
<li>D'autres questions de recherche concernant la diversité géographique considèrent 
la différence entre choisir un circuit efficace et en choisir un aléatoire.
Lisez l' <a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">argumentation
</a> de Stephen Rollyson sur comment éviter les nœuds lents sans trop impacter
l'anonymat. Cet axe de raisonnement nécessite davantage de travail et de 
réflexion, mais semble très prometteur.</li>
<li>Tor ne fonctionne pas très bien lorsque les serveurs ont des bandes passantes 
asymétriques (par exemple câble ou DSL). Comme Tor a des connexions TCP séparées entre 
chaque saut, si les octets arrivent correctement mais que les octets sortants 
sont bloqués sur place, les mécanismes de refoulement de TCP 
ne retransmettent pas vraiment cette information aux flux entrants.
Peut-être Tor devrait-il détecter s'il perd beaucoup de paquets sortants, 
et limiter la vitesse du flux entrant pour réguler cela lui-même ? Je peux concevoir 
un schéma de type augmentation-descente dans lequel on choisit un débit "sûr", 
que l'on augmente jusqu'à perdre des paquets, puis qui redescend, puis qui réaugmente. Nous 
avons besoin de quelq'un de fort en réseau pour simuler ce fonctionnement et aider à concevoir 
des solutions. De manière générale, l'évaluation des pertes de performances 
d'un tel système pourrait peut-être - dans le cas où elles sont grandes - 
servir de motivation pour reconsidérer la question du transport UDP.</li>
<li>Un sujet lié est le contrôle de congestion : notre système 
actuel est-il suffisant pour un usage intensif ? Peut-être 
devrions-nous expérimenter des fenêtres de taille variable 
plutôt qu'à taille fixe ? C'est apparu assez efficace pour cette <a
href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">expérience 
sur ssh</a>. Nous aurons à faire des mesures et des réglages, et peut-être 
une révision de Tor si les résulats sont bons.</li>
<li>Our censorship-resistance goals include preventing
an attacker who's looking at Tor traffic on the wire from <a
href="https://www.torproject.org/svn/trunk/doc/design-paper/blocking.html#sec:network-fingerprint">distinguishing
it from normal SSL traffic</a>. Obviously we can't achieve perfect
steganography and still remain usable, but for a first step we'd like to
block any attacks that can win by observing only a few packets. One of
the remaining attacks we haven't examined much is that Tor cells are 512
bytes, so the traffic on the wire may well be a multiple of 512 bytes.
How much does the batching and overhead in TLS records blur this on the
wire? Do different buffer flushing strategies in Tor affect this? Could
a bit of padding help a lot, or is this an attack we must accept?</li>
<li>Tor circuits are built one hop at a time, so in theory we have the
ability to make some streams exit from the second hop, some from the
third, and so on. This seems nice because it breaks up the set of exiting
streams that a given relay can see. But if we want each stream to be safe,
the "shortest" path should be at least 3 hops long by our current logic, so
the rest will be even longer. We need to examine this performance / security
tradeoff.</li>
<li>It's not that hard to DoS Tor relays or directory authorities. Are client
puzzles the right answer? What other practical approaches are there? Bonus
if they're backward-compatible with the current Tor protocol.</li>
<li>Programs like <a
href="https://torbutton.torproject.org/dev/">Torbutton</a> aim to hide
your browser's UserAgent string by replacing it with a uniform answer for
every Tor user. That way the attacker can't splinter Tor's anonymity set
by looking at that header. It tries to pick a string that is commonly used
by non-Tor users too, so it doesn't stand out. Question one: how badly
do we hurt ourselves by periodically updating the version of Firefox
that Torbutton claims to be? If we update it too often, we splinter the
anonymity sets ourselves. If we don't update it often enough, then all the
Tor users stand out because they claim to be running a quite old version
of Firefox. The answer here probably depends on the Firefox versions seen
in the wild. Question two: periodically people ask us to cycle through N
UserAgent strings rather than stick with one. Does this approach help,
hurt, or not matter? Consider: cookies and recognizing Torbutton users
by their rotating UserAgents; malicious websites who only attack certain
browsers; and whether the answers to question one impact this answer.
</li>
<li>Right now Tor clients are willing to reuse a given circuit for ten
minutes after it's first used. The goal is to avoid loading down the
network with too many circuit extend operations, yet to also avoid having
clients use the same circuit for so long that the exit node can build a
useful pseudonymous profile of them. Alas, ten minutes is probably way
too long, especially if connections from multiple protocols (e.g. IM and
web browsing) are put on the same circuit. If we keep fixed the overall
number of circuit extends that the network needs to do, are there more
efficient and/or safer ways for clients to allocate streams to circuits,
or for clients to build preemptive circuits? Perhaps this research item
needs to start with gathering some traces of what connections typical
clients try to launch, so you have something realistic to try to optimize.
</li>
<li>How many bridge relays do you need to know to maintain
reachability? We should measure the churn in our bridges. If there is
lots of churn, are there ways to keep bridge users more likely to stay
connected?
</li>
</ol>

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

</div>

#include <foot.wmi>

tor-webwml.git

Maintenance French Translation