tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 13966

3) # Last-Translator: 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>Trois 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 ami-e-s ! Faites-leur héberger des serveurs. Faites-leur utiliser les services 

15) cachés. Encouragez-les à informer leurs propres ami-e-s.</li>
16) <li> Nous recherchons des fonds et des mécènes. 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>. De même, si vous connaissez des 
19)   entreprises, des ONGs, 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 méthodes efficaces d'interception des requêtes DNS, pour qu'elles ne laissent pas filtrer 
27) d'informations à un observateur local pendant que nous tentons d'être anonymes. (Ce qui 
28) arrive lorsque l'application fait sa résolution DNS avant de passer par 
29) le proxy SOCKS.)</li>

30) <li>Élements tsocks/dsocks :

31) <ul>

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

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

43) </ul>

44) </li>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

688) nous et aidez.</li>

689) </ol>
690) 
691) <a id="Research"></a>
692) <h2><a class="anchor" href="#Research">Recherche</a></h2>
693) <ol>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

779) </ol>
780) 

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

782) ces points !

783) 
784)   </div><!-- #main -->
785)