tor-webwml.git

1) 
2) 

3) 
4) 
5) 
6) 
7) ## translation metadata
8) # Revision: $Revision$
9) # Translation-Priority: 4-optional
10) #include "head.wmi" TITLE="Tor: Volunteer" CHARSET="UTF-8"

11) <div class="main-column">
12) 

13) 

14) <!-- PUT CONTENT AFTER THIS TAG -->

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

16) <ol>

17) <li>Pensez à <a href="<page docs/tor-doc-relay>">héberger un noeud</a> pour
18) aider à la croissance du réseau Tor.</li>
19) <li>Informez vos amis ! Faites-leur héberger des serveurs. Faites-leur utiliser
20) les services

21) cachés. Encouragez-les à informer leurs propres amis.</li>

22) <li>Si vous adhérez aux objectifs de Tor, prenez s'il-vous-plaît un moment <a
23) href="<page donate>">pour faire un don et aider le développement futur de
24) Tor</a>. Nous recherchons également plus de sponsors &mdash; si vous
25) connaissez des entreprises, des ONG, ou d'autres organisations qui veulent
26) un anonymat,une protection de la vie privée, sécurité dans leurs
27) communications, parlez-leur de nous.</li>
28) <li>Nous sommes recherchons plus <a href = "<page torusers>"> de bons exemples
29) d'utilisateurs de Tor et des cas d'utilisation Tor</a>. Si vous utilisez Tor
30) dans un scénario ou le but, non encore décrits sur cette page, et vous êtes
31) à l'aise pour le partager avec nous,nous aimerions que vous nous en parliez.</li>

32) </ol>
33) 

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

36) 

37) <a id="Documentation"></a>
38) <h2><a class="anchor" href="#Documentation">Documentation</a></h2>

39) <ol>

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

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

70) </ol>
71) 

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

74) 

75) <p>

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

85) </p>

86) 

87) <ol>

88) 

89) <li>

90) <b>Tor Browser Bundle for Linux/Mac OS X</b> <br /> Priority: <i>High</i>
91) <br /> Effort Level: <i>High</i> <br /> Skill Level: <i>Medium</i> <br />
92) Likely Mentors: <i>Steven, Erinn, Jacob, Andrew</i> <br /> The Tor Browser
93) Bundle incorporates Tor, Firefox, Polipo, and the Vidalia user interface
94) (and optionally the <a href="http://pidgin.im/">Pidgin</a> Instant Messaging
95) client). Components are pre-configured to operate in a secure way, and it
96) has very few dependencies on the installed operating system. It has
97) therefore become one of the most easy to use, and popular, ways to use Tor
98) on Windows.  <br /> However, there is currently no released package for
99) Linux and Mac OS X, so this project would be to implement Tor Browser Bundle
100) for OS X and continue work on the Tor Browser Bundle for Linux. This will
101) involve modifications to Vidalia (C++), possibly Firefox (C) then creating
102) and testing the launcher on a range of operating system versions and
103) configurations to verify portability.  Some work on this was completed as
104) part of the Google Summer of Code 2009. Another part of this project is to
105) identify all of the traces left behind by using a Tor Browser Bundle on Mac
106) OS X or Linux.  Developing ways to stop, counter, or remove these traces is
107) a final step.  <br /> Students should be familiar with application
108) development on one or preferably both of Linux and Mac OS X, and be
109) comfortable with C/C++ and shell scripting.  <br /> Part of this project
110) could be usability testing of Tor Browser Bundle, ideally amongst our target
111) demographic.  That would help a lot in knowing what needs to be done in
112) terms of bug fixes or new features. We get this informally at the moment,
113) but a more structured process would be better.

114) </li>
115) 
116) <li>

117) <b>Aider à mesurer l'état général du réseau Tor</b> <br /> Priorité:
118) <i>Moyenne à Haute</i> <br /> Effort à fournir: <i>Moyen</i> <br />
119) Compétences requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Karsten,
120) Roger</i> <br /> Il serait bon de mettre en place un système automatisé pour
121) rendre compte de la santé du réseau au cours du temps, avec des graphiques,
122) etc... Une partie de ce projet consisterait à trouver un système de mesure
123) adéquat pour évaluer la santé du réseau et sa croissance. Est-ce-que sa
124) durée de fonctionnement augmente ? Combien de relais sont en cours de
125) qualification pour adopter l'état Guard ce mois-ci comparé au mois précédent
126) ? Comment est le turnover entre les nouveaux relais qui apparaissent et ceux
127) qui s'éteignent ? Régulièrement, des personnes collectes de brèves photos
128) d'état mais il est plus intéressant de le faire sur une longue période.  <br
129) ./> Les données peuvent être collectées depuis les scanners du réseau Tor
130) dans <a
131) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>,
132) depuis les descripteurs de serveurs publiés par chaque relais et ailleurs
133) également. Les résultats sur le long terme pourraient être présentés sur
134) l'une des pages web de <a href="https://torstatus.blutmagie.de/">Tor
135) Status</a> ou éventuellement ailleurs. En parlant des pages Tor Status,
136) prenez le temps de consulter <a
137) href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">la
138) "whish-list" Tor Status</a> de Roger.

139) </li>
140) 
141) <li>

142) <b>Improving Tor's ability to resist censorship</b> <br /> Priority:
143) <i>Medium to High</i> <br /> Effort Level: <i>Medium</i> <br /> Skill Level:
144) <i>High</i> <br /> Likely Mentors: <i>Nick, Roger, Steven</i> <br /> The Tor
145) 0.2.1.x series makes <a

