fr/volunteer.wml (cb1a8481f) - 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 a <a href="<page open-positions>">deux postes à pourvoir</a>. Merci de
<a href="<page contact>">nous contacter</a> si vous êtes qualifié !

<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>Evaluate and document <a href="<wiki>TorifyHOWTO">our list of programs</a>
that can be configured to use Tor.</li>
<li>We have a huge list of <a href="<wiki>SupportPrograms">potentially useful
programs that interface to Tor</a>. Which ones are useful in which
situations? Please help us test them out and document your results.</li>
</ol>

<a id="Advocacy"></a>
<h2><a class="anchor" href="#Advocacy">Plaidoyer</a></h2>
<ol>
<li>Créer un <a
href="https://trac.torproject.org/projects/tor/wiki/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/thetorproject">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>

Quelques-uns de ces projets peuvent sans doute faire de bonnes idées pour le
<a href="<page gsoc>">Google Summer of Code 2010</a>. Nous avons marqué
chaque idée avec son niveau d'utilité globale pour le projet Tor (priorité),
quelle quantité de travail nous attendons (niveau d'effort), avec quelles
prérequis vous pouvez commencer (compétences requises) et lequel de nos <a
href="<page people>#Core">développeurs de coeur de projet</a> sont
pré-sentis pour devenir tuteur. Si une (ou plus) de ces idées vous semble
prometteuse, merci de <a href="<page contact>">nous contacter</a> pour
discuter de vos intentions plutôt que de nous envoyer une application toute
faîte. Vous pouvez également nous proposer votre propre idée &mdash; ce qui
conduit souvent à la meilleure application.

<ol>

<li>
Pack de Navigation Tor pour Mac OS X Priorité: Haute
 Effort à fournir: Haut Compétences requises:
Moyennes Tuteurs potentiels: Steven, Erinn, Jacob,
Andrew Le Pack de Navigation Tor contient Tor, Firefox, Polipo et
l'interface graphique Vidalia (et en option le client de messagerie
instantanée <a href="http://pidgin.im/">Pidgin</a>). Les composants sont
préconfigurés pour fonctionner de manière sécurisée et requièrent très peu
de dépendances vis à vis du système d'exploitation installé. C'était
autrefois un des moyens le plus facile et le plus populaire d'utiliser Tor
sous Windows. Toutefois, il n'existe pas de paquets fonctionnant
sous Mac Os X. C'est pourquoi ce projet consiste à créer un Pack de
Navigation Tor sur OS X. Cela implique des modifications dans Vidalia (C++),
peut-être dans Firefox (C) et enfin de créer et de tester le lanceur sur
toute une gamme de versions de systèmes d'exploitation et de configuration
différentes afin de vérifier la portabilité. Un peu de ce travail a été
accompli lors du Google Summer of Code 2009. Une autre partie de ce projet
consiste à identifier toutes les traces laissées après l'utilisation d'un
Pack de Navigation sur Mac Os X ou Linux. L'étape finale consiste à trouver
un moyen de stopper, de contrer ou de supprimer ces traces. Les
étudiants désirant participer doivent connaître le développement
d'applications, de préférence, sur les deux plateformes (Linux et Mac OS X)
et doivent disposer de sérieuses compétences en C/C++ et en script shell.
 Une part de ce projet peut consister à tester ce Pack de Navigation
