tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 13966

3) # Last-Translator: mfr(ä]misericordia.be, fredzupy@gmail.com

4) 

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

6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->

10) <h2>Un certain nombre de choses que vous pouvez faire:</h2>

11) <ol>

12) <li>Pensez à <a href="<page docs/tor-doc-relay>">héberger 

13) un relais</a> pour aider à la croissance du réseau Tor.</li>

14) <li> Informez vos amis ! Faites-leur héberger des serveurs. Faites-leur utiliser les services 
15) cachés. Encouragez-les à informer leurs propres amis.</li>
16) <li> Si vous adhérez aux objectifs de Tor, prenez s'il-vous-plaît un moment 

17)   <a href="<page donate>">pour faire un don et aider aux développements 

18)   futurs de Tor</a>. Nous recherchons également plus de sponsors - si vous connaissez des 
19)   entreprises, des ONG, ou d'autres organisations qui souhaitent utiliser des communications 

20)   sécurisées, parlez-leur de nous.</li>

21) </ol>
22) 
23) <a id="Usability"></a>
24) <h2><a class="anchor" href="#Usability">Support d'applications</a></h2>
25) <ol>

26) <li>Nous avons besoin de plus méthodes efficaces d'interception des requêtes DNS, pour qu'elles ne laissent pas filtrer d'informations à un observateur local pendant que nous tentons d'être anonymes. (Ce qui 

27) arrive lorsque l'application fait sa résolution DNS avant de passer par 
28) le proxy SOCKS.)</li>

29) <li>Élements tsocks/dsocks :

30) <ul>

31) <li>Nous avons besoin <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">d'appliquer 

32) tout nos patchs à tsocks</a> et d'en maintenir une nouvelle branche. Nous l'hébergerons si 
33) vous le souhaitez.</li>
34) <li>Nous devrions patcher le programme « dsocks » développé par Dug Song pour utiliser les commandes 
35) <i>mapaddress</i> de Tor depuis l'interface de contrôle, de manière à ne pas faire 
36) inutilement un aller-retour complet dans Tor pour faire la résolution avant la 
37) connexion.</li>
38) <li>Notre script <i>torify</i> doit détecter lequel de tsocks ou 
39) dsocks est installé pour l'appeler correctement. Cela nécessite certainement 
40) d'unifier leurs interfaces, et peut amener à faire un mix des deux 
41) voire à en éliminer un des deux.</li>

42) </ul>

43) </li>

44) <li>Les gens qui hébergent des serveurs nous signalent qu'ils aimeraient avoir une passante allouée 
45) durant une partie de la journée, et une autre bande passante à un autre moment. 
46) Plutôt que de coder ceci dans Tor, nous aimerions utiliser un petit 
47) script qui communique avec <a href="<page gui/index>">l'interface de contrôle de Tor</a>, 
48) et ferait un setconf pour changer la valeur de la bande passante. Éventuellement, ce pourrait être un script lancé 
49) par cron, ou qui se lancerait à certaines heures (
50) ce qui est certainement plus portable). Quelqu'un pourrait-il écrire cela pour nous, 
51) nous l'ajouterons à <a href="<svnsandbox>tor/contrib/">tor/contrib/</a> ? 
52) C'est une bonne entrée pour la <a href="<page gui/index>"> compétition pour l'interface 
53) graphique de Tor</a>.

54)   <!-- Nous avons un bon script pour ça maintenant, n est-ce pas ? -NM -->

55) </li>
56) <li>Tor peut <a 

57) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">quitter 

58) le réseau Tor par un noeud de sortie particulier</a>, mais il serait pratique 
59) de n'avoir qu'à spécifier un pays, et que le serveur de sortie soit choisi automatiquement. Le 
60) meilleur moyen est probablement de récupérer le répertoire de Blossom, et d'utiliser en local un client 
61) qui récupère ce répertoire de manière sûre (via Tor et en vérifiant sa 
62) signature), lise les noms des machines <tt>.country.blossom</tt> et se charge ensuite
63) de choisir le serveur.</li>
64) <li>En parlant de géolocalisation, quelqu'un devrait faire une carte de la Terre 
65) indiquant chaque serveur Tor par un point. La cerise sur le gâteau serait la mise à jour dynamique 
66) de la carte à mesure que le réseau Tor évolue et grandit. Malheureusement, les moyens aisés de faire cela 
67) passent par l'envoi de toutes les données à Google pour qu'il trace cette carte pour vous. Dans quelle mesure 

68) cela jouerait-il sur la confidentialité, et par ailleurs, existe-t-il des solutions de remplacement valables ?</li>

69) </ol>
70) 
71) <a id="Documentation"></a>
72) <h2><a class="anchor" href="#Documentation">Documentation</a></h2>
73) <ol>

74) <li>Aidez Matt Edman à documenter et à écrire des tutoriaux pour son 
75) contrôleur Tor,
76) <a href="http://vidalia-project.net/">Vidalia</a>.</li>
77) <li>Évaluez et documentez 

78) <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">notre 

79) liste de programmes</a> pouvant être utilisés avec Tor.</li>
80) <li>Nous avons besoin d'une meilleure documentation traitant de l'interception dynamique de 
81) connexions et de leur envoi à travers Tor. tsocks (Linux), dsocks (BSD), 
82) et freecap (Windows) semblent être de bons candidats, et utiliserait au mieux
83) notre nouvelle fonctionnalité Transport.</li>

84) <li>Nous avons toute une liste de <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programmes 

85) potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles et dans quelles 

86) situations ? Contribuez à les tester et à documenter les résultats.</li>

87) <li>Aidez-nous à traduire le site et la documentation dans d'autres 
88) langues. Allez voir les <a href="<page translation>">conseils de 

89) traduction</a> si vous souhaitez le faire. Nous avons besoin plus spécialement de personnes pour 
90) traduire en Arabe ou en Persan pour les utilisateurs Tor situés dans les zones censurées.</li>

91) </ol>
92) 
93) <a id="Coding"></a>

94) <a id="Summer"></a>
95) <a id="Projects"></a>