146) href="<svnprojects>design-paper/blocking.html">significant improvements</a>

147) in resisting national and organizational censorship.  But Tor still needs
148) better mechanisms for some parts of its anti-censorship design.  For
149) example, current Tors can only listen on a single address/port combination
150) at a time.  There's <a
151) href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">a proposal to
152) address this limitation</a> and allow clients to connect to any given Tor on
153) multiple addresses and ports, but it needs more work.  <br /> Another area
154) that needs work is our <a
155) href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
156) service. See e.g. <a
157) href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">Roger's or-dev
158) post</a> from December for details &mdash; lots of design work remains.  <br
159) /> This project involves a lot of research and design. One of the big
160) challenges will be identifying and crafting approaches that can still resist
161) an adversary even after the adversary knows the design, and then trading off
162) censorship resistance with usability and robustness.

163) </li>

164) 
165) 

166) 
167) <!--<li>
168) 
169) <b>Tuneup Tor!</b>
170) <br />
171) Priority: <i>Medium to High</i>
172) <br />
173) Effort Level: <i>Medium to High</i>
174) <br />
175) Skill Level: <i>High</i>
176) <br />
177) Likely Mentors: <i>Nick, Roger, Mike, Karsten</i>
178) <br />
179) Right now, Tor relays measure and report their own bandwidth, and Tor
180) clients choose which relays to use in part based on that bandwidth.
181) This approach is vulnerable to
182) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
183) relays lie about their bandwidth</a>;
184) to address this, Tor currently caps the maximum bandwidth
185) it's willing to believe any relay provides.  This is a limited fix, and
186) a waste of bandwidth capacity to boot.  Instead,
187) Tor should possibly measure bandwidth in a more distributed way, perhaps
188) as described in the
189) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
190) Tor"</a> paper
191) by Snader and Borisov. One could use current testing code to
192) double-check this paper's findings and verify the extent to which they
193) dovetail with Tor as deployed in the wild, and determine good ways to
194) incorporate them into their suggestions Tor network without adding too
195) much communications overhead between relays and directory
196) authorities.
197) </li>-->

198) <li>

199) <b>Améliorer Polipo sous Windows</b> <br /> Priorité: <i>Moyenne à Haute</i>
200) <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences requises:
201) <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Chris</i> <br />Il faut nous
202) aider à porter <a
203) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> sous
204) Windows. Quelques exemples de sujets à retenir:
205) <ol><li> la possibilité d'interroger de manière asynchrone les serveurs de noms,
206) trouver les serveurs de noms utilisés par le système et gérer les requêtes
207) netbios et dns.</li>
208) <li> gérer nativement les tampons et les évènement (i.e. sous les OS de type
209) Unix, Polipo occupe 25% de la ram, sous Windows, c'est selon la
210) configuration).</li>
211) <li> un outil graphique de configuration et de rapport, avec en bonus, une icône
212) de barre système avec un menu d'option par clic-droit. Double-bonus si c'est
213) multiplateforme.</li>
214) <li> permettre au logiciel d'utiliser le registre Windows et de gérer
215) correctement les emplacements de répertoire Windows tels que "C:\Program
216) Files\Polipo"</li>
217) </ol>

218) </li>

219) 

220) <li>

221) <b>Tor Controller Status Event Interface for Vidalia</b> <br /> Priority:
222) <i>Medium</i> <br /> Effort Level: <i>Medium</i> <br /> Skill Level: <i>Low
223) to Medium</i> <br /> Likely Mentors: <i>Matt</i> <br /> There are a number
224) of status changes inside Tor of which the user may need to be informed. For
225) example, if the user is trying to set up his Tor as a relay and Tor decides
226) that its ports are not reachable from outside the user's network, we should
227) alert the user. Currently, all the user gets is a couple log messages in
228) Vidalia's 'message log' window, which they likely never see since they don't
229) receive a notification that something has gone wrong. Even if the user does
230) actually look at the message log, most of the messages make little sense to
231) the novice user.  <br /> Tor has the ability to inform Vidalia of many such
232) status changes, and we recently implemented support for a couple of these
233) events. Still, there are many more status events the user should be informed
234) of and we need a better UI for actually displaying them to the user.  <br />
235) The goal of this project then is to design and implement a UI for displaying
236) Tor status events to the user. For example, we might put a little badge on
237) Vidalia's tray icon that alerts the user to new status events they should
238) look at. Double-clicking the icon could bring up a dialog that summarizes
239) recent status events in simple terms and maybe suggests a remedy for any
240) negative events if they can be corrected by the user. Of course, this is
241) just an example and one is free to suggest another approach.  <br /> A
242) person undertaking this project should have good UI design and layout and
243) some C++ development experience. Previous experience with Qt and Qt's
244) Designer will be very helpful, but are not required. Some English writing
245) ability will also be useful, since this project will likely involve writing
246) small amounts of help documentation that should be understandable by
247) non-technical users. Bonus points for some graphic design/Photoshop fu,
248) since we might want/need some shiny new icons too.

249) </li>

250) 

251) <li>

252) <b>Improve our unit testing process</b> <br /> Priority: <i>Medium</i> <br
253) /> Effort Level: <i>Medium</i> <br /> Skill Level: <i>Medium</i> <br />
254) Likely Mentors: <i>Nick, Erinn</i> <br /> Tor needs to be far more
255) tested. This is a multi-part effort. To start with, our unit test coverage
256) should rise substantially, especially in the areas outside the utility
257) functions. This will require significant refactoring of some parts of Tor,
258) in order to dissociate as much logic as possible from globals.  <br />
259) Additionally, we need to automate our performance testing. We've got
260) buildbot to automate our regular integration and compile testing already
261) (though we need somebody to set it up on Windows), but we need to get our
262) network simulation tests (as built in <a
263) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
264) updated for more recent versions of Tor, and designed to launch a test
265) network either on a single machine, or across several, so we can test
266) changes in performance on machines in different roles automatically.