sur le coeur de cible des utilisateurs concernés. Cela permettrait d'en
savoir un peu plus sur ce qui a besoin d'être corrigé ou amélioré. Nous
conservons cette description comme un simple élément d'information pour le
moment mais un processus plus structuré serait bien meilleur. Une
version Beta du pack de navigation pour GNU/Linux est déjà sortie mais il
reste à travailler sur la partie messagerie instantanée. Ce travail est
également en cours sur la version Mac OS X. Si vous désirez nous aider à
améliorer la situation ou réaliser un audit sécurité sur l'un (ou l'autre)
de ces projets, n'hésitez pas à contacter Erinn.
</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>
Réécrire TorDNSEL avec cette fois, une spécification ! 
Priorité: Haute Effort à fournir: Moyen 
Compétences requises: Moyennes Tuteurs potentiels: Mike,
Roger, Sebastian, Damian La <a href="<page tordnsel/index>">Liste
de Sortie DNS Tor (ndt: Tor DNS Exit List) est un programme en Haskell non
maintenu qui a trois objectifs. Le premier est de fournir une interface DNS
rbl pour les personnes qui souhaitent savoir si une adresse IP donnée est
(ou a été récemment) un relais de sortie Tor. Le deuxième objectif est de
construire activement des circuits dans le réseau Tor pour se reconnecter à
lui-même de manière à connaître l'adresse IP réelle de sortie de chaque
relais &mdash; certains relais Tor font sortir le trafic à une autre adresse
que celle qui est affichée dans leur descripteur. Le troisième objectif
consiste à exporter <a
href="http://exitlist.torproject.org/exitAddresses">une liste</a> de manière
à ce que <a href="https://check.torproject.org/">check.torproject.org</a>
puisse deviner si votre navigateur est configuré pour utiliser Tor. 
Ce projet utilisera <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, un
ensemble de scripts Python qui interagissent avec Tor pour déterminer
comment notre Vérificateur de Relais de sortie Tor devrait fonctionner et
donc, comment le compiler &mdash; probablement en Python car Torflow est en
Python. L'objectif principal est de réduire, le plus possible, les faux
positifs en étant assuré de connaître les nouveaux relais le plus rapidement
possible, de s'assurer de terminer rapidement la phase de tests et que les
réponses soient bien transmises au script de vérification. En bonus, il
faudrait standardiser (rédiger la spécification) le format du fichier
d'adresses de sortie et réécrire le script <a
href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">Tor
Bulk Exit List</a> de manière à utiliser ce fichier plutôt que <a
href="https://trac.torproject.org/projects/tor/ticket/1019">l'horrible hack
DNS</a> qui est actuellement en vigueur. En extra-bonus, il faudrait
travailler avec Freenode, OFTC et/ou les autres réseaux IRC pour être
certains que les scripts réalisés sont bien ceux qu'ils attendent, en terme
d'identification précise des utilisateurs issus du réseau Tor. Vous
pouvez récupérer <a href="git://git.torproject.org/git/tordnsel">la dernière
version de tordnsel</a> via git.
</li>

<li>
Improving Tor's ability to resist censorship Priority:
Medium to High Effort Level: Medium to High 
Skill Level: High Likely Mentors: Roger, Nick, Steven
 The Tor 0.2.1.x series makes <a
href="<svnprojects>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. One
huge category of work is adding features to our <a
href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
service (Python). Tor aims to give out <a href="<page bridges>">bridge relay
addresses</a> to users that can't reach the Tor network directly, but
there's an arms race between algorithms for distributing addresses and
algorithms for gathering and blocking them. See <a
href="<blog>bridge-distribution-strategies">our blog post on the topic</a>
as an overview, and then look at <a
href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's or-dev
post</a> from December for more recent thoughts &mdash; lots of design work
remains. If you want to get more into the guts of Tor itself (C), a
more minor problem we should address is that 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. This project
could involve 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>
Interface de contrôle des évènements d'état de Tor Priorité:
Moyenne Effort à fournir: Moyen Compétences
requises: Faibles à Moyennes Tuteurs potentiels: Matt
 Il existe un grand nombre de changement d'état à l'intérieur de Tor
qu'il serait bon de signaler à l'utilisateur. Par exemple, si l'utilisateur
essaye de configure son noeud Tor en tant que relais et que Tor décide que
ses ports ne sont pas accessibles depuis l'extérieur, l'utilisateur devrait
en être averti. Actuellement, tous ce que l'utilisateur récupère sont les
quelques messages de log dans la fenêtre Vidalia 'message log' qui est
rarement consultée puisqu'aucun avertissement n'est notifié. Même si
l'utilisateur consulte les messages de log, ces derniers sont souvent peu
compréhensibles pour les novices. Tor a la possibilité d'informer
Vidalia de ces nombreux changements d'état et nous avons récemment
implémenté le support de quelques-uns d'entre-eux. Toutefois, il existe
beaucoup d'autres changement d'état à notifier et nous avons besoin d'une
meilleure interface pour les communiquer à l'utilisateur. L'objectif
de ce projet est donc de concevoir et d'implémenter une interface pour
notifier les évènements d'état à l'utilisateur. Par exemple, on pourrait
mettre un petit badge sur l'icône de Vidalia qui alerterait l'utilisateur
sur les évènement d'état qu'il doit consulter. Double-cliquer sur l'icône
afficherait une fenêtre résumant les évènements récents en termes faciles à
comprendre et peut-être également des suggestions pour remédier aux
évènements négatifs qui pourraient être réglés par l'utilisateur. Bien
entendu, c'est juste un exemple et les suggestions sont ouvertes. 
Une personne en charge de ce projet devrait avoir de solides compétences en
conception et en ergonomie ainsi que de l'expérience dans le développement
en C++. Une expérience avec Qt et le designer Qt serait un plus. Des
capacités de rédaction en Anglais seraient appréciées car le projet implique
probablement la rédaction de quelques documentations compréhensible par les
utilisateurs non techniques. En bonus, des compétences graphiques
permettrait de créer les belles nouvelles icônes dont nous aurons besoin.
</li>

