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="NLnet Project: Tor for Low Bandwidth Clients" CHARSET="UTF-8"

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

14) 
15) <!-- PUT CONTENT AFTER THIS TAG -->
16) <h2>Projet NLNet: Tor pour les clients à faible bande passante:</h2>

17) <hr />
18) 
19) <p>

20) Le système d'anonymat Tor est pour l'instant utilisable uniquement pour les
21) utilisateurs Internet qui disposent d'une connexion avec une bande passante
22) large. Dès le démarrage du client Tor, un fichier volumineux contenant la
23) description de tous les serveurs Tor est téléchargé. Ce fichier est celui
24) qui est appelé l'Annuaire Tor et permet au client de choisir parmi la
25) multitude de serveurs disponibles dans le réseau Tor. Le téléchargement de
26) l'intégralité de l'Annuaire Tor est indispensable dans le protocole Tor
27) actuellement employé. Ce fichier est trop volumineux pour les utilisateurs
28) de lignes modem ou pour les réseaux mobiles de données comme le GPRS car le
29) chargement initial qui est lancé à chaque fois que l'utilisateur se connecte
30) prend de 10 à 30 minutes sur une ligne lente. En conséquence, Tor n'est pas
31) utilisable sur les personnes utilisant une ligne modem ou une ligne
32) mobile. L'un des objectifs majeurs du projet Tor est de fournir un accès
33) Internet anonyme et sécurisé aux utilisateurs vivants dans les états
34) répréssifs et dictatoriaux. Ces lieux ont souvent des connexion à Internet
35) lentes, soit par modem soit à cause de la faiblesse des liens vers le reste

36) du monde. En permettant à ces utilisateurs d'utiliser le réseau Tor, un
37) progrès significatif sera réalisé pour la libre information dans ces pays.

38) </p>
39) 
40) <p>

41) Pour rendre Tor utilisable également par les utilisateurs ayant une
42) connexion à faible bande passante, une évolution du protocole Tor est
43) indispensable en vue de réduire la taille du téléchargement initial. Cette
44) nouvelle version du protocole devrait modifier le moyen pour le client de
45) recevoir l'information nécéssaire à l'établissement d'un circuit Tor de
46) manière à ce qu'elle puisse être récupérée en environ trois minutes par une
47) ligne modem à 14,4Kbps. Le travail à fournir à partir de cette proposition a
48) l'objectif final de rendre le changement de protocole en production et

49) propagé à l'ensemble des utilisateurs Tor dans un pas de temps de moins de
50) 12 mois. Le logiciel résultant sera publié sous licence BSD 3-Clause comme
51) le reste du code source de Tor. Tous les livrables seront entièrement
52) publics.

53) </p>
54) 
55) <p>
56) Ce projet est généreusement financé par:
57) </p>
58) 
59) <p>

60) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html"> <img
61) src="$(IMGROOT)/nlnet-160x60.png" alt="La fondation NLnet" /></a>

62) </p>
63) 
64) <table width="100%" border="0" cellspacing="0" cellpadding="3">
65) <thead>
66) <tr>
67) <th><big>Projet</big></th>

68) <th><big>Date de rendu</big></th>

69) </tr>
70) </thead>
71) 
72) <tr bgcolor="#e5e5e5">
73)   <td>

74)     <b>Livrable A:</b> Fonctionnalités et évaluation du changement de
75) protocole<br /><small><em>Ce livrable couvre le design détaillé et
76) l'évaluation basée sur une simulation des changements nécessaires et des
77) modifications de fonctionnalités du protocole Tor actuel.  Les changements
78) dans le protocole seront relativement substantiels, ils nécessitent donc une
79) évaluation prudente sur les possibles répercussions en terme de sécurité et
80) d'anonymat sur le réseau Tor. Une période de deux mois est planifiée pour
81) cette phase de design et d'évaluation qui conclura à une évaluation
82) intensive par les utilisateurs. Une partie du livrable A sera une définition
83) d'objectif de performance pour la phase d'implémentation. L'objectif de
84) design est de réduire la taille de l'annuaire Tor qu'il faut télécharger aux
85) environ de 300Ko ce qui permettra à un utilisateur sur une ligne à 14,4kbps
86) de le télécharger en environ trois minutes. Il y aura peut-être des écarts
87) par rapport à cet objectif pour des raisons de maintien d'anonymat et de
88) sécurité, mais ce chiffre est bien celui à atteindre.  </em></small>

89)   </td>
90)   <td>
91)     15 juillet 2008
92)   </td>
93) </tr>
94) 
95) <tr>
96)   <td>