267) </li>

268) 

269) <li>

270) <b>Help with independent Tor client implementations</b> <br /> Priority:
271) <i>Medium</i> <br /> Effort Level: <i>High</i> <br /> Skill Level: <i>Medium
272) to High</i> <br /> Likely Mentors: <i>Bruce, Nathan</i> <br /> Others are
273) currently working on Tor clients for Java, Android, and Maemo environments.
274) The first step is to get a handle on the current state of the project in
275) which you are interested in helping; <a
276) href="http://github.com/brl/JTor">Tor for Java</a>, <a
277) href="https://svn.torproject.org/svn/projects/android/trunk/">Android/Orbot</a>
278) , or Tor for Maemo. Check out the repository and familiarlize yourself with
279) the source code.  Further, support for requesting or even providing Tor
280) hidden services would be neat, but not required.  <br /> A prospective
281) developer should be able to understand and write new Java code, including a
282) Java cryptography API. Being able to read C code would be helpful, too. One
283) should be willing to read the existing documentation, implement code based
284) on it, and refine the documentation when things are underdocumented. This
285) project is mostly about coding and to a small degree about design.

286) </li>

287) 
288) 

289) 
290) 

291) 
292) <!--<li>
293) 
294) <b>New Torbutton Features</b>
295) <br />
296) Priority: <i>Medium</i>
297) <br />
298) Effort Level: <i>High</i>
299) <br />
300) Skill Level: <i>High</i>
301) <br />
302) Likely Mentors: <i>Mike</i>
303) <br/>
304) There are several <a
305) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">good
306) feature requests</a> on the Torbutton Flyspray section. In particular, <a
307) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">Integrating
308) 'New Identity' with Vidalia</a>,
309) <a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">ways of
310) managing multiple cookie jars/identities</a>, <a
311) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">preserving
312) specific cookies</a> when cookies are cleared,
313) <a
314) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">better
315) referrer spoofing</a>, <a
316) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">correct
317) Tor status reporting</a>, and <a
318) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">"tor://"
319) and "tors://" urls</a> are all interesting
320) features that could be added.
321) <br />
322) This work would be independent coding in Javascript and the fun world of <a
323) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
324) with not too much involvement in the Tor internals.
325) </li>-->

326) <!-- <li>
327) 
328) <b>New Thandy Features</b>
329) <br />
330) Priority: <i>Medium</i>
331) <br />
332) Effort Level: <i>Medium</i>
333) <br />
334) Skill Level: <i>Medium to High</i>
335) <br />
336) Likely Mentors: <i>Martin</i>
337) <br />
338) Additional capabilities are needed for assisted updates of all the Tor
339) related software for Windows and other operating systems. Some of the
340) features to consider include:

341) <ol>

342) <li> Integration of the <a
343) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
344) Python library</a>
345) for authenticated HTTPS downloads.</li>
346) <li> Adding a level of indirection
347) between the timestamp signatures and the package files included in an
348) update. See the "Thandy attacks / suggestions" thread on or-dev.</li>
349) <li> Support locale specific installation and configuration of assisted
350) updates based on preference, host, or user account language settings.
351) Familiarity with Windows codepages, unicode, and other character sets
352) is helpful in addition to general win32 and posix API experience and
353) Python proficiency.</li>

354) </ol>

355) </li> -->

356) <li>

357) <b>Simulateur pour les connexion Internet lentes</b> <br /> Priorité:
358) <i>Moyenne</i> <br /> Effort à fournir: <i>Moyen</i> <br /> Compétences
359) requises: <i>Moyennes</i> <br /> Tuteurs potentiels: <i>Steven</i> <br /> De
360) nombreux utilisateurs de Tor disposent de connexions à Internet de qualité
361) médiocre avec une faible bande passante, beaucoup de latence et de
362) nombreuses pertes ou tris de paquets. A l'usage, Tor ne se comporte pas très
363) bien dans ces conditions mais il est difficile d'améliorer la situation sans
364) pouvoir reproduire le problème en laboratoire.  <br /> Ce projet consiste à
365) élaborer un environnement de simulation d'une connection médiocre de manière
366) à ce que l'effet sur Tor puisse être mesuré. D'autres composants à mettre en
367) place pourraient être des utilitaires de test des propriétés des connexions
368) disponibles pour mesurer l'effet sur les performance des modifications
369) apportées à Tor.  <br /> Le responsable du projet peut utiliser les outils
370) de son choix mais dummynet (pour FreeBSD) et nisnet (pour Linux) sont deux
371) composants sur lesquels le projet peut être construit. Les étudiants
372) devraient avoir de l'expérience en programmation réseau et en TCP/IP, de
373) préférence compétents en C et en langage de script.

374) </li>

375) 

376) <li>

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

398) </li>

399) 

400) <li>

401) <b>Torbutton equivalent for Thunderbird</b> <br /> Priority: <i>Medium</i>
402) <br /> Effort Level: <i>High</i> <br /> Skill Level: <i>High</i> <br />
403) Likely Mentors: <i>Mike</i> <br /> We're hearing from an increasing number
404) of users that they want to use Thunderbird with Tor. However, there are
405) plenty of application-level concerns, for example, by default Thunderbird
406) will put your hostname in the outgoing mail that it sends. At some point we
407) should start a new push to build a Thunderbird extension similar to
408) Torbutton.