<li>
Améliorer notre processus de tests unitaires Priorité:
Moyenne Effort à fournir: Moyen Compétences
requises: Moyennes Tuteurs potentiels: Nick, Errin Tor a besoin d'être bien plus testé. Ce travail est composé de plusieurs
parties. Pour commencer, notre couverture de tests unitaires devrait être
plus large, spécialement du côté des fonctions utilitaires. Cela implique la
refonte de certaines parties de Tor dans le but de dissocier le plus
possible la logique du reste. Ensuite, nous devons automatiser les
tests de performance. Nous avons utilisé builbot pour automatiser notre
processus d'intégration et de tests de compilation (nous sommes à la
recherche de quelqu'un qui pourrait le faire fonctionner sous Windows). Mais
nous avons besoin de mettre à jour nos tests de simulation réseau
(construits dans <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>) pour
les versions récentes de Tor et de concevoir la mise en place d'un réseau de
test soit sur une seule machine soit sur plusieurs de manière à tester
automatiquement les changements de performances selon les rôles de chaque
machine.
</li>

<li>
Aider les implémentations de clients Tor indépendantes 
Priorité: Moyenne Effort à fournir: Important 
Compétences requises: Moyennes à Hautes Tuteurs potentiels:
Karsten, Nick D'autres personnes travaillent en ce moment sur
des clients Tor pour Java, Android et Maemo. La première étape est de vous
intéresser au projet dans lequel vous désirez vous investir: <a
href="http://github.com/brl/JTor">Tor pour Java</a>, <a
href="https://svn.torproject.org/svn/projects/android/trunk/">Androif/Orbot</a>
ou Tor pour Maemo. Consultez les dépôts et familiarisez-vous avec le code
source. De plus, nous recherchons quelqu'un qui pourrait (mais ce n'est
pas requis) travailler sur l'interrogation ou même l'hébergement des
services cachés Tor sur ces plateformes. Un développeur compétent
devrait être capable de comprendre et d'écrire du code Java, y compris une
API Java de chiffrement. Connaître le C serait également un vrai plus. Il
faut également vouloir lire et contribuer à la documentation existante car
l'implémentation du code est basée sur celle-ci. Ce projet est
essentiellement un projet de code qui nécessite quelques compétences en
matière de conception.
</li>
<li>
Plus de développements spécifiques à Orbot &amp; Androïd 
Priorité: Moyenne Effort à fournir: Important 
Niveau de compétences: Moyennes à élevées Tuteurs potentiels:
Nathan Travail sur l'interface graphique Java Androïd:
Écran d'accueil amélioré pour miex présenter les statistiques sur les
transferts de données (entrée/sortie), nombre de circuits connectés, qualité
de la connexion, etc... L'application Androïd "Tether Wifi" est un modèle à
suivre car elle montre en temps réel le nombre d'octets transférés ainsi que
les notifications lorsque le client wifi se connecte. De plus, il faudrait
améliorer l'affichage des messages d'erreur. Enfin, l'ajout d'un assistant
ou d'un tutoriel pour les novices qui leur expliquerait ce qu'est vraiment
l'anonymat leur permettrait d'utiliser correctement Orbot. 
Travail sur le coeur de l'application Java Androïd: Il y a besoin
d'un meilleur système d'indication, par la barre de notification, des
pop-ups ou tout autre mode que le traffic d'une application circule à
travers Orbot/Tor. Par exemple, vous devez consulter un site de vérification
pour confirmer que votre navigateur web route bien son traffic à travers
Tor. Orbot devrait être capable de notifier que les circuits ont été
ouverts, utilisés, etc... Le pisteur de transfert de données mentionné
ci-dessus pourrait également indiquer cette information. 
Travail de sensibilisation de la communauté sur un bibliothèque Java
Android Nous devons mettre en paquet une bibliothèque simplifiée pour
permettre de "Torifier" certaines applications sur les périphériques
non-root (aka proxy transparent). Cette bibliothèque devrait inclure un
wrapper pour la bibliothèque Apache HTTPClient, une classe pour détecter
l'état de connexion d'Orbot et d'autres choses utiles pour une application
Android qui aurait besoin de se rendre anonyme. Ce travail inclue la
création de la bibliothèque, la documentation et un exemple de code. Le
travail d'implémentation avec d'autres applications open-source
suivra. Travail sur Android OS/C/Linux: Le portage de Tor
sur Androïd est basiquement une compilation croisée sur Linux ARM. Aucun
travail d'optimisation avec l'environnement matériel n'a été mené, ni sur le
processeur ARM ou le matériel Android ou sur les réseaux mobiles. Malgré ce
manque d'optimisation, Tor gère plutot bien l'environnement des réseaux
mobiles, détecte automatiquement le changement d'adresse IP, reconnecte les
circuits et gère le passage d'un réseau 2G à 3G à Wifi. 
</li>