97)     <b>Livrable B:</b>Implémentation du changement de protocole<br />
98) <small><em>Après le design, l'évaluation et le test utilisateur, les
99) modifications doivent être implémentées et intégrées dans la base actuelle
100) du code source de Tor. Cette implémentation prendra approximativement trois
101) mois.  </em></small>

102)   </td>
103)   <td>
104)     15 octobre 2008
105)   </td>
106) </tr>
107) 
108) <tr bgcolor="#e5e5e5">
109)   <td>

110)     <b>Livrable C:</b>Tests<br /> <small><em>Étant donné que la modification est
111) hautement critique en terme de sécurité et de maintient d'anonymat pour le
112) réseau Tor, elle requière des tests et du debugging en conditions de
113) laboratoire et en conditions réelles. Une période de trois mois est
114) planifiée pour ces opérations où le développeur responsable est dévolu à ce
115) travail à 1/3 de son temps. Une partie de la phase de tests sera une période
116) de version beta publique.  </em></small>

117)   </td>
118)   <td>

119)     15 janvier 2009

120)   </td>
121) </tr>
122) 
123) <tr>
124)   <td>

125)     <b>Livrable D:</b> Déploiement<br /> <small><em>Le déploiement vers le
126) serveur Tor sur le réseau sera mené en lien avec le calendrier des versions
127) régulières de Tor. Étant donné que ce calendrier dépend d'un certain nombre
128) de facteurs externes tels que l'état des autres projets logiciels devant

129) être incorporés dans la version, la date de livraison de la version actuelle

130) et celle où les modifications auront été complètement acceptées et
131) installées par la majorité des opérateurs de serveurs Tor peuvent
132) varier. D'expérience, on peut s'attendre à une période de trois à quatre
133) mois. Le déploiement sera intégré au processus de versions régulières de Tor
134) qui est une activité continue réalisée par des volontaires et du personnel
135) payés grâce aux dons au projet Tor.  </em></small>

136)   </td>
137)   <td>

138)     15 avril 2009

139)   </td>
140) </tr>
141) </table>
142) 

143) <br /> <a id="Reports"></a>

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

145) <p>

146) Il y aura au total huit rapports mensuels d'état qui commenceront avec le
147) premier livrable aux alentours du 15 juillet 2008 et se termineront avec la
148) fin de l'implémentation et des tests aux alentours du 15 janvier 2009.

149) </p>
150) 
151) <table width="100%" border="0" cellspacing="0" cellpadding="3">
152) <thead>
153) <tr>
154) <th><big>Mois,</big></th>
155) <th><big>Rapport d'avancement</big></th>
156) </tr>
157) </thead>
158) 
159) <tr bgcolor="#e5e5e5">
160)   <td>

161)     <a id="Jun08"></a> <a class="anchor" href="#Jun08">Juin 2008</a>
162)   </td>
163)   <td>
164)     <small><em>Nous avons effectué les premières mesures sur l'amorçage des
165) clients Tor. Les résultats ne sont pas très surprenants: un client récupère
166) environ 10ko de certificats, un document de consensus pour 140Ko (maintenant
167) 90Ko voir le paragraphe suivant) et environ 1,5Mo de descripteurs de serveur
168) (la construction des circuits démarre dès la moitié de ce
169) téléchargement).</em></small> <br /> <small><em><a
170) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">La
171) proposition 138</a> réduit la taille des documents de consensus de 30 à 40%
172) et a déjà été implémentée et intégrée dans la
173) spécification. L'implémentation fait partie de la branche 0.2.1.x-alpha et
174) le code source prendra effet une fois que plus des deux-tiers des autorités
175) d'annuaire (soit 5 sur 6) auront été mises à jour.</em></small> <br />
176) <small><em><a
177) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">La
178) proposition 140</a> n'est pas directement liée à la réduction du volume à
179) télécharger au démarrage mais essaye au contraire de rendre le
180) téléchargement des nouveaux documents de consensus moins volumineux. Elle a
181) été rédigée et <a
182) href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">envoyée sur la
183) liste de diffusion or-dev</a>. Il y a quelques questions qui doivent d'abord
184) être réglées par les autres développeurs Tor mais le reste me semble correct
185) et pourrait-être implémenté.</em></small> <br /> <small><em>Le gros du
186) projet est de faire en sorte que les clients ne doivent plus télécharger
187) 1,5Mo de descripteurs de serveurs. <a
188) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">La
189) proposition 141</a> a été <a
190) href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">envoyée sur la
191) liste de diffusion or-dev</a>. Pour le moment, j'y vois 3 choses à faire:
192) déplacer l'information sur l'équilibrage de charge dans le consensus (pas
193) trop complexe), mettre en place un dispositif pour que les clients Tor
194) puissent récupérer des descripteurs de serveurs à la demande depuis les
195) routeurs lorsqu'ils élaborent leur circuit (décrit dans le brouillon) et
196) enfin, gérer la sélection des sorties. Nous sommes toujours en cours de
197) réflexion concernant la dernière partie; quelques possibilités sont
198) mentionnées dans le brouillon.</em></small>