409) </li>

410) 
411) 

412) 
413) <!--<li>
414) 
415) <b>Intermediate Level Network Device Driver</b>
416) <br />
417) Priority: <i>Low</i>
418) <br />
419) Effort Level: <i>High</i>
420) <br />
421) Skill Level: <i>High</i>
422) <br />
423) Likely Mentors: <i>Martin</i>
424) <br />
425) The WinPCAP device driver used by Tor VM for bridged networking does
426) not support a number of wireless and non-Ethernet network adapters.
427) Implementation of a intermediate level network device driver for win32
428) and 64bit would provide a way to intercept and route traffic over such
429) networks. This project will require knowledge of and experience with
430) Windows kernel device driver development and testing. Familiarity with
431) Winsock and Qemu would also be helpful.
432) </li>-->

433) <li>

434) <b>Améliorer Tor Weather</b> <br /> Priorité: <i>Moyenne</i> <br /> Effort à
435) fournir: <i>Moyen</i> <br /> Compétences requises: <i>moyennes</i> <br />
436) Tuteurs potentiels: <i>Christian, Roger</i> <br /> <a
437) href="https://weather.torproject.org/">Tor weather</a> est un outil qui
438) permet de recevoir un email indiquant le moment où le relais que vous
439) désirez tracer s'arrête. Actuellement, il n'est pas vraiment utile pour les
440) personnes qui utilisent la fonctionnalité d'hibernation de Tor ou pour ceux
441) qui doivent éteindre régulièrement leur relais. Au cours du projet, Tor
442) weather pourrait être enrichi pour permettre des configurations plus
443) souples.  D'autres améliorations sont également envisageables: Weather
444) pourrait vous envoyer des avertissements lorsque votre relais fonctionne
445) avec une version périmée de Tor ou lorsque votre bande passante atteint un
446) seuil limite. Il pourrait être également un outil sympathique pour vous
447) indiquer si votre relais vous permet d'avoir un <a href="<page
448) tshirt>">T-Shirt</a> ou envoyer des rappels au autorités d'annuaire que
449) leurs clefs vont bientôt expirer. Soyez créatifs et n'oubliez pas que ce
450) projet vous permet de juger de l'état du réseau dans le but de vous aider à
451) terminer votre travail plus rapidement ! Consultez également son <a
452) href="https://svn.torproject.org/svn/weather/trunk/README">README</a> et <a
453) href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.

454) </li>
455) 
456) <li>

457) <b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b> <br /> Priority:
458) <i>Medium</i> <br /> Effort Level: <i>Medium</i> <br /> Skill Level:
459) <i>Medium</i> <br /> Likely Mentors: <i>Erinn, Peter</i> <br /> Vidalia
460) currently doesn't play nicely on Debian and Ubuntu with the default Tor
461) packages. The current Tor packages automatically start Tor as a daemon
462) running as the debian-tor user and (sensibly) do not have a <a
463) href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> defined in the
464) default torrc. Consequently, Vidalia will try to start its own Tor process
465) since it could not connect to the existing Tor, and Vidalia's Tor process
466) will then exit with an error message the user likely doesn't understand
467) since Tor cannot bind its listening ports &mdash; they're already in use by
468) the original Tor daemon.  <br /> The current solution involves either
469) telling the user to stop the existing Tor daemon and let Vidalia start its
470) own Tor process, or explaining to the user how to set a control port and
471) password in their torrc. A better solution on Debian would be to use Tor's
472) ControlSocket, which allows Vidalia to talk to Tor via a Unix domain socket,
473) and could possibly be enabled by default in Tor's Debian packages. Vidalia
474) can then authenticate to Tor using filesystem-based (cookie) authentication
475) if the user running Vidalia is also in the debian-tor group.  <br /> This
476) project will first involve adding support for Tor's ControlSocket to
477) Vidalia. The student will then develop and test Debian and Ubuntu packages
478) for Vidalia that conform to Debian's packaging standards and make sure they
479) work well with the existing Tor packages. We can also set up an apt
480) repository to host the new Vidalia packages.  <br /> The next challenge
481) would be to find an intuitive usable way for Vidalia to be able to change
482) Tor's configuration (torrc) even though it is located in
483) <code>/etc/tor/torrc</code> and thus immutable. The best idea we've come up
484) with so far is to feed Tor a new configuration via the ControlSocket when
485) Vidalia starts, but that's bad because Tor starts each boot with a different
486) configuration than the user wants. The second best idea we've come up with
487) is for Vidalia to write out a temporary torrc file and ask the user to
488) manually move it to <code>/etc/tor/torrc</code>, but that's bad because
489) users shouldn't have to mess with files directly.  <br /> A person
490) undertaking this project should have prior knowledge of Debian package
491) management and some C++ development experience. Previous experience with Qt
492) is helpful, but not required.

493) </li>
494) 
495) 