96) <h2><a class="anchor" href="#Projects">Bons Projets de codage</a></h2>
97) <p>Vous pouvez trouver que certains de ces projets sont de bonnes idées pour le <a href="<page
98)   	 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
99)   	 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
100)   	 href="<svnsandbox>doc/spec/proposals/">propositions actuelles</a>, ou tout simplement vos propres idées.</p>

101) <ol>
102)   	 
103) <li>
104) <b>Tor/Polipo/Vidalia cadre de mise à jour automatiques</b>
105) <br />
106) Priorité : <i>élevée</i>
107) <br />
108) Niveau d'effort : <i>élevé</i>
109) <br />

110) Niveau de connaissance : <i>élevé</i>

111) <br />
112) Mentors probables : <i>Matt, d'autres</i>
113) <br />
114) Vidalia à déjà la capacité de notifier quand un utilisateur fait tourner une
115) ancienne version ou une version non recommandée de Tor. Pour l'instant, Vidalia signale simplement
116) à l'utilisateur qu'il doit manuellement mettre à
117) jour. Le but de ce projet serait d'étendre la capacité de Vidalia en lui 
118) permettant également de rappatrier et installer la mise à jour de Tor à la place de
119) l'utilisateur. Si le temps le permet, nous aimerions aussi être capable de faire de même
120) pour les autres applications du « tout en un » comme Polipo et 
121) Vidalia lui même.
122) <br />
123) Pour mener à bien ce projet, l'étudiant devra premièrement avoir besoin d'enquêter
124) sur les ensembles de mises à jour déjà existant (p.e. Sparkle sur OS X) pour évaluer
125) leur forces, leurs faiblesses, les implications de sécurité, et la capacité à être
126) intégré dans Vidalia. Si aucun ne convient, l'étudiant
127) fera son propre cadre de mise à jour automatique, documentera la conception, et
128) discutera alors avec les autres développeurs pour évaluer tout problème de 
129) sécurité. L'étudiant pour alors implémenter son cadre (ou intégrer
130) l'existant) et le tester.
131) <br />
132) L'étudiant qui entreprendra ce projet devra avoir une bonne expérience en 
133) développement C++. Une expérience passée sur Qt est utile, mais non requise. L'
134) étudiant devrait avoir également une compréhension basique des pratiques de sécurité
135) usuelles, telle que la vérification de signature de paquet. Une bonne capacité d'écriture
136) est également importante pour ce projet, puisqu'une étape cruciale conciste à produire
137) un document de conception pour que les autres puissent le relire et discuter avec l'étudiant
138) avant l'implémentation.
139) </li>
140)   	 
141) <li>
142) <b>Une carte du réseau étendue et plus utilisable</b>
143) <br />
144) L'une des options existante de Vidalia est une carte du réseau qui montre la localisation
145) géographique approximative du relais dans le réseau Tor et
146) trace le chemin du trafic utilisateur tel qu'il est tunnellisé à travers le
147) réseau Tor. La carte n'est pour l'instant pas très interactive et est plutôt 
148) pauvre graphiquement. À la place, nous  aimerions profiter du widget Marble de KDE
149) qui nous apporterait une carte de meilleur qualité et étendrait l'interactivité,
150) en permettant à l'utilisateur de cliquer sur des relais ou circuit pour 
151) obtenir des informations supplémentaires. Il serait aussi souhaitable de permettre
152) à l'utilisateur de cliquer sur un relais particulier ou un pays contenant un ou
153) plusieurs relais Tor de sortie et dire « je souhaite que mes connexions à truc.com sortent
154) par là ».
155) <br />
156) Ce projet nécessite d'abord que l'étudiant soit à l'aise avec Vidalia
157) et l'API de l'objet Marble. L'étudiant devra alors intégrer l'objet dans 
158) Vidalia et configurer Marble pour s'indapter dans notre application,
159) comme faire des circuits cliquable, stocker des données cartes dans le répertoire
160) de donnée de Vidalia, et adapter quelques une des boites de dialogue.
161) <br />
162) L'étudiant prenant en charge ce projet devra avoir une bonne expérience en 
163) développement C++. Une expérience avec Qt et CMake est utile, mais non
164) requise.
165) </li>
166)   	 
167) <li>
168) <b>Mise en paquet Debian et support</b>
169) <br />
170) Vidalia ne s'intègre pas facilement sous Debian et Ubuntu avec les 
171) paquets par défaut Tor. Le paquet Tor courant démarre automatiquement Tor
172) en tant que démon tournant avec l'utilisateur debian-tor et (judicieusement) n'a pas 
173) de ControlPort défini dans son torrc par défaut. En conséquence de quoi, Vidalia tente
174) de lancer son propre processus Tor puisqu'il n'arrive pas à se connecter à un Tor existant, 
175) Le Tor de Vidalia quitte ensuite avec un message d'erreur que 
176) l'utilisateur a des chances de ne pas comprendre puisque Tor n'arrive pas à prendre le port
177) d'écoute—-il est déjà pris par le démon Tor original.
178) <br />
179) La solution actuelle implique soit de dire à l'utilisateur de stopper le Tor
180) existant et laisser Vidalia lancer son propre processus Tor, ou
181) expliquer à l'utilisateur comment paramètrer le port de control et le mot de passe dans leur
182) torrc. Une meilleur solution sous Debian serait d'utiliser le ControlSocket de Tor,
183) qui permet à Vidalia de communiquer avec Tor par une socket Unix, et pourrait 
184) être activée par défaut dans le paquet Debian. Vidalia pourrait 
185) alors s'identifier sur Tor en utilisant une identification par cookie si l'utilisateur faisant tourner
186) Vidalia est également dans le groupe debian-tor.
187) <br />
188) Ce projet devra premièrement ajouter le support dans Tor d'une ControlSocket 
189) pour Vidalia. L'étudiant devra alors développer et tester les paquets pour Debian et
190) Ubuntu qui se conforment aux standards de déploiment Debian et
191) s'assurer que ça fonctionne bien avec les paquets Tor courant. We nous pouvons également
192) mettre en place un dépôt apt pour héberger les nouveaux paquets Vidalia.
193) <br />
194) L'étudiant qui prendra en charge ce projet devra avoir une expérience passée dans 
195) la gestion des paquets Debian et une expérience en développement C++. Des connaissances
196) sur Qt aident mais ne sont pas requises.
197) </li>
198)   	 
199) <li>
200) <b>Interface d'évenements de status Tor</b>
201) <br />
202) Il existe de nombreux changement de status pour lequel l'utilisateur devrait 
203) être informé. Par exemple, si l'utilisateur essaye de mettre au point un 
204) relais Tor et que Tor montre que le relais utilisateur n'est pas atteignable à l'exterieur
205) du réseau utilisateur, nous devrions alerter l'utilisateur. Pour l'instant, l'utilisateur n'a
206) que deux ligne dans les messages de log de Vidalia, qui ont des chances de n'être jamais vues
207) puisqu'aucune notification du dysfonctionnement n'est envoyée. Même si l'utilisateur regarde les messages,
208) la plupart sont sans significations pour l'utilisateur novice.
209) <br />
210) Tor a la capacité d'informer Vidalia de changement de status similaires, et
211) nous avons récemment implémenté le support pour deux de ces évennements. Mais
212) il y'a beaucoup d'autres evènements pour lesquels l'utilisateur doit être informé et nous
213) avons besoin d'une meilleur interface graphique pour les afficher à l'utilisateur.
214) <br />
215) Le but de ce projet est de concevoir et implémenter une interface graphique 
216) pour afficher les évenements de status Tor à l'utilisateur. Par exemple, nous pourrions mettre un
217) petit badge sur l'icone de Vidalia pour alerter l'utilisateur d'un nouvel 
218) évenement qu'il devrait regarder. Double-cliquer sur l'icone pourrait ouvrir 
219) une fenêtre qui résumerait les évenements récent en termes simples et pourquoi pas,
220) suggerer une solution pour tout status négatif s'ils sont corrigeable par l'
221) utilisateur. Bien entendu, ceci n'est qu'un exemple et l'étudiant est libre de
222) proposer une autre approche.
223) <br />
224) L'étudiant qui prendra en charge ce projet devra avoir une bonne expérience dans la conception et l'ergonomie 
225) des interfaces graphique et quelques expériences en développement C++. Des expériences passées avec 
226) Qt et Qt Designer seraient très utiles, mais non requises. Une
227) bonne capacité d'écriture en Anglais sera très utile, puisque ce projet à des chances
228) de nécessiter la rédaction de petites aides qui puissent être comprises
229) par des personnes non techniques. Des points de bonus pour la modelisation de nouvelles
230) icone puisque nous en auront surement besoin.
231) </li>
232)   	 
233) <li>
234) <b>Un Wiki traduction</b>
235) <br />
236) Nous avons besoin d'un moyen d'éditer et traduire le site web &mdash;
237) qui pourrait aboutir à un patch pour l'arbre svn. L'actuel
238) «Coût» de la publication des modifications apportées au site Web est assez élevé, même pour l'anglais.
239) Les mainteneurs ont besoin de consulter nos fichiers modèles, les traduire
240) et nous envoyez la traduction. Pour changer un seul mot ou n'importe quel type de
241) changement mineur, la page ne peut jamais être corrigées ou traduites. Il serait
242) bien d'avoir un wiki qui a été spécialement conçu pour la traduction
243) et pourrait traquer à partir de la version officielle (anglaise) si
244) une nouvelle traduction est nécessaire. Cela semble être le travail d'un intégrateur wiki
245) ou un auteur de logiciel wiki. Certes, la personne devra
246) être intéressées par les langues et de la traduction. Il devrait au moins
247) à minima être familier avec ce que Tor est mais n'aurait pas d'interaction
248) avec le logiciel, seulement la documentation sur le site.
249) </li>
250)   	 
251) <li>
252) <b>Améliorations de notre testeur de configuration active de navigateur</b> -
253) <a href="https://check.torproject.org">https://check.torproject.org</a>
254) <br />
255) Actuellement, nous avons une page Web fonctionnelle pour détecter si Tor fonctionne. Il  	 
256) ya des manques à quelques endroits. Il nécessite quelques améliorations s'agissant
257) des langues par défaut et des fonctionnalités. Il répond pour l'instant qu'en
258) Anglais. De plus, c'est un hack d'un script perl qui n'aurait
259) jamais dû voir le jour. Il devrait être réécrit en python
260) avec un support multi-langues. Il utilise actuellement la liste de sortie DNS 
261) Tor et devrait continuer à faire de même dans le futur. Il peut y'avoir de temps en temps
262) des faux positif et ceci devrait être découvert, documenté et corrigé lorsque 
263) c'est possible. Toute personne travaillant sur ce projet devrait être interessée par 
264) DNS, les bases de perl ou de préférence python et auront un peu à interagir avec
265) Tor pour tester leur code.
266) </li>
267)   	 
268) <li>
269) <b>Amélioration de notre liste de sortie DNS</b> -
270) <a href="http://exitlist.torproject.org">http://exitlist.torproject.org</a>
271) <br />
272) Le logiciel exitlist est écrit par notre fabuleux contributeur 
273) anonyme Tup. C'est un serveur DNS écrit en Haskell qui supporte une partie de notre <a
274) href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">document
275) de conception exitlist</a>. Actuellement, c'est fonctionnel et utilisé par
276) check.torproject.org et d'autres utilisateurs. Les problèmes qui sont en suspens
277) sont pour la plupart esthétiques. Ce service merveilleux pourrait bien mieux utiliser
278) le site web en utilisant la charte graphique Tor. It serait mieux servi avec une meilleure
279) documentation pour les services communs qui utilisent une RBL. Il pourrait y'avoir d'avantage
280) de publicité. La personne travaillant sur ce projet devrait être interessée par les DNS,
281) la configuration basique de RBL pour des services populaires, et écrire de la documentation.
282) La personne devrait avoir un peu d'interaction avec Tor &mdash; tester leur propre
283) documentation au minimum. De plus, ce serait utile
284) qu'il soit interessé par Haskell et souhaite implémenter d'avantages des suggestions du 
285) torel-design.txt.
286) </li>
287)   	 
288) <li>
289) <b>Tester l'intégration de Tor avec les navigateur pour nos utilisateurs finaux</b>
290) <br />
291) 
292) Le Projet Tor manque actuellement de test solide pour s'assurer que 
293) l'utilisateur a proprement configuré son navigateur. Il devrait tester la plupart
294) des problèmes connus autant que possible. Il devrait essayer de découvrir 
295) l'utilisateur par tous les moyens possibles. Deux pages web qui tracent ces
296) type de problèmes sont fournies par Greg et HD Moore. Greg conserve une bonne <a
297) href="http://pseudo-flaw.net/tor/torbutton/">liste de problèmes avec 
298) leur code de preuve de concept, les bugs, etc</a>. HD Moore fournit
299) le <a href="http://metasploit.com/research/misc/decloak/">site
300) decloak</a>. Une personne interessée par l'attaque de Tor peut commencer
301) par collecter autant de solutions fonctionnelles et de méthodes connues pour réveller
302) un utilisateur Tor. La personne devrait être familière des écueils courants mais pourrait
303) avoir d'autres méthodes en tête pour implémenter des outils de désanonymisation. Le
304) site web devrait s'assurer d'informer l'utilisateur de ce que sont ses problèmes. Il
305) devra l'aider à les résoudre ou les renvoyer directement sur le bon canal de 
306) soutien. La personne devra être très familière dans l'utilisation de Tor et comment
307) palier aux fuites de Tor.
308) </li>
309)   	 
310) <li>
311) <b>Accroitre notre capacité à résister à la censure.</b>
312) <br />
313) Tor a besoin de d'avantage de mécanisme de résistance à la censure. Il y a
314) plusieurs mécanismes qui peuvent aider.  Tor pourrait être capable d'écouter sur de multiples
315) adresses et ports, et autoriser les clients à se connecter sur l'ensemble d'entre eux.
316) Tor pourrait apparaitre comme un serveur web (HTTP ou HTTPS) lorsqu'il
317) est contacté par scanner de ports.
318) </li>
319)   	 
320) <li>
321) <b>Amélioration de l'intégration Libevent et Tor</b>
322) <br />
323) Tor devrait faire un meilleur usage des récentes options de Niels Provos dans
324) la bibliothèque Libevent.  Libevent apporte déjà HTTP et des tampons de socket ;
325) Le code de Tor pour ces choses pourrait être remplacé. Nous aurons à améliorer le code
326) de libevent autant que nécessaire ; particulièrement, pour ajouter un bon support openssl au dessus de
327) la couche d'abstraction des tampons de libevent.
328) </li>
329)   	 
330) <li>
331) <b>Étendre les performances de Tor!</b>
332) <br />
333) Tor pourrait mesurer la bande passante de manière distribuée, comme dans cette publication
334) <a href="http://freehaven.net/anonbib/">« A Tuneup for Tor »</a>
335) de Snader et Borisov. L'étudiant pourrait utiliser le code déjà existant
336) pour contrôler les conclusions de ce document et vérifier dans quelle mesure elles
337) rejoignent Tor dans la réalité, et déterminer de bonnes méthodes de les incorporer
338) dans le réseau Tor sans ajouter un trafic indésirable d'ordre n² 
339) sur les annuaires principaux.
340) </li>
341)   	 
342) <li>
343) <b>Améliorer le processus qualité de Tor : Intégration continue pour les paquets Windows</b>
344) <br />
345) Il serait interessant d'avoir une automatisation des compilation pour Windows et
346) probablement d'autres plateformes. Le but d'avoir une intégration continue
347) des environnements est de s'assurer que Windows n'est pas mis de coté pour aucun
348) des projets logiciels utilisés par le Projet Tor où ses contributions.<br />
349) Buildbot serait un bon choix pour ça puisqu'il semble supporter l'ensemble des 
350) platformes de Tor. Voyez l'
351) <a href="http://en.wikipedia.org/wiki/BuildBot">entrée wikipedia pour
352) buildbot</a>.<br />
353) Il pourrait y'avoir de meilleurs options et la personne prenant en charge cette tâche devrait
354) évaluer d'autres options. Toute personne travaillant sur ce processur de compilation 
355) automatique devrait avoir ou être en mesure d'avoir l'expérience pour apprendre à construire l'ensemble
356) des sources relatives à Tor à partir du début. En outre, la
357) personne devrait avoir l'expérience de la compilation sous un environnement
358) Windows puisqu'il s'agit de l'audience finale dont nous voulons nous assurer que nous ne les laissons
359) pas à la traine. Ça devrait nécessiter un travail proche du code source de Tor mais
360) probablement uniquement sous l'aspect compilation, pas de rédaction de code.<br />
361) De plus, nous avons besoin d'automatiser nos tests de performance pour toutes les plateformes.
362) Nous avons buildbot (excepté sous Windows &mdash; comme dit au dessus) pour automatiser
363) notre intégration régulièrement et tester la compilation déjà,
364) mais nous avons besoin d'avoir notre test de simulation de réseau (comme dans torflow)
365) mis à jour pour des versions plus récentes de Tor, et faites pour lancer un test
366) de réseau à la fois sur une seule machine, et sur plusieurs, afin que nous puissions tester
367) les changements de performance sur des machins de roles différents automatiquement.<br />
368) </li>
369)   	 
370) <li>
371) <b>Amélioration de notre banc de test</b>
372) <br />
373) Tor doit être bien plus testé.  C'est un effort multi-partie.  Pour commencer,
374) Notre unité de couverture de test devrait augmenter substantiellement, spécialement dans
375) les zones en dehors des fonctions utilitaires. Ceci devra conduire à une refonte
376) significative des certaines parties de Tor, dans le but de dissocier autant de logique
377) que possible de la globalité.<br />
378) De plus, nous avons besoin d'automatiser nos tests de performance pour toutes les plateformes.
379) Nous avons buildbot (excepté sous Windows &mdash; comme dit au dessus) pour automatiser
380) notre intégration régulièrement et tester la compilation déjà,
381) mais nous avons besoin d'avoir notre test de simulation de réseau (comme dans torflow)
382) mis à jour pour des versions plus récentes de Tor, et faites pour lancer un test
383) de réseau à la fois sur une seule machine, et sur plusieurs, afin que nous puissions tester
384) les changements de performance sur des machins de roles différents automatiquement.<br />
385) </li>
386)   	 
387) <li>
388) <b>Aider à raviver la communauté Java autour de Tor</b>
389) <br />
390) Réanimer l'une des approches d'implématation d'un client Tor en Java,
391) p.e. le <a href="http://onioncoffee.sourceforge.net/">Projet
392) OnionCoffee</a>, et le faire tourner sur <a
393) href="http://code.google.com/android/">Android</a>. La première étape
394) pourrait être de porter le code existant et l'exécuter dans un environnement
395) Android. Ensuite, le code pourrait être mis à jour pour supporter les nouvelles
396) version de protocole comme la <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
397) des protocole d'annuaire</a>. Ensuite, le support pour les requêtes ou même
398) apporter des services cachés serait sympa, mais non requis. L'étudiant
399) devrait être capable de comprendre et écrire du code Java, comprenant
400) une API de cryptographie Java. Capable de lire du code C serait utile,
401) également. L'étudiant devrait être prêt à lire la documentation existante,
402) implémenter du code de celle ci, et, si nécessaire, refaire la documentation
403) si des éléments ne sont pas documentés. Ce projet est principalement du codage et
404) à un degré moindre, de la conception.
405) </li>
406)   	 
407) <li>
408) <b>Devenir le Maître PuppeTor</b>
409) <br />
410) Écrire un outil qui lance un système de tests automatique en plus
411) de l'unité de tests existante. Le simulateur Tor en Java <a
412) href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
413) devrait être un bon départ pour commencer un réseau privé Tor, l'utiliser 
414) quelques temps, et verifier qu'au moins quelques parties fonctionnent. Ce
415) projet nécessite de concevoir un plan pour effectuer les tests système
416) du réseau privé Tor, avant de commencer à coder. Les tests typiques
417) vont de la simple requête dans le réseau privé à la
418) manipulation des messages echangés et 
419) voir si les nœuds peuvent correctement prendre en compte les messages corrompus.
420) L'étudiant devrait pouvoir obtenir une bonne comprehension de 
421) comment Tor fonctionne et quels problèmes ou bugs peuvent survenir pour concevoir de bons
422) bancs de tests. Comprendre le code Tor et la documentation existante est
423) vital. Si PuppeTor est utilisé, l'étudiant devrait aussi être en mesure de comprendre
424) et éventuellement étendre une application Java existante. Ce projet est en partie
425) de la conception et en partie du codage.
426) </li>
427)   	 
428) <li>
429) <b>Donner vie à moniTor</b>
430) <br />
431) Implémenter un outil <a href="http://www.ss64.com/bash/top.html">comme top</a>
432) d'administration pour les relais Tor. Le but de cet outil serait de
433) superviser un relais Tor local via son port de control et inclure des informations
434) système utiles de la machine. Lorsque l'outil tourne, il 
435) devrait dynamiquement se mettre à jour comme top le faire pour les processus Linux.
436) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">Ce
437) post sur or-dev</a> devrait être un point d'entré. L'étudiant devrait être familier
438) ou prêt à apprendre l'administration d'un relais Tor et sa configuration
439) à travers son port de control. Du fait qu'un prototype exist en Python
440) quelques connaissances en Python serait interessantes. Ce projet porte sur
441) l'identification des nécessités pour un tel outil et sur la conception d'une interface ;
442) et d'un autre coté nécessite beaucoup de codage.
443) </li>
444)   	 
445) <li>
446) <b>Amélioration du scanneur des sorties Tor</b>
447) <br />
448) Priorité : <i>élevée</i>
449) <br />
450) Niveau d'effort : <i>élevé</i>
451) <br />
452) Mentors supposés : <i>Mike Perry</i>
453)   	 
454) <br />
455) Le scanner des nœuds de sortie Tor 'SoaT', partie du <a
456)   	 href="https://www.torproject.org/svn/torflow/">projet Torflow</a>, est
457)   	 pour l'instant écrit dans un perl plutôt bancal et s'appuie sur des MD5sums de
458)   	 documents entier dans le but de savoir si un nœud de sortie modifie des contenusin order to determine if exit nodes are modifying
459)   	 content. The problem with this is threefold: 1) Perl sucks at life.
460)   	 2) The scanner can't verify pages that are dynamic, and attackers can
461)   	 focus malicious content injection on only those dynamic pages. 3)
462)   	 Pages change after a while (or based on GeoIP) and begin generating
463)   	 false positives.
464)   	 <br />
465)   	 Ideally, soat.pl would be reimplemented in a sane language with a
466)   	 robust html parser library (since the rest of Torflow is in Python,
467)   	 that would be nice, but not required), and calculate signatures only for
468)   	 tags and content likely to be targeted by a malicious attacker (script
469)   	 tags, object links, images). It should also be robust in the face of
470)   	 changes to content outside of Tor, and ultimately even GeoIP localized
471)   	 content.
472)   	 <br />
473)   	 This scanner would likely be run by the directory authorities and
474)   	 report its results to the control port via the AuthDirBadExit config
475)   	 setting.
476)   	 <br />
477)   	 </li>
478)   	 <li>
479)   	 <b>Tor Node Scanner Improvements</b>
480)   	 <br />
481)   	 Priority: <i>High</i>
482)   	 <br />
483)   	 Effort Level: <i>Medium-High</i>
484)   	 <br />
485)   	 Likely Mentors: <i>Mike Perry</i>
486)   	 <br />
487)   	 Similar to the exit scanner (or perhaps even during exit scanning),
488)   	 statistics can be gathered about the reliability of nodes. Nodes that
489)   	 fail a certain percentage of their circuits should not be used for
490)   	 Guard status, and perhaps should have their reported bandwidth
491)   	 penalized by some ratio as well, or just get marked as Invalid. In
492)   	 addition, nodes that exhibit a very low average stream capacity but
493)   	 advertise a very high node bandwidth can also be marked as Invalid.
494)   	 Much of this statistics gathering is already done, it just needs to be
495)   	 transformed into something that can be reported to the Directory
496)   	 Authorities to blacklist/penalize nodes in such a way that clients
497)   	 will listen.
498)   	 <br />
499)   	 In addition, these same statistics can be gathered about the traffic
500)   	 through a node. Events can be added to the <a
501)   	 href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control
502)   	 Protocol</a> to
503)   	 report if a circuit extend through the node succeeds or fails, and
504)   	 passive statistics can be gathered on both bandwidth and reliability
505)   	 of other nodes via a node-based monitor using these events. Such a
506)   	 scanner which would also report information on oddly-behaving nodes to
507)   	 the Directory Authorities, but a communication channel for this
508)   	 currently does not exist and would need to be developed as well.
509)   	 </li>
510)   	 <li>
511)   	 <b>Tor path selection improvements</b>
512)   	 <br />
513)   	 Priority: <i>High</i>
514)   	 <br />
515)   	 Effort Level: <i>Low-Medium</i>
516)   	 <br />
517)   	 Likely Mentors: <i>Mike Perry</i>
518)   	 <br />
519)   	 Some simple improvements can be made to Tor's path selection to vastly
520)   	 improve Tor speed. For instance, some of the (unofficial) <a
521)   	 href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
522)   	 Performance Recommendations</a> on the wiki are to increase the number of
523)   	 guards and decrease the CircuitBuildTimeout. Ideally, the client would
524)   	 learn these values by gathering statistics on circuit construction
525)   	 time (and/or using values gained from Torflow), and set the timeouts
526)   	 low enough such that some high percentile (75%, 90%, 1-stddev?) of
527)   	 circuits succeed, yet extremely slow nodes are avoided. This would
528)   	 involve some statistics gathering+basic research, and some changes to
529)   	 Tor path selection code.
530)   	 <br />
531)   	 
532)   	 In addition, to improve path security, some elements from the <a
533)   	 href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
534)   	 Hop Paths proposal</a> could be done as part of this (since it will
535)   	 likely touch the same code anyways), regardless of the adoption of
536)   	 thatproposal. In particular, clients probably should avoid guards thatseem to
537)   	 fail an excessive percentage of their circuits through them, and non-bridged
538)   	 clients should issue a warn if they are only able toconnect to a limited set
539)   	 of guard nodes.
540)   	 
541)   	 </li>
542)   	 <li>
543)   	 <b>Torbutton improvements</b>
544)   	 <br />
545)   	 Priority: <i>Low</i>
546)   	 <br />
547)   	 Effort Level: <i>Medium-High</i>
548)   	 <br />
549)   	 Likely Mentors: <i>Mike Perry</i>
550)   	 <br/>
551)   	 
552)   	 Torbutton has a number of improvements that can be made in the post-1.2
553)   	 timeframe. Most of these are documented as feature requests in the <a
554)   	 href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5">Torbutton
555)   	 flyspray section</a>. Good examples include: stripping off node.exit on http
556)   	 headers, more fine-grained control over formfill blocking, improved referrer
557)   	 spoofing based on the domain of the site (a-la refspoof extension), tighter
558)   	 integration with Vidalia for reporting Tor status, a New Identity button with
559)   	 Tor integration and multiple identity management, and anything else you might
560)   	 think of.
561)   	 
562)   	 <br />
563)   	 
564)   	 This work would be independent coding in Javascript and the fun world of <a
565)   	 href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
566)   	 with not too much involvement in the Tor internals.
567)   	 
568)   	 </li>
569)   	 <li>
570)   	 <b>Help track the overall Tor Network status</b>
571)   	 Torstatus. Set up an automated system for tracking network health
572)   	 over time, graphing it, etc. Better metrics for assessing network
573)   	 health and growth. Make it short and simple. Unbloated and easy to audit.
574)   	 </li>
575)   	 
576)   	 <li>vidalia and upnp</li>
577)   	 <li>nymble</li>
578)   	 
579)   	 <li>
580)   	 <b>Porting Polipo to Windows</b>
581)   	 <br />
582)   	 Help port <a
583)   	 href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
584)   	 Windows. 1) handle spaces in path names and understand the filesystem
585)   	 namespace &mdash; namespace meaning where application data, personal data,
586)   	 and program data typically reside in various versions of Windows. 2) the
587)   	 ability to handle ipv6 communications. 3) the ability to asynchronously
588)   	 query name servers, find the system nameservers, and manage netbios
589)   	 and dns queries. 4) use native regex capabilities of Windows, rather
590)   	 than using 3rd party GNU regex libraries. 5) manage events and buffers
591)   	 natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
592)   	 Windows it's whatever the config specifies). 6) some sort of GUI config
593)   	 and reporting tool, bonus if it has a systray icon with right clickable
594)   	 menu options. Double bonus if it's cross-platform compatible.
595)   	 </li>
596)   	 
597)   	 <li>
598)   	 <b>Make our diagrams beautiful and automated</b>
599)   	 <br />
600)   	 a way to generate the website diagrams from source, so we can translate
601)   	 them as utf-8 text rather than with gimp. (svg? or imagemagick?)
602)   	 integrate this with a wml file so translations are easy and images are
603)   	 generated in multiple languages at web publish
604)   	 </li>
605)   	 
606)   	 <li>
607)   	 <b>Improve the LiveCD offerings for the Tor community</b>
608)   	 <br />
609)   	 How can we make the <a
610)   	 href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
611)   	 easier to maintain, improve, and document?</li>
612)   	 <li>We need a distributed testing framework. We have unit tests,
613)   	 but it would be great to have a script that starts up a Tor network, uses
614)   	 it for a while, and verifies that at least parts of it are working.</li>
615)   	 
616)   	 <li>
617)   	 <b>Bring up new ideas!</b>
618)   	 <br />
619)   	 Don't like any of these? Look at the <a
620)   	 href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
621)   	 roadmap</a> for more ideas.<br /><br />
622)   	 Don't see your idea here? We probably need it anyway! Contact
623)   	 us and find out.</li>
624)   	 </ol>