199)   </td>
200) </tr>
201) 
202) <tr>
203)   <td>

204)     <a id="Jul08"></a> <a class="anchor" href="#Jul08">Juillet 2008</a>
205)   </td>
206)   <td>
207)     <small><em>Le travail sur <a
208) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">la
209) proposition 141</a> avance: Il y a deux idées simples pour déplacer
210) l'information de répartition de charge dans le consensus: l'une est basée
211) sur les autorités générant les poids que les clients peuvent utiliser et
212) mettre dans le consensus, l'autre approche consiste à y insérer directement
213) l'information de bande passante depuis le descripteur de serveur.  La
214) dernière option est probablement la plus abordable lorsqu'on étudie
215) également <a
216) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">la
217) proposition 140</a>. Cette dernière évite d'avoir trop d'éléments fluctuants
218) dans le consensus.</em></small> <br /> <small><em>Pour la gestion de la
219) politique de sortie, <a
220) href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">un post de la
221) liste de diffusion or-dev</a> suggère l'ajout d'un hash d'identification de
222) la politique de sortie du noeud soit ajouté au document de consensus.
223) L'ajout dans le consensus de 160 bits à haute entropie par noeud est risqué
224) mais nous pensons que puisque les politiques de sortie sont souvent
225) identiques, le document de consensus devrait se compresser correctement.
226) Nous attendons les mesures sur ce sujet.</em></small>

227)   </td>
228) </tr>
229) 
230) <tr bgcolor="#e5e5e5">
231)   <td>

232)     <a id="Aug08"></a> <a class="anchor" href="#Aug08">Août 2008</a>

233)   </td>
234)   <td>

235)     <small><em>Les documents de vote des autorités d'annuaire et l'algorithme de
236) création de leur consensus ont été modifiés de manière à inclure
237) l'information sur la bande passante et les résumés des politiques de sorties
238) tels qu'indiqués dans la proposition 141.  Une fois que cinq des six
239) autorités en fonctionnement auront mis à jour leur base à la révision 16554,
240) le consensus commencera à inclure cette information.</em></small>

241)   </td>
242) </tr>
243) 
244) <tr>
245)   <td>

246)     <a id="Sep08"></a> <a class="anchor" href="#Sep08">Septembre 08</a>

247)   </td>
248)   <td>

249) <small><em>Pas de mises à jour pour Septembre.</em></small>

250)   </td>
251) </tr>
252) 
253) <tr bgcolor="#e5e5e5">
254)   <td>

255)     <a id="Oct08"></a> <a class="anchor" href="#Oct08">Octobre 08</a>

256)   </td>

257)   <td><p>
258) <small><em>Nous n'avons pas réussi à atteindre notre jalon "terminer
259) l'implémentation" ce mois-ci car le développeur principal du projet avait
260) trop de travail à mener. La bonne nouvelle est que nous avons réalisé une
261) grande partie du travail d'implémentation et il est en cours depuis
262) plusieurs mois maintenant (depuis le jalon d'août) et a donc déjà bénéficié
263) de nombreux tests. Les étapes restantes sont: faire en sorte que les relais
264) sachent comment récupérer les requêtes de demande de descripteurs à partir
265) de l'intérieur du circuit (nous allons probablement utiliser un nouveau type

266) de cellule pour ça de manière à éviter un aller-retour); puis de faire en

267) sorte que les clients puissent effectuer ces requêtes dès lors qu'ils sont
268) dans une version suffisamment récente. Ces deux étapes sont rédigées de
269) manière détaillée dans <a
270) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">la
271) Section 3.2 de la proposition 141</a>.</em></small></p>
272) 

273) <p><small><em>Notre nouveau plan est de disposer de ces deux morceaux courant

274) novembre, et si cela se présente moins bien, alors nous procéderons à une

275) refonte plus radicale de notre planning et peut-être également sur le