<li>
New Torbutton Features Priority: Medium Effort
Level: High Skill Level: High Likely Mentors:
Mike There are several <a
href="https://trac.torproject.org/projects/tor/report/14">good feature
requests</a> on the Torbutton Trac section. In particular, <a
href="https://trac.torproject.org/projects/tor/ticket/523">Integrating 'New
Identity' with Vidalia</a>, <a
href="https://trac.torproject.org/projects/tor/ticket/940">ways of managing
multiple cookie jars/identities</a>, <a
href="https://trac.torproject.org/projects/tor/ticket/637">preserving
specific cookies</a> when cookies are cleared, <a
href="https://trac.torproject.org/projects/tor/ticket/524">better referrer
spoofing</a>, <a
href="https://trac.torproject.org/projects/tor/ticket/564">correct Tor
status reporting</a>, and <a
href="https://trac.torproject.org/projects/tor/ticket/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>
Équivalent de Torbutton pour Thunderbird Priorité:
Moyenne Effort à fournir: Important Compétences
requises: Hautes Tuteurs potentiels: Mike Nous
entendons parler d'un nombre de plus en plus important d'utilisateurs qui
désirent utiliser Thunderbird avec Tor. Néanmoins, il y a plein de problèmes
de niveau applicatifs, par exemple, par défaut Thunderbird ajoutera votre
nom d'hôte au mail sortant qu'il envoie. A un certain niveau, nous devrions
pousser la réalisation d'une extension Thunderbird similaire à Torbutton.
</li>

<li>
Améliorer Tor Weather Priorité: Moyenne Effort à
fournir: Moyen Compétences requises: moyennes 
Tuteurs potentiels: Christian, Roger, Damian <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 aux autorités d'annuaire leur
indiquant 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>
Améliorer la mise en paquets de Tor et Vidalia sur Debian/Ubuntu Priorité: Moyenne Effort à fournir: Moyen 
Compétences requises: Moyennes Tuteurs potentiels: Erinn,
Peter Vidalia ne fonctionne pas correctement avec Tor sur les
plateformes Unix et Linux. En fait, sous Debian et Ubuntu, il y a un
mécanisme de configuration qui permet à Vidalia d'empêcher Tor de se lancer
au boot (en éditant <code>/etc/default/tor.vidalia</code> en indiquant
<code>RUN_DAEMON=no</code>). Néanmoins, il y a besoin de d'implémenter
complètement un <a
href="<gitblob>doc/spec/control-spec.txt">ControlPort</a>. Une
meilleure solution sur les plateformes Linux et Unix serait d'utiliser la
directive ControlSocket qui permet à Vidalia de communiquer avec Tor via une
socket Unix et cela pourrait être activé par défaut dans les paquets Tor des
distributions. Vidalia peut ensuite s'authentifier sur Tor en utilisant
l'authentification du système de fichier (cookie) si l'utilisateur qui a
lancé Vidalia est également dans le groupe spécifique à tor pour sa
distribution. Ce projet implique d'abord le support de la directive
ControlSocket dans Vidalia. L'étudiant développera et testera alors les
paquets Vidalia pour de nombreuses distributions et s'assurera qu'ils
fonctionnent correctement. Le challenge suivant sera de trouver un
moyen intuitif et utilisable pour Vidalia de modifier la configuration de
Tor (torrc) même s'il est situé dans <code>/etc/tor/torrc</code>. Sous
Debian et Ubuntu, nous gérons cela avec le fichier
<code>/etc/default/tor.vidalia</code> susmentionné, mais cette
fonctionnalité pourrait être moins spécifique à ces distributions. La
meilleure idée que nous avons trouvée jusqu'à présent est de faire passer
cette configuration par le ControlSocket lorsque Vidalia démarre mais c'est
une méthode discutable car si l'utilisateur n'utilise pas les derniers
paquets Debian/Ubuntu de Tor, ils n'ont sans doute pas désactiver la
capacité de Tor à se lancer au démarrage et ils récupéreront une
configuration différente de ce qu'ils désirent. La deuxième idée consiste à
faire écrire à Vidalia un fichier temporaire torrc et demander à
l'utilisateur de le déplacer manuellement dans <code>/etc/tor/torrc</code>
mais c'est également discutable car les utilisateurs ne devraient pas gérer
ces fichiers directement. Une personne intéressée par ce projet doit
disposer d'une certaine connaissance des règles d'empaquetage dans Debian et
avoir une expérience en C++. Des compétences en QT seraient un vrai plus.
</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é: Basse 
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 les 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 ne sommes
plus acceptés que sur quasiement 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. Quelques travaux sur ce sujet ont été
initiés par d'autres contributeurs; vous pouvez consultezr leurs progrès sur
<a href="http://github.com/anonirc/orc">http://github.com/anonirc/orc</a>.
</li>