625) <h2><a class="anchor" href="#Coding">Conception et Code</a></h2>
626) <ol>

627) <li>Les serveurs de Tor ne fonctionnent pas parfaitement sur Windows XP. Sur
628) Windows, Tor utilise l'appel système standard <tt>select()</tt>, 
629) qui utilise l'espace non paginé dans le pool. Ce qui implique 
630) que les serveurs de taille moyenne vont vider l'espace non paginé, <a

631) href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">provocant 

632) l'instabilité et le plantage du système</a>. Nous devrions probablement utiliser des E/S recouvrables 
633) à la place. Une solution pourrait-être d'apprendre à la <a
634) href="http://www.monkey.org/~provos/libevent/">libevent</a> comment utiliser 
635) les E/S recouvrables à la place de select() sous Windows, et alors d'adapter Tor à 

636) la nouvelle interface libevent.</li> Christian King à 
637) <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">bien
638) démarré</a> sur ce point l'été dernier.</li>
639) <li>Comment pouvons nous faire en sorte que <a
640) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
641) soit plus simple à maintenir, étendre, et à documenter ?</li>

642) <li>Notre interface graphique préférée pour Tor, nommée
643) <a href="http://vidalia-project.net/">Vidalia</a>, nécessite toutes sortes 
644) de dévelopments.</li>
645) <li>Nous avons besoin maintenant de commencer l'élaboration de notre <a href="<page
646) documentation>#DesignDoc">conception de résistance au blocage</a>. Ceci implique 
647) une refonte de la conception, une modification de différents aspects de Tor, une adaptation de
648) <a href="http://vidalia-project.net/">Vidalia</a> pour qu'il supporte les nouvelles
649) fonctionnalités, et planifier le deploiement.</li>
650) <li>Nous avons besoin d'un ensemble d'outils flexibles de simulation pour étudier de bout en bout
651) les trafics de confirmation d'attaque. Beaucoups de chercheurs ont conçu des simulateurs ad hoc
652) pour confirmer leurs intuitions comme quoi soit l'attaque marche 
653) vraiment bien ou que les défenses fonctionnent. Pouvons nous construire un simulateur
654) qui soit clairement documenté et suffisament ouvert pour que tout le monde sache qu'il