276) design.</em></small></p>
277) 
278) <p><small><em>Il y a d'autres composants que nous aimerions créer après
279) celui-ci: le premier auquel nous pensons consiste à télécharger des "diffs"
280) du dernier consensus: <a
281) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">140-consensus-diffs.txt</a>.
282) D'abord, cela pourrait consommer moins de bande passante ce qui est toujours
283) appréciable lorsque multiplié par le nombre total de clients, mais aussi,
284) cela signifie que nous pouvons utiliser cette bande passante pour récupérer
285) les diffs plus souvent que l'actuel "toutes les 3 ou 4 heures". Si les
286) clients récupère plus souvent les informations à jour des annuaires, ils
287) peuvent alors construire des chemins plus rapides car ils disposent
288) d'information plus fraîche sur la bande passante de chaque relais (ce qui
289) est lié avec le premier projet NLnet ci-dessus). La nouvelle idée importante
290) est que cela signifie également que nous gérons mieux les relais
291) transitoires: actuellement, un relais doit tourner depuis au moins 3 à 4
292) heures avant de voir des utilisateurs et cela met de côté un grand nombre de
293) volontaires qui désirent faire tourner un relais seulement quelques
294) heures.</em></small></p>
295) <p><small><em>La prochaine étape est de terminer l'implémentation de la
296) proposition 114 de manière à ce que nous puissions la faire tester par les
297) utilisateurs. Espérons que ce sera pour bientôt !</em></small></p>

298)   </td>
299) </tr>
300) 
301) <tr>
302)   <td>

303)     <a id="Nov08"></a> <a class="anchor" href="#Nov08">Novembre 2008</a>

304)   </td>
305)   <td>

306) <p><small><em>Il semble que le plan original que nous avions mis en place pour
307) la dernière partie de développement était à la fois a) beaucoup plus
308) compliqué que prévu et b) heureusement très efficace comparé à ce dont nous
309) avions besoin.</em></small></p>
310) 
311) <p><small><em> Roger a relancé la discussion sur le design sur la liste de
312) diffusion or-dev: <a
313) href="http://archives.seul.org/or/dev/Nov-2008/threads.html">http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.</em></small></p>
314) 
315) <p><small><em>Je pense que nous avons maintenant une meilleure vision des
316) options et des arbitrages: <a
317) href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.</em></small></p>
318) 
319) <p><small><em>Nick a été enterré par d'autres projets de développement
320) (heureusement, ça devrait aller mieux pour le mois à venir) et je veux avoir
321) son opinion sur comment procéder. J'espère que nous retiendrons l'approche
322) la plus simple.</em></small></p>
323) 
324) <p><small><em>Hélas, les approches très simples permettent moins
325) d'évolutivité. Néanmoins, je pense qu'elles feront des bouches-trous
326) corrects pour plus tard -- et comme on ne sait pas quand 'plus tard' arrive,

327) qui sait ce qui aura changé ?</em></small></p>

328)   </td>
329) </tr>
330) 
331) <tr bgcolor="#e5e5e5">
332)   <td>

333)     <a id="Jan09"></a> <a class="anchor" href="#Jan09">Janvier 2009</a>

334)   </td>
335)   <td>

336) <p><small><em> J'ai rédigé une version plus détaillée de notre nouvelle idée de
337) design, sous la <a
338) href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt">proposition
339) Tor #158</a>, et la discussion a commencé ici: <a
340) href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html">http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.</em></small></p>

341) 

342) <p><small><em> Je pense que nous en avons terminé ! (En fait, une fois que
343) j'aurais tenu compte de tous les commentaires.)  </em></small></p>
344) 
345) <p><small><em> La raison principale du fait que le projet ne tienne pas le
346) calendrier prévu tient à la conclusion du <a href="<page
347) projects/hidserv>">projet de Karsten de la NLnet sur la performance des
348) services cachés</a>: le principal responsable est l'extension de
349) circuit. Pour le moment, ce projet a proposé d'ajouter davantage
350) d'aller-retours et de complexité sur ce sujet. Ainsi, il nous faut élaborer
351) un meilleur plan pour atteindre l'objectif final sans sacrifier encore plus
352) de performance.  </em></small></p>
353) 
354) <p><small><em>Nous avons modifié la proposition de conception au cours des
355) semaines passées et je pense que nous serons bientôt prêts pour
356) l'implémentation. A noter qu'étant donné notre charge de travail en cours
357) sur le développement qui devrait s'étaler jusqu'à mi-février, il est
358) probable que cette implémentation ne sera mise en oeuvre qu'à partir de la
359) fin février ou pour mars. Cette fois, pour de bon !</em></small></p>

360)   </td>
361) </tr>
362) </table>
363) 
364) <br />
365) 

366) </div>

367) 
368) 
369)