496) 
497) <!--<li>
498) 
499) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
500) <br />
501) We're in need of a good authenticated-update framework.
502) Vidalia already has the ability to notice when the user is running an
503) outdated or unrecommended version of Tor, using signed statements inside
504) the Tor directory information. Currently, Vidalia simply pops
505) up a little message box that lets the user know they should manually
506) upgrade. The goal of this project would be to extend Vidalia with the
507) ability to also fetch and install the updated Tor software for the
508) user. We should do the fetches via Tor when possible, but also fall back
509) to direct fetches in a smart way. Time permitting, we would also like
510) to be able to update other
511) applications included in the bundled installers, such as Polipo and
512) Vidalia itself.
513) <br />
514) To complete this project, the student will first need to first investigate
515) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
516) their strengths, weaknesses, security properties, and ability to be
517) integrated into Vidalia. If none are found to be suitable, the student
518) will design their own auto-update framework, document the design, and
519) then discuss the design with other developers to assess any security
520) issues. The student will then implement their framework (or integrate
521) an existing one) and test it.
522) <br />
523) A person undertaking this project should have good C++ development
524) experience. Previous experience with Qt is helpful, but not required. One
525) should also have a good understanding of common security
526) practices, such as package signature verification. Good writing ability
527) is also important for this project, since a vital step of the project
528) will be producing a design document to review and discuss
529) with others prior to implementation.
530) </li>-->

531) <li>

532) <b>Improving the Tor QA process: Continuous Integration for builds</b> <br
533) /> Priority: <i>Medium</i> <br /> Effort Level: <i>Medium</i> <br /> Skill
534) Level: <i>Medium</i> <br /> Likely Mentors: <i>Erinn</i> <br /> It would be
535) useful to have automated build processes for Windows and probably other
536) platforms. The purpose of having a continuous integration build environment
537) is to ensure that Windows isn't left behind for any of the software projects
538) used in the Tor project or its accompanying.<br /> Buildbot may be a good
539) choice for this as it appears to support all of the platforms Tor does. See
540) the <a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
541) buildbot</a>.<br /> There may be better options and the person undertaking
542) this task should evaluate other options. Any person working on this
543) automatic build process should have experience or be willing to learn how to
544) build all of the respective Tor related code bases from
545) scratch. Furthermore, the person should have some experience building
546) software in Windows environments as this is the target audience we want to
547) ensure we do not leave behind. It would require close work with the Tor
548) source code but probably only in the form of building, not authoring.<br />
549) Additionally, we need to automate our performance testing for all
550) platforms.  We've got buildbot (except on Windows &mdash; as noted above) to
551) automate our regular integration and compile testing already, but we need to
552) get our network simulation tests (as built in torflow)  updated for more
553) recent versions of Tor, and designed to launch a test network either on a
554) single machine, or across several, so we can test changes in performance on
555) machines in different roles automatically.

556) </li>
557) 
558) 

559) 
560) <!--<li>
561) 
562) <b>Usability testing of Tor</b>
563) <br />
564) Priority: <i>Medium</i>
565) <br />
566) Effort Level: <i>Medium</i>
567) <br />
568) Skill Level: <i>Low to Medium</i>
569) <br />
570) Likely Mentors: <i>Andrew</i>
571) <br />
572) Especially the browser bundle, ideally amongst our target demographic.
573) That would help a lot in knowing what needs to be done in terms of bug
574) fixes or new features. We get this informally at the moment, but a more
575) structured process would be better.
576) </li>-->

577) <li>

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

606) </li>
607) 
608) <li>

609) <b>Make torsocks/dsocks work on OS X</b> <br /> Priority: <i>Medium</i> <br
610) /> Effort Level: <i>Medium</i> <br /> Skill Level: <i>Medium</i> <br />
611) Likely Mentors: <i>?</i> <br /> <a
612) href="http://code.google.com/p/torsocks/">Torsocks</a> and <a
613) href="http://code.google.com/p/dsocks/">dsocks</a> are wrappers that will
614) run applications, intercept their outgoing network connections, and push
615) those connections through Tor. The goal is to handle applications that don't
616) support proxies (or don't supporting them well). To get it right, they need
617) to intercept many system calls. The syscalls you need to intercept on Linux
618) differ dramatically from those on BSD. So Torsocks works fine on Linux,
619) dsocks works ok on BSD (though it may be less maintained and thus might miss
620) more syscalls), and nothing works well on both. First, we should patch
621) dsocks to use Tor's <i>mapaddress</i> commands from the controller
622) interface, so we don't waste a whole round-trip inside Tor doing the resolve
623) before connecting. Second, we should make our <i>torify</i> script detect
624) which of torsocks or dsocks is installed, and call them appropriately. This
625) probably means unifying their interfaces, and might involve sharing code
626) between them or discarding one entirely.
627) </li>
628) 
629) <li>
630) <b>Bring up new ideas!</b> <br /> Don't like any of these? Look at the <a
631) href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development
632) roadmap</a> for more ideas, or just try out Tor, Vidalia, and Torbutton, and
633) find out what you think needs fixing.  Some of the <a
634) href="<gittree>doc/spec/proposals">current proposals</a> might also be short
635) on developers.

636) </li>
637) 
638) </ol>
639) 

640) <a id="OtherCoding"></a>
641) <h2><a class="anchor" href="#OtherCoding">Autres idées de spécifications et de
642) code</a></h2>

643) <ol>

644) <li>Les serveurs de Tor ne fonctionnent pas parfaitement sur Windows
645) XP. SurWindows, Tor utilise l'appel système standard <tt>select()</tt>, qui
646) utilise l'espace non paginé dans le pool. Ce qui implique que les serveurs
647) de taille moyenne vont vider l'espace non paginé, <a
648) href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">provocant
649) l'instabilité et le plantage du système</a>. Nous devrions probablement
650) utiliser des E/S recouvrables à la place. Une solution pourrait-être
651) d'apprendre à la <a
652) href="http://www.monkey.org/~provos/libevent/">libevent</a> comment utiliser
653) les E/S recouvrables à la place de select() sous Windows, et alors d'adapter
654) Tor à la nouvelle interface libevent. Christian King à <a
655) href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">bien