655) donne une réponse raisonnable ? Ceci stimulera un grand nombre de nouvelles recherches.

656) Voyez l'entrée <a href="#Research">suivante</a> sur les confirmations d'attaque pour les 
657) détails sur le coté recherche de cette tâche &mdash; qui sait, quand ceci sera 
658) fait peut-être pouvez aider en écrivant un papier ou deux.</li>
659) <li>Nous avons besoin d'un banc de test distribué. Nous avons des unités de tests,
660) mais il serait sympa d'avoir un script qui lance un réseau Tor, 
661) l'utilise quelque temps, et vérifie que, au moins, quelques aspects fonctionnent.</li>
662) <li>Aidez Mike Perry sur sa bibliothèque <a

663) href="https://www.torproject.org/svn/torflow/">TorFlow</a> (<a href="https://www.torproject.org/svn/torflow/TODO">TODO</a>):

664) c'est une bibliothèque python qui utilise le <a

665) href="https://www.torproject.org/svn/torctl/doc/howto.txt">protocole du contrôleur Tor

666) </a> pour apprendre à Tor à construire des circuits de différentes manières,
667) et ensuite mesure les performances et essaye de détecter les anomalies.</li>
668) <li>Tor 0.1.1.x inclut le support d'accélérateurs matériels de chiffrage 