<li>
Faire fonctionner torsocks/dsocks sur OS X Priorité:
Moyenne Effort à fournir: Moyen Compétences
requises: Moyennes Tuteurs potentiels: ? <a
href="http://code.google.com/p/torsocks/">Torsocks</a> et <a
href="http://code.google.com/p/dsocks/">dsocks</a> sont des wrappers qui
fonctionnent avec des applications, en interceptent leurs connexions réseau
sortantes et les injectent dans Tor. L'objectif est de gérer les
applications qui ne supportent pas les proxy (ou qui ne les supportent pas
correctement). Ces wrappers doivent intercepter de nombreux appels
systèmes. Ces appels systèmes sous Linux sont complètement différents de
ceux de BSD. Ainsi, torsocks fonctionne bien sous Linux, dsocks fonctionne
bien sous BSD (bien qu'il soit moins bien maintenu et qu'il puisse rater
davantage d'appels systèmes) mais rien ne fonctionne bien sur les deux
systèmes. D'abord, il faut patcher dsocks pour qu'il utilise les commandes
de mapadress depuis l'interface de contrôle de manière à ne pas
perdre trop de temps pendant la résolution qui s'effectue dans Tor avant la
connexion. Ensuite, notre script torify doit détecter si tsocks ou
dsocks est installé et appelé celui qui est légitime. Cela implique
d'unifier l'interface de ces deux wrappers et peut-être de partager du code
entre eux ou bien d'en laisser tomber un des deux.
</li>

<li>
Bring up new ideas! Don't like any of these? Look at the <a
href="<svnprojects>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>Tor relays don't work well on Windows XP. On Windows, Tor uses the standard
<tt>select()</tt> system call, which uses space in the non-page pool. This
means that a medium sized Tor relay will empty the non-page pool, <a
href="<wiki>WindowsBufferProblems">causing havoc and system crashes</a>. We
should probably be using overlapped IO instead. One solution would be to
teach <a href="http://www.monkey.org/~provos/libevent/">libevent</a> how to
use overlapped IO rather than select() on Windows, and then adapt Tor to the
new libevent interface. Christian King made a <a
href="https://svn.torproject.org/svn/libevent-urz/trunk/">good start</a> on
this in the summer of 2007.</li>

<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 uses TCP for transport and TLS for link encryption. This is nice and
simple, but it means all cells on a link are delayed when a single packet
gets dropped, and it means we can only reasonably support TCP streams. We
have a <a
href="<wiki>TorFAQ#YoushouldtransportallIPpacketsnotjustTCPpackets.">list of
reasons why we haven't shifted to UDP transport</a>, but it would be great
to see that list get shorter. We also have a proposed <a
href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specification for
Tor and UDP</a> &mdash; please let us know what's wrong with it.</li>

<li>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 modifier à la main avec un éditeur
d'image. 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="https://amnesia.boum.org/">Le
système Live (Amnesic)</a> est un bon exemple.
</li>

<li>
Un autre projet anti-censure est de rendre Tor plus résistant au scans
réseaux. Pour le moment, un attaquant peut identifier <a
href="<gitblob>doc/spec/proposals/125-bridges.txt">les passerelles Tor</a>
en essayant simplement de se connecter à elles en utilisant le protocole Tor
pour vérifier si elles répondent. Pour régler ce problème, les passerelles
pourraient <a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">agir
comme des serveurs webs</a> (HTTP ou HTTPS) lorsqu'elles sont contactées par
des outils de scan de port et agir comme des passerelles uniquement lorsque
l'utilisateur aura amené une clef spécifique. Pour commencer, consultez <a
href="http://dl.dropbox.com/u/37735/index.html">la thèse et le prototype</a>
de Shane Pope.
</li>

</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Recherche</a></h2>
<ol>
<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="<svnprojects>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 parfaite 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 files for the website