656) démarré</a> sur ce point l'été 2007.</li>

657) 
658) <li>Nous avons besoin maintenant de commencer l'élaboration de notre <a
659) href="<page documentation>#DesignDoc">conception de résistance au
660) blocage</a>. Ceci implique une refonte de la conception, une modification de
661) différents aspects de Tor, une adaptation de <a href="<page
662) vidalia/index>">Vidalia</a> pour qu'il supporte les nouvelles

663) fonctionnalités, et planifier le deploiement.</li>

664) 
665) <li>Nous avons besoin d'un ensemble d'outils flexibles de simulation pour
666) étudier de bout en bout les trafics de confirmation d'attaque. Beaucoups de
667) chercheurs ont conçu des simulateurs ad hoc pour confirmer leurs intuitions
668) comme quoi soit l'attaque marche vraiment bien ou que les défenses
669) fonctionnent. Pouvons nous construire un simulateur qui soit clairement
670) documenté et suffisament ouvert pour que tout le monde sache qu'il donne une
671) réponse raisonnable ? Ceci stimulera un grand nombre de nouvelles
672) recherches. Voyez l'entrée <a href="#Research">suivante</a> sur les
673) confirmations d'attaque pour les détails sur le coté recherche de cette
674) tâche &mdash; qui sait, quand ceci sera fait peut-être pourrez aider en
675) écrivant un rapport ou deux.</li>
676) 
677) <li>Tor 0.1.1.x inclut le support d'accélérateurs matériels de chiffrage via
678) OpenSSL. Cependant, personne ne l'a jamais testé. Est-ce que quelqu'un
679) voudrait se procurer une carte et nous dire ce qu'il en est ?</li>
680) 

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

682) href="http://en.wikipedia.org/wiki/Fuzz_testing">du "fuzz"</a>. Déterminer
683) s'il existe déjà de bonnes bibliothèques de fuzz pour ce que nous voulons
684) faire. La célébrité pour celui grâce à qui une nouvelle version pourra voir
685) le jour !</li>
686) 
687) <li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est
688) simple et efficace, mais cela implique que toutes les unités (cellules) d'un
689) lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie
690) que seuls des flux TCP peuvent être raisonnablement supportés. Nous avons
691) dressé une <a
692) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">
693) liste de raisons pour lesquelles nous n'avons pas bifurqué vers le transport
694) par UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous
695) avons aussi proposé <a href="<gitblob>tor/doc/100-tor-spec-udp.txt">une
696) spécification pour Tor et UDP</a> &mdash; lisez-la et faites-nous part de
697) vos remarques et critiques, s'il-vous-plaît.</li>
698) 
699) <li>Nous ne sommes plus très loin d'avoir le support pour IPV6 entre les
700) serveurs de sorties et les adresses finales. Si IPV6 vous tient à cœur,
701) partir de là est sans doute un premier pas.</li>
702) 
703) <li>Nous avons besoin de générer les diagrammes du site web (par exemple les
704) images de "Comment fonctionne Tor ?" sur <a href="<page overview>">la page
705) d'aperçu</a> à partir d'une source de manière à pouvoir les traduire comme
706) du texte UTF-8 plutôt que de les éditer à la main avec Gimp. Nous voudrions
707) intégrer ce processus dans un fichier wml pour faciliter les traductions et
708) regénérer les images en plusieurs langues lorsque nous construisons le site
709) web.</li>
710) 
711) <li>Comment pouvons-nous maintenir, améliorer et documenter plus facilement les
712) différents systèmes LiveCD/USB ? <a href="http://amnesia.boum.org/">Le
713) LiveCD/USB amnesia</a>et <a
714) href="http://anonymityanywhere.com/incognito/">le LiveCD Incognito</a> sont
715) quelques exemples.
716) </li>

717) 
718) <li>
719) Another anti-censorship project is to try to make Tor more
720) scanning-resistant.  Right now, an adversary can identify <a
721) href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a> just by
722) trying to connect to them, following the Tor protocol, and seeing if they
723) respond.  To solve this, bridges could <a

724) href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

725) webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools, and
726) not act like bridges until the user provides a bridge-specific key.  To
727) start, check out Shane Pope's <a
728) href="http://dl.dropbox.com/u/37735/index.html">thesis and prototype</a>.
729) </li>
730) 

731) </ol>
732) 
733) <a id="Research"></a>
734) <h2><a class="anchor" href="#Research">Recherche</a></h2>
735) <ol>