669) via OpenSSL. Cependant, personne ne l'a jamais testé. Est-ce que quelqu'un voudrait se procurer 

670) une carte et nous dire ce qu'il en est ?</li>

671) <li>Faire une analyse de sureté de Tor avec <a

672) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer 
673) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons faire. La célébrité pour celui-lle 

674) grâce à qui une nouvelle version pourra voir le jour !</li>

675) <li>Tor utilise TCP pour le transport et TLS pour le chiffrage 
676) des liens. C'est simple et efficace, mais cela implique que toutes les unités (cellules) 
677) d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et 
678) cela signifie que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons dressé une <a

679) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP"> liste 

680) de raisons pour lesquelles nous n'avons pas bifurqué vers le transport par UDP</a>, mais ce serait 
681) bien de voir cette liste se raccourcir. Nous avons aussi proposé <a 
682) href="<svnsandbox>tor/doc/100-tor-spec-udp.txt">une spécification pour Tor et 
683) UDP</a> &mdash; lisez-la et faites-nous part de vos remarques et critiques, s'il-vous-plaît.</li>
684) <li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les serveurs de sorties 
685) et les adresses finales. Si IPV6 vous tient à cœur, partir de là est sans doute 
686) un premier pas.</li>

687) <li>Quelque chose vous déplait ? Regardez la <a

