tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 15959

3) #Last-Translator: mfr(ä]misericordia.be
4) 
5) #include "head.wmi" TITLE="Projet NLnet: Tor pour clients bas débit" CHARSET="UTF-8"
6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->
10) 
11) <h2>Projet NLnet: Tor pour clients bas débit</h2>
12) <hr />
13) 
14) <p>

15) Le système Tor anonymat est actuellement uniquement utilisable par les utilisateurs internet qui ont des connexions à haut débit. Dès lancement du client Tor, un grand fichier contenant toutes les descriptions de serveur Tor est téléchargé. Ce fichier, appellé le répertoire de Tor, permet au client de choisir parmi les serveurs de mélange disponibles dans le réseau Tor. Le téléchargement complet du répertoire Tor est requis par le protocole actuel de Tor. Ce répertoire fichier est trop volumineux pour les utilisateurs de modem sur des lignes ou des réseaux de données mobiles comme le GPRS car le téléchargement initial est déclenché à chaque fois qu'un utilisateur se connecte et prend de 10 à 30 minutes sur une ligne lente. En conséquence, Tor n'est pas utilisable par modem et par les utilisateurs mobiles. L'un des principaux objectifs du projet Tor est d'assurer la sécurité des accès anonymes à Internet pour les utilisateurs dans les dictatures et les états répressifs. Ces sites ont souvent de accès internet très lents, soit par modem ou en raison du bas débit des liens vers le monde extérieur. En permettant à ces utilisateurs d'utiliser le réseau Tor, des progrès significatifs peuvent être accomplis en vue de la liberté de communication et d'information dans ces pays.

16) </p>
17) 
18) <p>
19) Pour rendre Tor également utilisable pour les utilisateurs de connexions bas débit, une évolution du protocole Tor est nécessaire pour réduire la taille de téléchargement initial. Cette nouvelle version du protocole Tor devrait changer la façon dont un client reçoit les informations pour la création d'un circuit Tor de telle façon, que le téléchargement initial puisse être effectué à partir un ligne avec modem 14,4 kbps en trois minutes environ. Les travaux doivent mener de la proposition à la mise en production finale du protocole et à la diffusion auprès des utilisateurs dans un délai de moins de 12 mois. Le logiciel sera publiée sous la licence BSD 3, comme tout le code Tor. Tous les résultats seront entièrement publics.
20) </p>
21) 
22) <p>
23) Ce projet est généreusement financé par:
24) </p>
25) 
26) <p>
27) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html">
28) <img src="$(IMGROOT)/nlnet-160x60.png" alt="The NLnet foundation" /></a>
29) </p>
30) 
31) <table width="100%" border="0" cellspacing="0" cellpadding="3">
32) <thead>
33) <tr>
34) <th><big>Projet</big></th>

35) <th><big>Date de livraison</big></th>

36) </tr>
37) </thead>
38) 
39) <tr bgcolor="#e5e5e5">
40)   <td>

41)     <b>Livrable A:</b> Document de conception et évaluation du changement de protocole<br />

42)     <small><em>Ce livrable couvre la conception détaillée et la simulation fondée sur l'évaluation des changements nécessaires et la conception des modifications au protocole actuel de Tor. Les changements dans le protocole seront relativement important, de sorte qu'ils exigent une évaluation attentive des répercussions possibles pour la sécurité et l'anonymat du réseau Tor. Un délai de deux mois est prévu pour cette conception et d'évaluation, qui se termine par un vaste examen par les pairs. L'objectif d'une partie du livrable A sera la définition de la performance pour la phase de mise en œuvre. L'objectif de conception est de réduire la taille du répertoire Tor qui doit être téléchargé à environ 300 kilo-octets, ce qui permettrait à un utilisateur sur une ligne de 14,4 kbit/s pour le télécharger à peu près trois minutes. Il peut y avoir des exceptions à cet objectif de conception si nécessaire, afin de préserver l'anonymat et la sécurité, mais c'est la valeur à viser.