736) <li>"L'attaque par empreinte de sites": faire une liste de quelques centaines de
737) sites populaires, en télécharger les pages, et faire des "signatures" pour
738) chaque site. Ensuite, observer le trafic d'un client Tor. L'analyse de ses
739) réceptions de données donne rapidement une idée des sites qu'il
740) visite. Premièrement, quelle est l'efficacité de cette attaque sur le code
741) actuellement utilisé dans Tor ? Ensuite, tester les défenses possibles : par
742) exemple, changer la taille des cellules de Tor de 512 octets à 1024,
743) utiliser des techniques de remplissage comme <a
744) href="http://freehaven.net/anonbib/#timing-fc2004">le lâcher défensif</a>,
745) ou ajouter des délais de trafic. Quel impact ces stratégies de défense
746) ont-elles, et, dans les cas où elles sont efficaces en défense, quel impact
747) ont-elles en terme de perte d'utilisabilité de Tor (à quantifier) ?</li>
748) <li>"L'attaque par corrélation des trafics aux extrémités": par l'observation
749) des trafics de Alice et Bob, il est possible de <a
750) href="http://freehaven.net/anonbib/#danezis:pet2004">comparer les signatures
751) des trafics et d'en déduire qu'il s'agit du même flux</a>. Jusqu'ici, Tor
752) considère ce type d'attaque comme intrinsèque et donc inévitable. Tout
753) d'abord, est-ce réellement vrai ? Quelle quantité de trafic - et avec quelle
754) distribution - est-elle nécessaire pour que l'adversaire soit certain
755) d'avoir gagné ? Est-ce qu'il existe des scénarios (par exemple avoir un
756) trafic faible) pour ralentir cette attaque ? Est-ce que certains types de
757) remplissage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>
758) <li>On peut relier la question qui vient: Est-ce-que le fait de faire tourner un
759) relais/passerelle offre une protection supplémentaire contre ces attaques
760) basées sur les timings ? Un attaquant externe qui ne peut voir l'intérieur
761) des flux TLS peut-il reconnaître de manière fiable les flux individuels ?
762) Est-ce-que le volume de trafic transféré dégrade cette possibilité ? Que
763) faire si le relais du client retarde délibérément le trafic montant pour
764) former une queue pouvant être utilisée pour mimer les timings du trafic
765) descendant du client pour le faire passer pour du trafic egalement relayé ?
766) Cette queue identique pourrait être également utilisée pour masquer les
767) temps du trafic montant du client à l'aide des techniques dites <a
768) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptative
769) padding</a> sans avoir besoin de trafic supplémentaire. Est-ce-qu'un tel
770) entrelacement du trafic montant du client osbcurcit les temps pour des
771) attaquants externes ? Les stratégies doivent-elles être ajustées pour les
772) liens symétriques ? Ou bien est-ce plus évident que pour les liens
773) symétriques ?</li>
774) <li><a href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">L'attaque
775) d'Oakland 05</a> par Repeat Murdoch et Danezi sur le réseau Tor
776) acutel. Essayez de comprendre pourquoi elle fonctionne bien sur certains
777) noeuds et pas sur les autres. (Ma théorie est que les noeuds rapides avec
778) davantage de capacité résistent mieux à l'attaque). On peut expérimenter
779) cette attaque avec la gestion des options RelayBandwithRate et
780) RelayBandwithBurst pour faire tourner un relais utilisé comme client tout en
781) relayant le traffic de l'attaquant: si nous limitons fortement le
782) RelayBandwithRate, est-ce-que l'attaque est plus difficile ? Quel est le
783) ratio correct de RelayBandwithRate par rapport à la capacité ? D'ailleurs,
784) est-ce-que le ratio joue un rôle dans cette attaque ? Pendant qu'on y est,
785) est-ce-qu'un plus grand nombre de relais candidats augmente le taux de faux
786) positifs ou une autre complexité dans l'attaque ? (Le réseau Tor est
787) maintenant deux fois plus étendu qu'il ne l'était au moment de la rédaction
788) de leur papier). Prenez également le temps de consulter le document <a
789) href="http://freehaven.net/anonbib/#clog-the-queue">Don't Clog the
790) Queue</a>.</li>
791) <li>L'attaque "routing zones": la majorité de ce qui est écrit sur Tor modélise
792) le chemin réseau entre Alice et son noeud d'entrée (et entre Bob et le noeud
793) de sortie) comme un simple lien sur un graphe. En pratique, le chemin
794) traverse de nombreux systèmes automomes (SA) et <a
795) href="http://freehaven.net/anonbib/#feamster:wpes2004">il n'est pas rare que
796) le même SA apparaissent à la fois sur le chemin d'entrée comme sur le chemin
797) de retoure</a>.  Malheureusement, pour être sûr de prédire si un quartet
798) Alice, noeud d'entrée, noeud de sortie, Bob sera dangereux, il faut
799) télécharger entièrement une zone de routage Internet et effectuer de
800) couteuses opérations dessus. Existe-t-il des approximations pratiques comme
801) éviter les adresse IP situées dans le même réseau /8 ?</li>
802) <li>D'autres points de recherche se pose la question de savoir, d'un point de
803) vue diversité géographique, s'il est mieux d'avoir un circuit efficace ou de
804) choisir un circuit au hasard. Consultez <a
805) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">les
806) travaux de Stephen Rollyson</a> qui expliquent comment éviter les choix
807) particulièrement inefficaces sans "trop" compromettre l'anonymat. Cet angle
808) d'attaque a besoin d'être creusé et travaillé mais il a l'air très
809) prometteur.</li>
810) <li>Tor ne fonctionne pas bien lorsque les relais disposent d'une bande passante
811) asymétrique (ex: câble ou ADSL). Etant donné que Tor sépare les connexions
812) entre chaque hop, si les octets entrants arrivent trop vite et que du coup,
813) les octets sortants arrivent plus lentement, les mécanismes de push-back de
814) TCP ne retournent pas cette information aux flux entrants.  Peut-être que
815) Tor devrait détecter les rejets de paquets sortants et réguler les flux
816) entrants de lui-même ? J'imagine un schéma d'ouverture/fermeture où l'on
817) récupère un taux de transfert limite donné qu'on incrémente lentement
818) jusqu'à perdre des paquets, moment où l'on diminuerait le taux, etc... Nous
819) avons besoin de quelqu'un disposant de sérieuses compétences réseau pour
820) simuler cela et apporter son aide pour la mise en place de ces
821) fonctionnalités. Nous avons besoin de comprendre l'importance de la
822) dégradation des performances et de l'utiliser comme élément moteur en vue de
823) reconsidérer le transport par UDP.</li>
824) <li>Le contrôle de la congestion est un sujet proche. Est-ce-que notre
825) spécification permet de gérer les fortes charges ? Peut-être devrions-nous
826) expérimenter des fenêtres de tailles variables plutôt que des fenêtres fixes
827) ? Cela semble prometteur dans <a
828) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">cette
829) expérimentation autour de ssh</a>. Nous avons besoin de mesurer, de corriger
830) et peut-être de refondre quelquechose si les résultats s'avèrent bons.</li>
831) <li>Nos objectifs de résistance à la censure incluent l'impossibilité pour un
832) attaquant qui observe le trafic Tor de <a