688) href="<svnsandbox>doc/design-paper/roadmap-future.pdf">planification du développement

689) de Tor</a> pour plus d'idées.</li>

690) <li>Vous ne voyez pas vos idées ici ? Nous en avons peut-être besoin ! Contactez

691) nous et aidez.</li>

692) </ol>
693) 
694) <a id="Research"></a>
695) <h2><a class="anchor" href="#Research">Recherche</a></h2>
696) <ol>

697) <li>"L'attaque par empreinte de sites": faire une liste de quelques 
698) centaines de sites populaires, en télécharger les pages, et faire des 
699) "signatures" pour chaque site. Ensuite, observer le trafic d'un client Tor. 
700) L'analyse de ses réceptions de données donne rapidement une idée 
701) des sites qu'il visite. Premièrement, quelle est l'efficacité 

702) de cette attaque sur le code actuellement utilisé dans Tor ? Ensuite, tester 

703) les défenses possibles : par exemple, changer la taille des cellules de Tor de 512 
704) octets à 1024, utiliser des techniques de remplissage comme <a
705) href="http://freehaven.net/anonbib/#timing-fc2004">le lâcher défensif</a>, 
706) ou ajouter des délais de trafic. Quel impact ces stratégies de défense ont-elles, 
707) et, dans les cas où elles sont efficaces en défense, quel impact ont-elles 