43) 				</em></small>

44)   </td>
45)   <td>
46)     15 juillet 2008
47)   </td>
48) </tr>
49) 
50) <tr>
51)   <td>

52)     <b>Livrable B:</b> Mise en œuvre du changement de protocole<br />

53)     <small><em>Après la conception, l'évaluation par les pairs et les modifications doivent être mises en œuvre et intégrées dans la version actuelle de code de Tor. La mise en œuvre effective des changements nécessaires prendra environ trois mois.
54)     </em></small>
55)   </td>
56)   <td>
57)     15 octobre 2008
58)   </td>
59) </tr>
60) 
61) <tr bgcolor="#e5e5e5">
62)   <td>

63)     <b>Livrable C:</b> Tests<br />

64)     <small><em>L'aspect très critique de la modification pour la sécurité et l'anonymat du réseau Tor, nécessite de nombreux essais et le débogage en laboratoire et en condtions d'utilisations réelles. Une période de trois mois est prévue pour tester et déboguer, où le développeur responsable passera 1/3 de son temps à des essais. Une partie de la phase d'essai sera une période de bêta publique.
65)     </em></small>
66)   </td>
67)   <td>
68)     15 novembre 2008
69)   </td>
70) </tr>
71) 
72) <tr>
73)   <td>

74)     <b>Livrable D:</b> Déploiement<br />

75)     <small><em>Le déploiement dans le réseau des serveurs Tor sera réalisé en synchronisation avec le calendrier normal de diffusion de Tor. Comme ce calendrier dépend d'un certain nombre de facteurs externes, tel que l'achèvement d'autres projets de logiciels qui devraient aller dans le même livraison, la date de sortie effective et la date auquelle cette version a été accepté et installé par la plupart des opérateurs de serveur Tor peuvent varier. D'expérience une période de trois à quatre mois peut être prévue. Le déploiement sera effectué dans le cadre du processus de livraison Tor qui est une activité permanente fait par des bénévoles et du personnel payé par d'autres subventions du projet Tor.

76)     </em></small>
77)   </td>
78)   <td>
79)     15 Février 2009
80)   </td>
81) </tr>
82) </table>
83) 
84) <br />
85) 
86) <a id="Reports"></a>

87) <h2><a class="anchor" href="#Reports">Rapports mensuels d'avancement</a></h2>

88) <p>

89) Il y aura au total huit rapports mensuels de situation en commençant 
90) par le premier livrable le 15 juillet 2008 et terminant avec l'achèvement 
91) de la mise en oeuvre et les tests de bon fonctionnement le 15 février 2009.

92) </p>
93) 
94) <table width="100%" border="0" cellspacing="0" cellpadding="3">
95) <thead>
96) <tr>
97) <th><big>Mois,</big></th>
98) <th><big>Rapport d'avancement</big></th>
99) </tr>
100) </thead>
101) 
102) <tr bgcolor="#e5e5e5">
103)   <td>
104)     <a id="Jun08"></a>
105)     <a class="anchor" href="#Jun08">Jui 08</a>
106)   </td>
107)   <td>
108)     <small><em>Nous n'avons fait une mesure initiale de vitesse des clients Tor.
109) 				Les résultats ne sont pas très surprenants: un client récupère environ 10 Ko
110) 				de certificats, un consensus pour 140KB (90KB maintenant, voir le paragraphe suivant),
111) 				et environ 1,5 Mo de descripteurs  de serveurs (et avec la moitié d'entre eux

112) 				il commence la construction de circuits).</em></small>

113)     <br />

114)     <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">La proposition 138</a>  qui réduit de 30 à 40% les documents de consensus a déjà été réalisée et fusionnée en les spécifications. La mise en œuvre est en place dans la branche 0.2.1.x-alpha et le code prendra effet une fois de plus des deux-tiers des répertoires autorités (c'est-à-dire 5 sur 6) auront été mis à jour.</em></small>