833) href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">le

834) distinguer d'un trafic SSL normal</a>. Néanmoins, nous ne pouvons pas
835) recréer une stéganographie parfaire tout en restant utilisable mais, dans un
836) premier temps, nous aimerions pouvoir bloquer toute attaque qui pourrait
837) réussir en observant quelques paquets seulement. Une des attaques qu'il nous
838) reste à examiner est basée sur le fait que les paquets Tor font 512 octets
839) et que par conséquence, les paquets du trafic réseau sont également des
840) multiples de 512 octets.  En quoi le fait de modifier les enregistrements
841) TLS et leur en-tête pourrait brouiller ce trafic ? Différentes stratégies de
842) fermeture de tampon dans Tor peuvent-elles avoir un impact sur ce sujet ?
843) Est-ce-qu'un peu de remplissage ferait l'affaire ou bien est-ce-une attaque
844) que nous pouvons accepter ?</li>
845) <li>Les circuits Tor sont construit pas à pas. Ainsi, il est théoriquement
846) possible de faire sortir des flux à partir du second pas, d'autres à partir
847) du troisième et ainsi de suite. Cela semble une alternative séduisante car
848) elle permet de passer outre la limite en sortie de chaque relais. Mais si
849) nous voulons que chaque flux soit sécurisé, le chemin "le plus court" doit
850) obligatoirement avoir au moins 3 pas selon notre logique actuelle. Nous
851) devons examiner cette alternative sur l'aspect performance en balance de la
852) sécurité</li>
853) <li>Il n'est pas si difficile de faire du dénis de service sur les relais Tor ou
854) les autorités d'annuaire. Les clients forment-ils la meilleure réponse ?
855) Quelles sont les autres approches possibles ? Il serait bien qu'elles soient
856) compatibles avec le protocole Tor actuel.</li>
857) <li>Les programmes tels que <a href="<page torbutton/index>">Torbutton</a> ont
858) pour objectif de masquer le champ UserAgent de votre navigateur web en le
859) replaçant par une réponse uniforme pour tous les utilisateurs Tor. Ainsi, un
860) attaquant ne peut rien déduire de vous en regardant cet en-tête. Il essaye
861) de récupérer une chaîne communément utilisée par les utilisateurs
862) non-Tor. Première question: comment révélons-nous l'utilisation de Tor en
863) mettant à jour régulièrement ce champ ? Si nous le mettons à jour trop
864) souvent, nous supprimons nous-même de l'anonymat. Si nous ne le mettons pas
865) à jour souvent alors tous les utilisateurs de Tor se dévoileront car leur
866) navigateur web indiquera qu'ils utilisent tous une assez vieille version de
867) Firefox. La réponse à la question dépend certainement des versions de
868) Firefox utilisés dans la nature. Deuxième question: régulièrement, les gens
869) nous demande de modifier le champ UserAgent selon un cycle de N chaînes de
870) caractères différentes plutôt que de mettre toujours la même. Est-ce-que
871) cette approche est vraiment utile, malfaisante ou neutre ? A prendre en
872) considération: les cookies et le fait de reconnaître les utilisateurs de
873) Torbutton par leur rotation de UserAgents; les sites webs malicieux qui
874) n'attaque qu'un seul type de navigateur web; la réponse à la question un
875) impact la réponse à la question deux.
876) </li>
877) <li>Actuellement, les clients Tor réutilisent un circuit donné pendant les dix
878) minutes qui suivent sa première utilisation. L'objectif est d'éviter de
879) surcharger le réseau avec des opérations de circuits étendus et également
880) pour éviter que les clients utilisent le même circuit pendant trop longtemps
881) ce qui permettrait au noeud de sortie de les profiler. Hélas, dix minutes
882) est une période de temps sans doute trop longue, spécialement si des
883) connexions vers des protocoles différents (ex messagerie instantanée et
884) navigation internet) utilisent le même circuit. Si nous continuons à fixer
885) le nombre global de la taille des circuits que le réseau a besoin d'établir,
886) existe-t-il de meilleurs et/ou de plus sûrs moyens pour les clients
887) d'affecter des flux aux circuits ou bien pour que les clients construisent
888) des circuits préemptifs ? Peut-être que cet élément de recherche doit
889) commencer par récupérer des traces sur les connexions typiques que les
890) clients initient afin de disposer de données réalistes ?
891) </li>
892) <li>De combien de passerelles avez-vous besoin pour maintenir un bon niveau
893) d'accessibilité ? Nous devrions mesurer le contenu de nos passerelles. Si ce
894) contenu est bien fourni, existe-t-il des moyens de faire en sorte que les
895) utilisateurs de passerelles restent connectés plus longtemps ?

896) </li>

897) </ol>
898) 

899) <p>

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

902) </p>

903) 

904)   </div>

905) 

906)