708) en terme de perte d'utilisabilité de Tor (à quantifier) ?</li>

709) <li>"L'attaque par corrélation des trafics aux extrémités": 
710) par l'observation des trafics de Alice et Bob, il est possible de <a
711) href="http://freehaven.net/anonbib/#danezis:pet2004">comparer 
712) les signatures des trafics et d'en déduire qu'il s'agit du même 
713) flux</a>. Jusqu'ici, Tor considère ce type d'attaque comme intrinsèque 

714) et donc inévitable. Tout d'abord, est-ce réellement vrai ? Quelle 

715) quantité de trafic - et avec quelle distribution - est-elle nécessaire pour que l'adversaire 

716) soit certain d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un trafic faible) 
717) pour ralentir cette attaque ? Est-ce que certains types de remplissage ou de modelage de trafic
718) fonctionnent mieux que d'autres ?</li>

719) <li>"L'attaque par zones de routage" : la littérature spécialisée considère 
720) le plus souvent que le chemin réseau entre Alice et son noeud d'entrée (et entre le noeud de sortie 
721) et Bob) comme un lien unique dans un graphe. En pratique, 
722) cependant, le chemin passe par de nombreux systèmes autonomes (Autonomous Systems : ASes), et <a
723) href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas inhabituel 
724) de retrouver le même AS sur les chemins d'entrée et de sortie</a>.
725) Malheureusement, pour prévoir précisément si le chemin "Alice, entrée, 
726) sortie, Bob" sera dangereux, nous devrions télécharger une zone de routage 
727) internet complète et faire dessus des calculs lourds. Est-ce qu'il existe 

