projects/fr/lowbandwidth.wml (2864568fc) - tor-webwml.git

lowbandwidth.wml

## translation metadata
# Revision: $Revision$
# Translation-Priority: 4-optional
#include "head.wmi" TITLE="NLnet Project: Tor for Low Bandwidth Clients" CHARSET="UTF-8"
<div class="main-column">

<h2>Projet NLNet: Tor pour les clients à faible bande passante:</h2>
<hr />

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

Pour rendre Tor utilisable également par les utilisateurs ayant une
connexion à faible bande passante, une évolution du protocole Tor est
indispensable en vue de réduire la taille du téléchargement initial. Cette
nouvelle version du protocole devrait modifier le moyen pour le client de
recevoir l'information nécéssaire à l'établissement d'un circuit Tor de
manière à ce qu'elle puisse être récupérée en environ trois minutes par une
ligne modem à 14,4Kbps. Le travail à fournir à partir de cette proposition a
l'objectif final de rendre le changement de protocole en production et
propagé à l'ensemble des utilisateurs Tor dans pas de temps de moins de 12
mois. Le logiciel résultant sera publié sous licence BSD 3-Clause comme le
reste du code source de Tor. Tous les livrables seront entièrement publics.

Ce projet est généreusement financé par:

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Projet</big></th>
<th><big>Date de rendu</big></th>
</tr>
</thead>

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

<tr>
 <td>
 Livrable B:Implémentation du changement de protocole 
Après le design, l'évaluation et le test utilisateur, les
modifications doivent être implémentées et intégrées dans la base actuelle
du code source de Tor. Cette implémentation prendra approximativement trois
mois. 
 </td>
 <td>
 15 octobre 2008
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 Livrable C:Tests Étant donné que la modification est
hautement critique en terme de sécurité et de maintient d'anonymat pour le
réseau Tor, elle requière des tests et du debugging en conditions de
laboratoire et en conditions réelles. Une période de trois mois est
planifiée pour ces opérations où le développeur responsable est dévolu à ce
travail à 1/3 de son temps. Une partie de la phase de tests sera une période
de version beta publique. 
 </td>
 <td>
 15 janvier 2009
 </td>
</tr>

<tr>
 <td>
 Livrable D: Déploiement Le déploiement vers le
serveur Tor sur le réseau sera mené en lien avec le calendrier des versions
régulières de Tor. Étant donné que ce calendrier dépend d'un certain nombre
de facteurs externes tels que l'état des autres projets logiciels devant
être incorporé dans la version, la date de livraison de la version actuelle
et celle où les modifications auront été complètement acceptées et
installées par la majorité des opérateurs de serveurs Tor peuvent
varier. D'expérience, on peut s'attendre à une période de trois à quatre
mois. Le déploiement sera intégré au processus de versions régulières de Tor
qui est une activité continue réalisée par des volontaires et du personnel
payés grâce aux dons au projet Tor. 
 </td>
 <td>
 15 avril 2009
 </td>
</tr>
</table>

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

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

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Mois,</big></th>
<th><big>Rapport d'avancement</big></th>
</tr>
</thead>

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

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

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Aug08"></a> <a class="anchor" href="#Aug08">Août 2008</a>
 </td>
 <td>
 Les documents de vote des autorités d'annuaire et l'algorithme de
création de leur consensus ont été modifiés de manière à inclure
l'information sur la bande passante et les résumés des politiques de sorties
tels qu'indiqués dans la proposition 141. Une fois que cinq des six
autorités en fonctionnement auront mis à jour leur base à la révision 16554,
le consensus commencera à inclure cette information.
 </td>
</tr>

<tr>
 <td>
 <a id="Sep08"></a> <a class="anchor" href="#Sep08">Septembre 08</a>
 </td>
 <td>
Pas de mises à jour pour Septembre.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Oct08"></a> <a class="anchor" href="#Oct08">Octobre 08</a>
 </td>
 <td>
Nous n'avons pas réussi à atteindre notre jalon "terminer
l'implémentation" ce mois-ci car le développeur principal du projet avait
trop de travail à mener. La bonne nouvelle est que nous avons réalisé une
grande partie du travail d'implémentation et il est en cours depuis
plusieurs mois maintenant (depuis le jalon d'août) et a donc déjà bénéficié
de nombreux tests. Les étapes restantes sont: faire en sorte que les relais
sachent comment récupérer les requêtes de demande de descripteurs à partir
de l'intérieur du circuit (nous allons probablement utiliser un nouveau type
de celulle pour ça de manière à éviter un aller-retour); puis de faire en
sorte que les clients puissent effectuer ces requêtes dès lors qu'ils sont
dans une version suffisamment récente. Ces deux étapes sont rédigées de
manière détaillée dans <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">la
Section 3.2 de la proposition 141</a>.

Noter nouveau plan est de disposer de ces deux morceaux courant
novembre, et si cela se présente moins bien, alors nous procéderons à une
refonte plus radical de notre planning et peut-être également sur le
design.

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

<tr>
 <td>
 <a id="Nov08"></a> <a class="anchor" href="#Nov08">Novembre 2008</a>
 </td>
 <td>
Il semble que le plan original que nous avions mis en place pour
la dernière partie de développement était à la fois a) beaucoup plus
compliqué que prévu et b) heureusement très efficace comparé à ce dont nous
avions besoin.

Roger a relancé la discussion sur le design sur la liste de
diffusion or-dev: <a
href="http://archives.seul.org/or/dev/Nov-2008/threads.html">http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.

Je pense que nous avons maintenant une meilleure vision des
options et des arbitrages: <a
href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.

Nick a été enterré par d'autres projets de développement
(heureusement, ça devrait aller mieux pour le mois à venir) et je veux avoir
son opinion sur comment procéder. J'espère que nous retiendrons l'approche
la plus simple.

Hélas, les approches très simples permettent moins
d'évolutivité. Néanmoins, je pense qu'elles feront des bouches-trous
corrects pour plus tard -- et comme on ne sait pas quand 'plus tard' arrive,
qui sait ce qui aura changé.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Jan09"></a> <a class="anchor" href="#Jan09">Janvier 2009</a>
 </td>
 <td>
 J'ai rédigé une version plus détaillée de notre nouvelle idée de
design, sous la <a
href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt">proposition
Tor #158</a>, et la discussion a commencé ici: <a
href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html">http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.

Je pense que nous en avons terminé ! (En fait, une fois que
j'aurais tenu compte de tous les commentaires.)

La raison principale du fait que le projet ne tienne pas le
calendrier prévu tient à la conclusion du <a href="<page
projects/hidserv>">projet de Karsten de la NLnet sur la performance des
services cachés</a>: le principal responsable est l'extension de
circuit. Pour le moment, ce projet a proposé d'ajouter davantage
d'aller-retours et de complexité sur ce sujet. Ainsi, il nous faut élaborer
un meilleur plan pour atteindre l'objectif final sans sacrifier encore plus
de performance.

Nous avons modifié la proposition de conception au cours des
semaines passées et je pense que nous serons bientôt prêts pour
l'implémentation. A noter qu'étant donné notre charge de travail en cours
sur le développement qui devrait s'étaler jusqu'à mi-février, il est
probable que cette implémentation ne sera mise en oeuvre qu'à partir de la
fin février ou pour mars. Cette fois, pour de bon !
 </td>
</tr>
</table>

</div>

#include <foot.wmi>

tor-webwml.git

if we're going to rely on the footer, then actually attach it.