115)     <br />
116)     <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Une proposition
117)     140</a> qui ne se rapporte pas directement à la réduction de la taille du
118) 				téléchargement initial, mais tente de rendre les nouveaux téléchargements
119) 				de documents de consensus moins volumineux, a également été rédigée et <a
120)     href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">envoyée à
121)     or-dev</a>. Il y a des questions auxquelles doivent répondre les autres
122) 				développeurs de Tor en premier, mais je pense que cela va bien et pourrait

123) 				être mis en œuvre.</em></small>

124)     <br />
125)     <small><em>Le Gros Travail est que les clients ne téléchargent pas tous
126) 				les 1,5 Mo de descripteurs de serveurs. <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">
127) 				Une proposition 141</a> a été <a
128)     href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">envoyée
129)     à or-dev</a>. Il existe principalement 3 choses à l'intérieur, 
130) 				pour autant que je puisse voir actuellement: déplacer l'équilibrage
131) 				des informations de charge dans le consensus (ne devrait pas être difficile),
132) 				mettre en oeuvre quelque chose pour que clients Tor puissent récupérer les DSs 
133) 				à la demande de routeurs le long de leur circuit alors qu'ils sont en train 
134) 				de la construire (décrites dans le projet), et de selectionner le sortie. 
135) 				Nous sommes encore en phase de développement des idées pour cette dernière partie,

136) 				plusieurs possibilités sont mentionnées dans le projet.</em></small>

137)   </td>
138) </tr>
139) 
140) <tr>
141)   <td>

142) 			<a id="Jul08"></a>
143) 			<a class="anchor" href="#Jul08">Juil 08</a>
144)   </td>
145)   <td>
146) 				<small><em>La travail sur la <a
147)     href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Proposition
148)     141</a> continue:  Il y a principalement deux idées sur la façon de 
149) 				déplacer les informations d'équilibrage de charge dans le consensus: 
150) 				la première est que les autorités générent le poids que les clients 
151) 				doivent utiliser et le mettre dans le consensus, 
152) 				l'autre approche est de mettre juste les informations de bande passante
153) 				du descriteur du serveur. Cette dernière option est probablement 
154) 				plus pratique si l'on considère également la <a
155)     href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Proposition
156)     140</a> qui évite d'avoir un nombre très fluctuant dans le consensus.</em></small>
157)     <br />
158)     <small><em>Pour la gestion des politiques de sortie <a
159)     href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">un
160)     message sur la liste or-dev</a> propose qu'un hash identifie une 
161) 				politique de sortie ajoutée au document de consensus. L'addition
162) 				de 160 bits aléatoires par noeud au consensus pourrait être un 
163) 				souci mais comme nous pensons qu'un grand nombre de politiques 
164) 				de sorties sont identiques, le document de consensus sera compressé 
165) 				efficacement. Des mesures sont en attente.</em></small>

166)   </td>
167) </tr>
168) 
169) <tr bgcolor="#e5e5e5">
170)   <td>
171)     Aou 08
172)   </td>
173)   <td>
174)   </td>
175) </tr>
176) 
177) <tr>
178)   <td>
179)     Sep 08
180)   </td>
181)   <td>
182)   </td>
183) </tr>
184) 
185) <tr bgcolor="#e5e5e5">
186)   <td>
187)     Oct 08
188)   </td>
189)   <td>
190)   </td>
191) </tr>
192) 
193) <tr>
194)   <td>
195)     Nov 08
196)   </td>
197)   <td>
198)   </td>
199) </tr>
200) 
201) <tr bgcolor="#e5e5e5">
202)   <td>
203)     Déc 08
204)   </td>
205)   <td>
206)   </td>
207) </tr>
208) 
209) <tr>
210)   <td>
211)     Jan 09
212)   </td>
213)   <td>
214)   </td>
215) </tr>
216) </table>
217) 
218) <br />
219) 
220) <!-- Do we want a people section? If so, would it make sense to write what

221) these people will be doing? And what exactly are these people going to