728) des approximations utilisables, comme par exemple d'ignorer les adresses IP d'un réseau /8 ?</li>

729) <li>D'autres questions de recherche concernant la diversité géographique considèrent 
730) la différence entre choisir un circuit efficace et en choisir un aléatoire.
731) Lisez l' <a
732) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">argumentation
733) </a> de Stephen Rollyson sur comment eviter les nœuds lents sans trop impacter
734) l'anonymat. Cet axe de raisonnement nécessite davantage de travail et de 
735) réflexion, mais semble très prometteur.</li>
736) <li>Tor ne fonctionne pas très bien lorsque les serveurs ont des bandes passantes 
737) asymétriques (par exemple câble ou DSL). Comme Tor a des connexions TCP séparées entre 
738) chaque saut, si les octets arrivent correctement mais que les octets sortants 
739) sont bloqués sur place, les mécanismes de refoulement de TCP 
740) ne retransmettent pas vraiment cette information aux flux entrants.
741) Peut-être Tor devrait-il détecter s'il perd beaucoup de paquets sortants, 

742) et limiter la vitesse du flux entrant pour réguler cela lui-même ? Je peux concevoir 

743) un schéma de type augmentation-descente dans lequel on choisit un débit "sûr", 
744) que l'on augmente jusqu'à perdre des paquets, puis qui redescend, puis qui réaugmente. Nous 
745) avons besoin de quelq'un-e de fort-e en réseau pour simuler ce fonctionnement et aider à concevoir 
746) des solutions. De manière générale, l'évaluation des pertes de performances 
747) d'un tel système pourrait peut-être - dans le cas où elles sont grandes - 
748) servir de motivation pour reconsidérer la question du transport UDP.
749) <li>Un sujet lié est le contrôle de congestion : notre système 

750) actuel est-il suffisant pour un usage intensif ? Peut-être 

751) devrions-nous expérimenter des fenêtres de taille variable 

752) plutôt qu'à taille fixe ? C'est apparu assez efficace pour cette <a

753) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">expérience 
754) sur ssh</a>. Nous aurons à faire des mesures et des réglages, et peut-être 
755) une révision de Tor si les résulats sont bons.</li>
756) <li>Pour permettre à des dissident-e-s de se connecter sans être bloqué-e-s 
757) par les pare-feu de leur pays, nous avons besoin de dizaines de milliers de 
758) relais et pas seulement de quelques centaines. Nous pourrions imaginer un client Tor graphique qui 

759) aurait un bouton "Tor pour la liberté" pour activer l'ouverture d'un port et le relais 

760) de quelques KB/s de trafic pour le réseau Tor. (Quelques KB/s ne devraient pas être trop 
761) pénibles et il y a peu de risque d'abus puisqu'il ne s'agirait pas de noeuds de 
762) sortie.) Mais comment distribuer la liste de ces clients volontaires aux 
763) bons dissidents de manière automatique, tout en ne permettant pas aux 

764) pare-feux au niveau national de l'intercepter et de lister ces clients ? Probablement, il faut faire 

765) intervenir la confiance, au niveau humain. Voir notre <a href="<page documentation>#DesignDoc">document 
766) préliminaire sur la résistance au blocage</a> et notre 
767) <a

768) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">entrée 

769) dans la FAQ</a> à ce sujet, puis lire <a 
770) href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">la section 
771) sur la résistance à la censure de anonbib</a>.</li>
772) <li>Les circuits Tor sont construits saut par saut, donc en théorie nous pouvons 
773) faire sortir des flux au second saut, au 
774) troisième, etc. Cela paraît bien car cassant l'ensemble des flux sortants 
775) qu'un serveur peut voir. Mais si nous voulons que chaque flux soit sûr, 
776) le chemin "le plus court" devrait comporter au moins 3 sauts dans notre logique actuelle, et 
777) les sorties suivantes seraient encore plus lointaines. Nous devons évaluer ce rapport 
778) performance/sûreté.</li>
779) <li>Il n'est pas difficile de provoquer un DoS sur les serveurs et les serveurs de répertoires Tor. Est-ce 

780) que les puzzles de clients sont la bonne réponse ? Existe-t-il d'autres approches réalisables ? Il y a un bonus 

781) si elles sont rétro-compatibles avec le protocol actuel de Tor.</li>

782) </ol>
783) 

784) <a href="<page contact>">Contactez-nous</a> si vous avez avancé sur 

785) ces points !

786) 
787)   </div><!-- #main -->
788)