[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r9979: Update fr volunteer page (website/trunk/fr)
Author: fredzupy
Date: 2007-04-17 08:51:21 -0400 (Tue, 17 Apr 2007)
New Revision: 9979
Modified:
website/trunk/fr/volunteer.wml
Log:
Update fr volunteer page
Modified: website/trunk/fr/volunteer.wml
===================================================================
--- website/trunk/fr/volunteer.wml 2007-04-17 11:56:12 UTC (rev 9978)
+++ website/trunk/fr/volunteer.wml 2007-04-17 12:51:21 UTC (rev 9979)
@@ -1,150 +1,324 @@
## translation metadata
-# Based-On-Revision: 8183
-# Last-Translator: eightone_18@xxxxxxxxxxx
+# Based-On-Revision: 9921
+# Last-Translator: fredzupy@xxxxxxxxx
#include "head.wmi" CHARSET="UTF-8" TITLE="Contribuer"
<div class="main-column">
<!-- PUT CONTENT AFTER THIS TAG -->
-<h2>Quatre choses que vous pouvez faire :</h2>
+<h2>Trois choses que vous pouvez faire :</h2>
<ol>
-<li> Pensez à <a href="<page docs/tor-doc-server>">hÃberger un serveur</a> pour aider à la croissance du rÃseau Tor.</li>
-<li> Jetez un oeil à <a href="<page gui/index>">la compÃtition d'interfaces graphiques pour Tor</a>, et contribuez à amÃliorer l'interface et l'ergonomie de Tor. Un t-shirt est offert pour chaque proposition !</li>
-<li> Informez vos ami-e-s ! Faites-leur hÃberger des serveurs. Faites-leur utiliser les services cachÃs. Encouragez-les à informer leurs propres ami-e-s.</li>
-<li> Nous recherchons des fonds et des mÃcÃnes. Si vous adhÃrez aux objectifs de Tor, prenez s'il-vous-plaÃt un moment <a href="<page donate>">pour faire un don et aider aux dÃveloppements futurs de Tor</a>. De mÃme, si vous connaissez des entreprises, des ONGs, ou d'autres organisations qui souhaitent utiliser des communications sÃcurisÃes, parlez-leur de nous.</li>
+<li> Pensez à <a href="<page docs/tor-doc-server>">hÃberger
+un serveur</a> pour aider à la croissance du rÃseau Tor.</li>
+<li> Informez vos ami-e-s ! Faites-leur hÃberger des serveurs. Faites-leur utiliser les services
+cachÃs. Encouragez-les à informer leurs propres ami-e-s.</li>
+<li> Nous recherchons des fonds et des mÃcÃnes. Si vous adhÃrez aux objectifs de Tor, prenez s'il-vous-plaÃt un moment
+ <a href="<page donate>">pour faire un don et aider aux dÃveloppements
+ futurs de Tor</a>. De mÃme, si vous connaissez des
+ entreprises, des ONGs, ou d'autres organisations qui souhaitent utiliser des communications
+ sÃcurisÃes, parlez-leur de nous.</li>
</ol>
-<a id="Bugs"></a>
-<h2><a class="anchor" href="#Bugs">Bugs critiques</a></h2>
-<ol>
-<li>Les serveurs Tor ne sont actuellement pas stables sous Windows XP, car nous essayons d'utiliser des centaines de sockets alors que le noyau de Windows ne semble pas capable de le faire. <a href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems";> Aidez-nous à rÃsoudre ce problÃme !</a>La meilleure solution consiste certainement à apprendre à libevent à utiliser des E/S chevauchantes plutÃt que select() sous Windows, puis à adapter Tor pour cette nouvelle interface de libevent.</li>
-</ol>
-
-<!--
-<a id="Installers"></a>
-<h2><a class="anchor" href="#Installers">Installeurs</a></h2>
-<ol>
-<li>Matt Edman a Ãcrit un <a
-href="http://freehaven.net/~edmanm/torcp/download.html";> installeur pour Windows basà sur NSIS et qui contient Privoxy et TorCP</a>. Est-ce que vous pouvez l'aider à amÃliorer sa stabilità et à lui ajouter des fonctionnalitÃs ?
-</li>
-<li>DÃvelopper un logiciel pour la dÃsinstallation sous OS X qui soit plus automatique que de demander aux gens <a href="<page docs/tor-doc-osx>#uninstall">d'effacer manuellement chaque fichier</a>. Il faut proposer un moyen de faire cela en un clic.</li>
-<li>Notre <a href="<cvssandbox>tor/tor.spec.in">fichier de spÃcification RPM</a> doit trouver un mainteneur, de sorte que l'on puisse se reconcentrer sur l'Ãcriture de Tor. Si vous savez faire ce genre de chose avec les RPMs, aidez-nous.</li>
-</ol>
--->
-
<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Support d'applications</a></h2>
<ol>
-<li>Nous avons besoin de mÃthodes efficaces d'interception des requÃtes DNS, de sorte qu'elles ne laissent pas filtrer d'informations à un observateur local pendant que nous tentons d'Ãtre anonymes. (Ce qui arrive lorsque l'application fait sa rÃsolution DNS avant de passer par le proxy SOCKS.)
-<!--
-Une possibilità est d'utiliser le support intÃgrà à Tor pour ces rÃsolutions DNS; mais il est nÃcessaire de faire l'appel en utilisant notre nouvelle extension à socks, et aucune application ne le fait encore. Une meilleure solution consiste en l'utilisation de l'interface de contrÃle de Tor, qui intercepte la rÃsolution DNS, la transmet à Tor, qui rÃpond avec une adresse IP bidon. Lorsque l'application fait une connexion via Tor à cette adresse IP bidon, Tor la renvoie directement à la requÃte initiale.
--->
+<li>Nous avons besoin de mÃthodes efficaces d'interception des requÃtes DNS, pour qu'elles ne laissent pas filtrer
+d'informations à un observateur local pendant que nous tentons d'Ãtre anonymes. (Ce qui
+arrive lorsque l'application fait sa rÃsolution DNS avant de passer par
+le proxy SOCKS.)</li>
<ul>
-<li>Nous avons besoin <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches";>d'appliquer nos patchs à tsocks</a> et d'en maintenir un nouveau fork. Nous l'hÃbergerons si vous le souhaitez.</li>
+<li>Nous avons besoin <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches";>d'appliquer
+tout nos patchs à tsocks</a> et d'en maintenir une nouvelle branche. Nous l'hÃbergerons si
+vous le souhaitez.</li>
+<li>Nous devrions patcher le programme ÂÂdsocks dÃveloppà par Dug Song pour utiliser les commandes
+<i>mapaddress</i> de Tor depuis l'interface de contrÃle, de maniÃre à ne pas faire
+inutilement un aller-retour complet dans Tor pour faire la rÃsolution avant la
+connexion.</li>
+<li>Notre script <i>torify</i> doit dÃtecter lequel de tsocks ou
+dsocks est installà pour l'appeler correctement. Cela nÃcessite certainement
+d'unifier leurs interfaces, et peut amener à faire un mix des deux
+voire à en Ãliminer un des deux.</li>
+</ul>
+<li>Les gens qui hÃbergent des serveurs nous signalent qu'ils aimeraient avoir une passante allouÃe
+durant une partie de la journÃe, et une autre bande passante à un autre moment.
+PlutÃt que de coder ceci dans Tor, nous aimerions utiliser un petit
+script qui communique avec <a href="<page gui/index>">l'interface de contrÃle de Tor</a>,
+et ferait un setconf pour changer la valeur de la bande passante. Ãventuellement, ce pourrait Ãtre un script lancÃ
+par cron, ou qui se lancerait à certaines heures (
+ce qui est certainement plus portable). Quelqu'un pourrait-il Ãcrire cela pour nous,
+nous l'ajouterons à <a href="<svnsandbox>tor/contrib/">tor/contrib/</a>�
+C'est une bonne entrÃe pour la <a href="<page gui/index>"> compÃtition pour l'interface
+graphique de Tor</a>.
+ <!-- Nous avons un bon script pour Ãa maintenant, n est-ce pas ? -NM -->
</li>
-<li>Nous devrions patcher le programme "dsocks" dÃveloppà par Dug Song pour utiliser les commandes <i>mapaddress</i> de Tor depuis l'interface de contrÃle, de maniÃre à ne pas faire inutilement un aller-retour complet dans Tor pour faire la rÃsolution avant la connexion.</li>
-<li>Notre script <i>torify</i> doit dÃtecter lequel de tsocks ou dsocks est installà pour l'appeler correctement. Cela nÃcessite certainement d'unifier leurs interfaces, et peut amener à faire un mix des deux voire à en Ãliminer un des deux.</li>
-</ul>
-<li>Les gens qui hÃbergent des serveurs nous signalent qu'ils aimeraient pouvoir ajuster la bande passante allouÃe en fonction des moments de la journÃe. PlutÃt que de coder ceci dans Tor, nous aimerions utiliser un petit script qui communique avec <a href="<page gui/index>">l'interface de contrÃle de Tor</a>, et ferait un setconf pour changer la valeur de la bande passante. Ãventuellement, ce pourrait Ãtre un script lancà par cron, ou qui se lancerait à certaines heures (ce qui est certainement plus portable). Quelqu'un pourrait-il Ãcrire cela pour nous, nous l'ajouterons à <a href="<svnsandbox>tor/contrib/">tor/contrib/</a>? C'est une bonne entrÃe pour la <a href="<page gui/index>"> compÃtition pour l'interface graphique de Tor</a>.</li>
-<li>Tor peut <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit";> quitter le rÃseau Tor par un noeud de sorte choisi par l'utilisateur</a>, mais il serait pratique de n'avoir qu'Ã spÃcifier un pays, et que le serveur de sortie soit choisi automatiquement. Le meilleur moyen est probablement de rÃcupÃrer le rÃpertoire de Blossom, et d'utiliser en local un client qui rÃcupÃre ce rÃpertoire de maniÃre sÃre (via Tor et en vÃrifiant sa signature), lise les noms des machines <tt>.country.blossom</tt> et se charge ensuite de choisir le serveur.</li>
-<li>En parlant de gÃolocalisation, quelqu'un devrait faire une carte de la Terre indiquant chaque serveur Tor par un point. La cerise sur le gÃteau serait la mise à jour dynamique de la carte à mesure que le rÃseau Tor Ãvolue et grandit. Malheureusement, les moyens aisÃs de faire cela passent par l'envoi de toutes les donnÃes à Google pour qu'il trace cette carte pour vous. Dans quelle mesure cela jouerait-il sur la confidentialitÃ, et par ailleurs, existe-t-il des solutions de remplacement valables ?</li>
+<li>Tor peut <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit";>quitter
+le rÃseau Tor par un noeud de sortie particulier</a>, mais il serait pratique
+de n'avoir qu'Ã spÃcifier un pays, et que le serveur de sortie soit choisi automatiquement. Le
+meilleur moyen est probablement de rÃcupÃrer le rÃpertoire de Blossom, et d'utiliser en local un client
+qui rÃcupÃre ce rÃpertoire de maniÃre sÃre (via Tor et en vÃrifiant sa
+signature), lise les noms des machines <tt>.country.blossom</tt> et se charge ensuite
+de choisir le serveur.</li>
+<li>En parlant de gÃolocalisation, quelqu'un devrait faire une carte de la Terre
+indiquant chaque serveur Tor par un point. La cerise sur le gÃteau serait la mise à jour dynamique
+de la carte à mesure que le rÃseau Tor Ãvolue et grandit. Malheureusement, les moyens aisÃs de faire cela
+passent par l'envoi de toutes les donnÃes à Google pour qu'il trace cette carte pour vous. Dans quelle mesure
+cela jouerait-il sur la confidentialitÃ, et par ailleurs, existe-t-il des solutions de remplacement valables ?</li>
</ol>
-<!--
-<li>Tor fournit des connexion anonymes, mais nous n'assurons pas la gestion de mutliples pseudonymes : vu que Tor utilise le mÃme tunnel pour plusieurs connexions, si un attaquant sait que vous Ãtes l'auteur d'une de ces connexions (par exemple une site web sur lequel vous vous Ãtes authentifiÃ); il peut savoir que vous Ãtes l'auteur des autres connexions qui passent par ce tunnel. Il faudrait trouver une approche et une interface pour gÃrer les pseudonymes dans Tor. Voir <a
-href="http://archives.seul.org/or/talk/Dec-2004/msg00086.html";>ce post</a> et <a
-href="http://archives.seul.org/or/talk/Jan-2005/msg00007.html";>sa suite</a>
-pour plus de dÃtails.</li>
-</ol>
--->
-
-
<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Documentation</a></h2>
<ol>
-<li>Nous avons des retours d'utilisateurs de Tor qui sont victimes d'attaques contre leur anonymat à cause de javascript, java, activex, flash, etc, s'ils ne pensent pas à les dÃsactiver. Existe-t-il des greffons (comme le plugin NoScript pour Firefox) qui rendent la gestion de ce risque plus facile pour les utilisateurs ? Et quel est ce risque exactement ?</li>
-<li>Existerait-il un ensemble de plugins qui remplacerait la totalità des fonctions de Privoxy lorsqu'il est utilisà avec Firefox 1.5+ ? Il semblerait que Tor soit bien plus performant si l'on enlÃve Privoxy du circuit.</li></li>
-<li>Aidez Matt Edman à documenter et à Ãcrire des tutoriaux pour son <a href="http://vidalia-project.net/";>ContrÃleur pour Tor</a>.
-</li>
-
-<!--
-<li>Proposez-vous pour maintenir ce site : code, contenu, css, mise en page. Prenez contact avec nous sur le canal IRC dans un premier temps.</li>
-<li>Nous avons trop de documentation -- elle est Ãparse et redondante parfois. Envoyez-nous des corrections, remarques et questions pour que nous puissions l'amÃliorer.</li>
-<li>Ãtudiez les versions de privoxy/freecap/sockscap pour windows 32bits pour y trouver des problÃmes d'usage ou de stabilità afin d'essayer de les rÃsoudre ou au moins en avertir les utilisateurs.</li>
-<li>Est-ce que quelqu'un pourrait aider Matt Edman pour la documentation et le howto de son <a href="http://freehaven.net/~edmanm/torcp/";>ContrÃleur pour Tor sous Windows</a>?</li>
--->
-
-<li>Ãvaluez et documentez la liste des <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO";>programmes pouvant Ãtre utilisÃs avec Tor</a>.</li>
-<li>Nous avons besoin d'une meilleure documentation traitant de l'interception dynamique de connexions et de leur envoi à travers Tor. tsocks (Linux), dsocks (BSD),et freecap (Windows) semblent Ãtre de bons candidats.</li>
-<li>Nous avons toute une liste de <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms";>programmes potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles et dans quelles situations ? Contribuez à les tester et à documenter les rÃsultats.</li>
-<li>Aidez-nous à traduire le site et la documentation dans d'autres langues. Allez voir les <a href="<page translation>">conseils de traduction</a> si vous souhaitez le faire. Nous avons besoin de personnes pour maintenir à jour les versions existantes en italien, franÃais et suÃdois - regardez la page <a href="<page translation-status>">d'Ãtat des traductions</a>.</li>
+<li>Nous avons des retours d'utilisateurs de Tor qui sont victimes d'attaques contre leur anonymat
+à cause de javascript, java, activex, flash, etc, s'ils ne pensent pas à les dÃsactiver.
+Existe-t-il des greffons (comme NoScript pour Firefox) qui rendent la gestion
+de ce risque plus facile pour les utilisateurs ? Et quel est ce risque exactement ?</li>
+<li>Existerait-il un ensemble de plugins qui remplacerait la totalità des fonctions de
+Privoxy pour Firefox 1.5+ ? Il semblerait que Tor soit bien plus performant si l'on enlÃve
+Privoxy du circuit.</li>
+<li>Aidez Matt Edman à documenter et à Ãcrire des tutoriaux pour son
+contrÃleur Tor,
+<a href="http://vidalia-project.net/";>Vidalia</a>.</li>
+<li>Ãvaluez et documentez
+<a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO";>notre
+liste de programmes</a> pouvant Ãtre utilisÃs avec Tor.</li>
+<li>Nous avons besoin d'une meilleure documentation traitant de l'interception dynamique de
+connexions et de leur envoi à travers Tor. tsocks (Linux), dsocks (BSD),
+et freecap (Windows) semblent Ãtre de bons candidats, et utiliserait au mieux
+notre nouvelle fonctionnalità Transport.</li>
+<li>Nous avons toute une liste de <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms";>programmes
+potentiellement utiles qui s'interfacent avec Tor</a>. Lesquels sont utiles et dans quelles
+situations ? Contribuez à les tester et à documenter les rÃsultats.</li>
+<li>Aidez-nous à traduire le site et la documentation dans d'autres
+langues. Allez voir les <a href="<page translation>">conseils de
+traduction</a> si vous souhaitez le faire. Nous avons besoin de personnes pour
+maintenir à jour les versions existantes, franÃais et suÃdois -
+regardez la page <a href="<page translation-status>">d'Ãtat des traductions
+</a>.</li>
+<li>Est-ce que quelqu'un pourrait nous aider au cas oà nous souhaiterions la voie
+<a href="http://www.cacert.org/";>cacert</a> pour le
+SSL de notre <a href="<page documentation>#Developers">dÃpÃt SVN</a></li>
</ol>
<a id="Coding"></a>
<h2><a class="anchor" href="#Coding">Conception et Code</a></h2>
+<p>Vous souhaiter passer votre <a href="http://code.google.com/soc/";>Google Summer
+of Code</a> en travaillant sur TorÂ? Sympa.
+<a href="http://wiki.noreply.org/noreply/TheOnionRouter/SummerOfCode";>Lisez ceci
+Ã propos de Tor et GSoC</a>, et voyez si l'une ou l'autre de ces idÃes
+vous tente.</p>
<ol>
-
+<li>Les serveurs de Tor ne fonctionnent pas parfaitement sur Windows XP. Sur
+Windows, Tor utilise l'appel systÃme standard <tt>select()</tt>,
+qui utilise l'espace non paginà dans le pool. Ce qui implique
+que les serveurs de taille moyenne vont vider l'espace non paginÃ, <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems";>provocant
+l'instabilità et le plantage du systÃme</a>. Nous devrions probablement utiliser des E/S recouvrables
+à la place. Une solution pourrait-Ãtre d'apprendre à la <a
+href="http://www.monkey.org/~provos/libevent/";>libevent</a> comment utiliser
+les E/S recouvrables à la place de select() sous Windows, et alors d'adapter Tor Ã
+la nouvelle interface libevent.</li>
+<li>Du fait que les serveurs Tor ont besoin du mecanisme de stockage-et-envoi pour chaque cellules envoyÃes,
+les serveurs Tor ayant une grosse bande passante se retrouvent avec des douzaines de mÃgaoctets de mÃmoire
+juste pour les mÃmoires tampons. Il nous est nÃcessaire d'avoir une meilleur approche pour savoir quand rÃduire/Ãtendre
+la taille des tampons. Probablement que ceci devrait Ãtre calquà sur l'architecture de gestion des tampons Linux,
+oà nous avons des tampons rÃduits et se liant les un aux autre,
+plutÃt que des gros tampons monolithiquesÂ?</li>
+<li>Nous avons besoin d'un site central officiel pour rÃpondre à la question "Est-ce que cette adresse IP est
+un serveur de sortieÂTor ?". Ceci devrait fournir plusieurs interfaces, y compris
+une interface Web et une interface type DNSBL. Il pourrait apporter la plus
+Ã jour des rÃponses en conservant un miroir local des informations des rÃpertoires
+Tor. Le point dÃlicat c'est qu'Ãtre un serveur de sorti n'est pas
+boolÃenÂ:Âainsi la question devient "Est-ce que cette adresse est un serveur de sorti
+Tor pouvant sortir sur mon adresse IP:portÂ?" L'interface DNSBL
+recevra probablement plusieurs centaines de requÃtes par minute, ainsi dÃvelopper des algorithmes
+robustes est de mise. La cerise sur le gateau s'ils font des tests actifs à travers
+chaque noeud de sorti pour dÃterminer de quelle adresse IP elle sort vraiment.
+<a href="<svnsandbox>doc/contrib/torbl-design.txt">Lisez-en plus ici</a>.</li>
+<li>Il serait sympa d'avoir un LiveCD qui inclurait les derniÃres
+versions de Tor, Polipo ou Privoxy, Firefox, Gaim+OTR, etc. Il y a
+deux dÃfis ici : le premier de documenter le sytÃme et les choix suffisament
+bien pour que les personnes de sÃcurità puissent former une opinion sur la
+robustesse, et le second est de trouver comment faire en sorte qu'il soit facilement maintenable,
+pour qu'il ne devienne pas rapidement obsolÃte comme AnonymOS. Le plus, serait
+que l'image du CD tienne sur des CDs de tailles rÃduites.</li>
+<li>Lià au LiveCD, nous devrions travailler sur une image bien documentÃe et intuitive
+de Tor et d'un ensemble d'application supportÃe sur une clà USB. Le
+gros du travail ici est de dÃcider quelles configurations sont sÃcurisÃes,
+documenter ces dÃcisions, et faire quelque chose qui soit simple Ã
+maintenir et faire aller de l'avant.</li>
+<li>Notre interface graphique prÃfÃrÃe pour Tor, nommÃe
+<a href="http://vidalia-project.net/";>Vidalia</a>, nÃcessite toutes sortes
+de dÃvelopments.</li>
+<li>Nous avons besoin maintenant de commencer l'Ãlaboration de notre <a href="<page
+documentation>#DesignDoc">conception de rÃsistance au blocage</a>. Ceci implique
+une refonte de la conception, une modification de diffÃrents aspects de Tor, une adaptation de
+<a href="http://vidalia-project.net/";>Vidalia</a> pour qu'il supporte les nouvelles
+fonctionnalitÃs, et planifier le deploiement.</li>
+<li>Nous avons besoin d'un ensemble d'outils flexibles de simulation pour Ãtudier de bout en bout
+les trafics de confirmation d'attaque. Beaucoups de chercheurs ont conÃu des simulateurs ad hoc
+pour confirmer leurs intuitions comme quoi soit l'attaque marche
+vraiment bien ou que les dÃfenses fonctionnent. Pouvons nous construire un simulateur
+qui soit clairement documentà et suffisament ouvert pour que tout le monde sache qu'il
+donne une rÃponse raisonnable ? Ceci stimulera un grand nombre de nouvelles recherches.
+Voyez l'entrÃe <a href="#Research">suivante</a> sur les confirmations d'attaque pour les
+dÃtails sur le cotà recherche de cette tÃche — qui sait, quand ceci sera
+fait peut-Ãtre pouvez aider en Ãcrivant un papier ou deux.</li>
+<li>Nous avons besoin d'une Ãtude mesurÃe des performances de <a
+href="http://www.pps.jussieu.fr/~jch/software/polipo/";>Polipo</a>
+et <a href="http://www.privoxy.org/";>Privoxy</a>. Est-ce que Polipo est en fait
+significativement plus rapide, une fois le ralentissement de Tor factorisà ? Est-ce que les
+rÃsultats sont les mÃmes sous Linux et Windows ? LiÃ, est-ce que Polipo tient
+plus de site Web correctement que Privoxy ou vice versa ? Y'a-t-il des
+problÃmes de stabilità sur les plateformes communes telles que Windows ?</li>
+<li>Lià à ce qui est dit au dessus, pouvez vous aider à porter <a
+href="http://www.pps.jussieu.fr/~jch/software/polipo/";>Polipo</a> pour qu'il
+tourne de maniÃre stable et efficace sous Windows ?</li>
+<li>Nous avons besoin d'un banc de test distribuÃ. Nous avons des unitÃs de tests,
+mais il serait sympa d'avoir un script qui lance un rÃseau Tor,
+l'utilise quelque temps, et vÃrifie que, au moins, quelques aspects fonctionnent.</li>
+<li>Aidez Mike Perry sur sa bibliothÃque <a
+href="http://tor.eff.org/svn/torflow/";>TorFlow</a> (<a href="http://tor.eff.org/svn/torflow/TODO";>TODO</a>):
+c'est une bibliothÃque python qui utilise le <a
+href="http://tor.eff.org/svn/torctl/doc/howto.txt";>protocole du contrÃleur Tor
+</a> pour apprendre à Tor à construire des circuits de diffÃrentes maniÃres,
+et ensuite mesure les performances et essaye de dÃtecter les anomalies.</li>
<!--
-<li>Nous recommandons Privoxy comme proxy et antipub pour le Web, mais il n'est <a href="http://wiki.noreply.org/noreply/TheOnionRouter/PrivoxyPatches";>plus maintenu et a encore des bugs</a>, en particulier sous Windows. Pendant que nous y sommes, quelles informations ne sont pas protÃgÃes par Privoxy ? Quels sont les autres outils du mÃme type qui seraient plus sÃrs ?</li>
-<li>tsocks ne semble plus maintenu: nous avons rassemblà <a
-href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches";>plusieurs correctifs</a> qui doivent Ãtre appliquÃs. Est-ce qu'une personne pourrait nous aider à les faire ajouter en amont, et sinon pourrait commencer une nouvelle branche tsocks ? Nous l'aiderons.</li>
+<li>Pour l'instant, les descripteurs de services cachÃs sont stockÃs sur un
+petit nombre de serveurs de rÃpertoires seulement. Ceci est mauvais au niveau confidentialità des donnÃes privÃes et au niveau de la robustesse. Pour
+amÃliorer la robustesse, nous allons affaiblir encore la protection des donnÃes sur les descripteurs de services cachÃs,
+car nous allons devoir multiplier les miroirs des serveurs de repÃrtoires. IdÃalement, nous aimerions que le systÃme de stockage/recherche
+soit entiÃrement sÃparà des serveurs de rÃpertoires Tor. Le premier problÃme est que nous devons
+concevoir un nouveau format de description des services cachÃs
+a) qui soit ascii plutÃt
+que binaire pour en simplifier l'utilisation; b) qui garde chiffrÃe la liste des points d'entrÃe
+Ã moins que l'on ne connaisse l'adresse <tt>.onion</tt>, de sorte que le rÃpertoire ne
+puisse les lister; et c) qui autorise les rÃpertoires à vÃrifier la date et
+la signature d'un descripteur de service cachà de sorte que ces rÃpertoires ne puissent Ãtre bidouillÃs
+pour en do nner des faux. DeuxiÃmement, tout systÃme de stockage distribuÃ
+sÃr conviendra, du moment qu'il permette des mises à jour authentifiÃes. Mais pour autant
+qu'on le sache, aucune implÃmentation de DHT ne supporte de mises à jour authentifÃes.</li>
-->
-
-<li>Pour l'instant, les descripteurs de services cachÃs sont stockÃs sur un petit nombre de serveurs de rÃpertoires seulement. Ceci est mauvais au niveau confidentialità des donnÃes privÃes et au niveau de la robustesse. Pour amÃliorer la robustesse, nous allons affaiblir encore la protection des donnÃes sur les descripteurs de services cachÃs, car nous allons devoir multiplier les miroirs des serveurs de repÃrtoires. IdÃalement, nous aimerions que le systÃme de stockage/recherche soit entiÃrement sÃparà des serveurs de rÃpertoires Tor. Le premier problÃme est que nous devons concevoir un nouveau format de description des services cachÃs
-<ol type ="a">
-<li>qui soit ascii plutÃt que binaire pour en simplifier l'utilisation; <li>qui garde chiffrÃe la liste des points d'entrÃe à moins que l'on ne connaisse l'adresse <tt>.onion</tt>, de sorte que le rÃpertoire ne puisse les lister; et <li>qui autorise les rÃpertoires à vÃrifier la date et la signature d'un descripteur de service cachà de sorte que ces rÃpertoires ne puissent Ãtre bidouillÃs pour en do
- nner des faux.</li></ol> DeuxiÃmement, tout systÃme de stockage distribuà sÃr conviendra, du moment qu'il permette des mises à jour authentifiÃes. Mais pour autant qu'on le sache, aucune implÃmentation de DHT ne supporte de mises à jour authentifÃes.</li>
-
-<li>Les serveurs de sortie Tor ont besoin de faire de nombreuses rÃsolutions DNS en parallÃle. Mais gethostbyname() est mal conÃu --- il se bloque en attendant d'avoir terminà la rÃsolution d'une requÃte --- et donc, il exige d'avoir son propre thread ou processus. Et Tor est obligà d'avoir plusieurs threads dÃdiÃs aux rÃsolutions DNS. Il y a bien quelques bibliothÃques DNS asynchrones par-ci par-lÃ, mais historiquement elles sont buguÃes et abandonnÃes. Y en a-t-il qui soient stables, rapides, propres et libres (Rappelez-vous que Tor utilise OpenSSL, et que OpenSSL n'est (probablement) pas compatible avec la GPL, et donc que toute bibliothÃque GPL est exclue.) S'il en existe (ou si nous pouvons faire en sorte qu'il en existe), nous devrions les intÃgrer à Tor. Voir <a
-href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html";>le message de Agl</a> sur une approche possible. Voir aussi
-<a href="http://daniel.haxx.se/projects/c-ares/";>c-ares</a> et
-<a href="http://www.monkey.org/~provos/libdnsres/";>libdnsres</a>.
-</li>
-<li>Tor 0.1.1.x inclut le support d'accÃlÃrateurs matÃriels de chiffrage via OpenSSL. Cependant, personne ne l'a jamais testÃ. Est-ce que quelqu'un voudrait se procurer une carte et nous dire ce qu'il en est ?</li>
-<li>Ãtant donnà que les serveurs Tor doivent stocker et renvoyer chaque unità d'information traitÃe (cellule), les serveurs Tor à haut dÃbit finissent par utiliser des dizaines de Mo de mÃmoire uniquement pour la mÃmoire tampon. Nous avons besoin de meilleures descriptions de fonctionnement pour prÃvoir les variations de taille des tampons. Ceci pourrait peut-Ãtre ceci Ãtre modÃlisà à partir de la conception de la mÃmoire tampon du noyau Linux, dans lequel il y a de nombreuses petites mÃmoires liÃes les unes aux autres, plutÃt qu'avec des grosses mÃmoires monolithiques ?</li>
-
-<!--
-<li>D'ailleurs comment fonctionne ulimits sous win32 ? Nous avons des soucis, en particulier avec les anciennes versions de windows qui dÃpassent le nombre maximum de descripteurs de fichiers, la taille des mÃmoires de connexion, etc. (Nous devrions gÃrer WSAENOBUFS comme nÃcessaire, regarder l'entrÃe du registre MaxConnections,
-l'entrÃe MaxUserPort, et l'entrÃe TcpTimedWaitDelay. Nous devrions peut-Ãtre aussi proposer un moyen de les rÃgler selon les besoins de chacun. Voir <a
-href="http://bugs.noreply.org/flyspray/index.php?do=details&id=98";>le bug
-98</a>.)</li>
-<li>Correctifs aux scripts autoconf de Tor. PremiÃrement nous aimerions que notre autoconfigure.in sache faire de la cross-compilation, c'est à dire que nous sachions compiler Tor pour des plateformes obscures comme le Linksys WRTG54. DeuxiÃmement, nous aimerions que l'option with-ssl-dir dÃsactive la recherche des bibliothÃques ssl.</li>
--->
-
-<li>ImplÃmenter les requÃtes de DNS inverses dans Tor (dÃjà spÃcifià dans la section 5.4 de <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</li>
+<li>Tor 0.1.1.x inclut le support d'accÃlÃrateurs matÃriels de chiffrage
+via
+OpenSSL. Cependant, personne ne l'a jamais testÃ. Est-ce que quelqu'un voudrait se procurer
+une carte et nous dire ce qu'il en est ?</li>
<li>Faire une analyse de suretà de Tor avec <a
-href="http://en.wikipedia.org/wiki/Fuzz_testing";>du "fuzz"</a>. DÃterminer s'il existe dÃjà de bonnes bibliothÃques de fuzz pour ce que nous voulons faire. La cÃlÃbrità pour celui-lle grÃce à qui une nouvelle version pourra voir le jour !</li>
-<li>Dans quelle mesure est-ce difficile de modifier bind ou un proxy DNS pour rediriger les requÃtes à Tor via notre <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications";>extension de socks : tor-resolve</a>? Sous BSD, docks en est dÃjà capable. Que pensez-vous de l'idÃe de convertir les requÃtes UDP DNS en requÃtes TCP et de les envoyer à travers Tor ?</li>
-<li>Tor utilise TCP pour le transport et TLS pour le chiffrage des liens. C'est simple et efficace, mais cela implique que toutes les unitÃs (cellules) d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie que seuls des flux TCP peuvent Ãtre raisonnablement supportÃs. Nous avons dressà une <a
-href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP";> liste de raisons pour lesquelles nous n'avons pas bifurquà vers le transport par UDP</a>, mais ce serait bien de voir cette liste se raccourcir. Nous avons aussi proposà <a href="<svnsandbox>tor/doc/tor-spec-udp.txt">une spÃcification pour Tor et UDP</a> — lisez-la et faites-nous part de vos remarques et critiques, s'il-vous-plaÃt.</li>
-<li>Nous ne sommes plus trÃs loin d'avoir le support pour IPV6 entre les serveurs de sorties et les adresses finales. Si IPV6 vous tient à cÅur, partir de là est sans doute un premier pas.</li>
+href="http://en.wikipedia.org/wiki/Fuzz_testing";>du "fuzz"</a>. DÃterminer
+s'il existe dÃjà de bonnes bibliothÃques de fuzz pour ce que nous voulons faire. La cÃlÃbrità pour celui-lle
+grÃce à qui une nouvelle version pourra voir le jour !</li>
+<li>Tor utilise TCP pour le transport et TLS pour le chiffrage
+des liens. C'est simple et efficace, mais cela implique que toutes les unitÃs (cellules)
+d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et
+cela signifie que seuls des flux TCP peuvent Ãtre raisonnablement supportÃs. Nous avons dressà une <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP";> liste
+de raisons pour lesquelles nous n'avons pas bifurquà vers le transport par UDP</a>, mais ce serait
+bien de voir cette liste se raccourcir. Nous avons aussi proposà <a
+href="<svnsandbox>tor/doc/100-tor-spec-udp.txt">une spÃcification pour Tor et
+UDP</a> — lisez-la et faites-nous part de vos remarques et critiques, s'il-vous-plaÃt.</li>
+<li>Nous ne sommes plus trÃs loin d'avoir le support pour IPV6 entre les serveurs de sorties
+et les adresses finales. Si IPV6 vous tient à cÅur, partir de là est sans doute
+un premier pas.</li>
+<li>Quelque chose vous dÃplait ? Regardez la <a
+href="<svnsandbox>doc/design-paper/roadmap-2007.pdf">planification du dÃveloppement
+de Tor</a> pour plus d'idÃes.</li>
+<li>Vous ne voyez pas vos idÃes ici ? Nous en avons peut-Ãtre besoin ! Contactez
+nous et aidez.</li>
</ol>
<a id="Research"></a>
<h2><a class="anchor" href="#Research">Recherche</a></h2>
<ol>
-<li>"L'attaque par empreinte de sites": faire une liste de quelques centaines de sites populaires, en tÃlÃcharger les pages, et faire des "signatures" pour chaque site. Ensuite, observer le trafic d'un client Tor. L'analyse de ses rÃceptions de donnÃes donne rapidement une idÃe des sites qu'il visite. PremiÃrement, quelle est l'efficacità de cette attaque sur le code actuellement utilisà dans Tor ? Ensuite, tester les dÃfenses possibles : par exemple, changer la taille des cellules de Tor de 512 octets à 1024, utiliser des techniques de remplissage comme <a
-href="http://freehaven.net/anonbib/#timing-fc2004";>le lÃcher dÃfensif</a>, ou ajouter des dÃlais de trafic. Quel impact ces stratÃgies de dÃfense ont-elles, et, dans les cas oà elles sont efficaces en dÃfense, quel impact ont-elles en terme de perte d'utilisabilità de Tor (à quantifier) ?
-</li>
-<li>"L'attaque par corrÃlation des trafics aux extrÃmitÃs": par l'observation des trafics de Alice et Bob, il est possible de <a
-href="http://freehaven.net/anonbib/#danezis:pet2004";>comparer les signatures des trafics et d'en dÃduire qu'il s'agit du mÃme flux</a>. Jusqu'ici, Tor considÃre ce type d'attaque comme intrinsÃque et donc inÃvitable. Tout d'abord, est-ce rÃellement vrai ? Quelle quantità de trafic - et avec quelle distribution - est-elle nÃcessaire pour que l'adversaire soit certain d'avoir gagnà ? Est-ce qu'il existe des scÃnarios (par exemple avoir un trafic faible) pour ralentir cette attaque ? Est-ce que certains types de remplissage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>
-<li>"L'attaque par zones de routage" : la littÃrature spÃcialisÃe considÃre le plus souvent que le chemin rÃseau entre Alice et son noeud d'entrÃe (et entre le noeud de sortie et Bob) comme un lien unique dans un graphe. En pratique, cependant, le chemin passe par de nombreux systÃmes autonomes (Autonomous Systems : ASes), et <a
-href="http://freehaven.net/anonbib/#feamster:wpes2004";>il n'est pas inhabituel de retrouver le mÃme AS sur les chemins d'entrÃe et de sortie</a>.
-Malheureusement, pour prÃvoir prÃcisÃment si le chemin "Alice, entrÃe, sortie, Bob" sera dangereux, nous devrions tÃlÃcharger une zone de routage internet complÃte et faire dessus des calculs lourds. Est-ce qu'il existe des approximations utilisables, comme par exemple d'ignorer les adresses IP d'un rÃseau /8 ?</li>
-<li>Tor ne fonctionne pas trÃs bien lorsque les serveurs ont des bandes passantes asymÃtriques (par exemple cÃble ou DSL). Comme Tor a des connexions TCP sÃparÃes entre chaque saut, si les octets arrivent correctement mais que les octets sortants sont bloquÃs sur place, les mÃcanismes de refoulement de TCP ne retransmettent pas vraiment cette information aux flux entrants.
-Peut-Ãtre Tor devrait-il dÃtecter s'il perd beaucoup de paquets sortants, et limiter la vitesse du flux entrant pour rÃguler cela lui-mÃme ?
-Je peux concevoir un schÃma de type augmentation-descente dans lequel on choisit un dÃbit "sÃr", que l'on augmente jusqu'à perdre des paquets, puis qui redescend, puis qui rÃaugmente. Nous avons besoin de quelq'un-e de fort-e en rÃseau pour simuler ce fonctionnement et aider à concevoir des solutions. De maniÃre gÃnÃrale, l'Ãvaluation des pertes de performances d'un tel systÃme pourrait peut-Ãtre - dans le cas oà elles sont grandes - servir de motivation pour reconsidÃrer la question du transport UDP.
-<li>Un sujet lià est le contrÃle de congestion : notre systÃme actuel est-il suffisant pour un usage intensif ? Peut-Ãtre devrions-nous expÃrimenter des fenÃtres de taille variable plutÃt qu'à taille fixe ? C'est apparu assez efficace pour cette <a
-href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php";>expÃrience sur ssh</a>. Nous aurons à faire des mesures et des rÃglages, et peut-Ãtre une rÃvision de Tor si les rÃsulats sont bons.</li>
-<li>Pour permettre à des dissident-e-s de se connecter sans Ãtre bloquÃ-e-s par les pare-feu de leur pays, nous avons besoin de dizaines de milliers de relais et pas seulement de quelques centaines. Nous pourrions imaginer un client Tor graphique qui aurait un bouton "aidez la Chine" pour activer l'ouverture d'un port et le relai de quelques KB/s de trafic pour le rÃseau Tor. (Quelques KB/s ne devraient pas Ãtre trop pÃnibles et il y a peu de risque d'abus puisqu'il ne s'agirait pas de noeuds de sortie.) Mais comment distribuer la liste de ces clients volontaires aux bons dissidents de maniÃre automatique, tout en ne permettant pas aux pare-feux au niveau national de l'intercepter et de lister ces clients ? Probablement, il faut faire intervenir la confiance, au niveau humain.
-Voir notre <a
-href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China";>entrÃe dans la FAQ</a> à ce sujet, puis lire <a href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship";>la section sur la rÃsistance à la censure de anonbib</a>.</li>
-<li>Les circuits Tor sont construits saut par saut, donc en thÃorie nous pouvons faire sortir des flux au second saut, au troisiÃme, etc. Cela paraÃt bien car cassant l'ensemble des flux sortants qu'un serveur peut voir. Mais si nous voulons que chaque flux soit sÃr, le chemin "le plus court" devrait comporter au moins 3 sauts dans notre logique actuelle, et les sorties suivantes seraient encore plus lointaines. Nous devons Ãvaluer ce rapport performance/sÃretÃ.</li>
-<li>Il n'est pas difficile de provoquer un DoS sur les serveurs et les serveurs de rÃpertoires Tor. Est-ce que les puzzles de clients sont la bonne rÃponse ? Existe-t-il d'autres approches rÃalisables ? Il y a un bonus si elles sont rÃtro-compatibles avec le protocol actuel de Tor.</li>
+<li>"L'attaque par empreinte de sites": faire une liste de quelques
+centaines de sites populaires, en tÃlÃcharger les pages, et faire des
+"signatures" pour chaque site. Ensuite, observer le trafic d'un client Tor.
+L'analyse de ses rÃceptions de donnÃes donne rapidement une idÃe
+des sites qu'il visite. PremiÃrement, quelle est l'efficacitÃ
+de cette attaque sur le code actuellement utilisà dans Tor ? Ensuite, tester
+les dÃfenses possibles : par exemple, changer la taille des cellules de Tor de 512
+octets à 1024, utiliser des techniques de remplissage comme <a
+href="http://freehaven.net/anonbib/#timing-fc2004";>le lÃcher dÃfensif</a>,
+ou ajouter des dÃlais de trafic. Quel impact ces stratÃgies de dÃfense ont-elles,
+et, dans les cas oà elles sont efficaces en dÃfense, quel impact ont-elles
+en terme de perte d'utilisabilità de Tor (à quantifier) ?</li>
+<li>"L'attaque par corrÃlation des trafics aux extrÃmitÃs":
+par l'observation des trafics de Alice et Bob, il est possible de <a
+href="http://freehaven.net/anonbib/#danezis:pet2004";>comparer
+les signatures des trafics et d'en dÃduire qu'il s'agit du mÃme
+flux</a>. Jusqu'ici, Tor considÃre ce type d'attaque comme intrinsÃque
+et donc inÃvitable. Tout d'abord, est-ce rÃellement vrai ? Quelle
+quantità de trafic - et avec quelle distribution - est-elle nÃcessaire pour que l'adversaire
+soit certain d'avoir gagnà ? Est-ce qu'il existe des scÃnarios (par exemple avoir un trafic faible)
+pour ralentir cette attaque ? Est-ce que certains types de remplissage ou de modelage de trafic
+fonctionnent mieux que d'autres ?</li>
+<li>"L'attaque par zones de routage" : la littÃrature spÃcialisÃe considÃre
+le plus souvent que le chemin rÃseau entre Alice et son noeud d'entrÃe (et entre le noeud de sortie
+et Bob) comme un lien unique dans un graphe. En pratique,
+cependant, le chemin passe par de nombreux systÃmes autonomes (Autonomous Systems : ASes), et <a
+href="http://freehaven.net/anonbib/#feamster:wpes2004";>il n'est pas inhabituel
+de retrouver le mÃme AS sur les chemins d'entrÃe et de sortie</a>.
+Malheureusement, pour prÃvoir prÃcisÃment si le chemin "Alice, entrÃe,
+sortie, Bob" sera dangereux, nous devrions tÃlÃcharger une zone de routage
+internet complÃte et faire dessus des calculs lourds. Est-ce qu'il existe
+des approximations utilisables, comme par exemple d'ignorer les adresses IP d'un rÃseau /8 ?</li>
+<li>D'autres questions de recherche concernant la diversità gÃographique considÃrent
+la diffÃrence entre choisir un circuit efficace et en choisir un alÃatoire.
+Lisez l' <a
+href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf";>argumentation
+</a> de Stephen Rollyson sur comment eviter les nÅuds lents sans trop impacter
+l'anonymat. Cet axe de raisonnement nÃcessite davantage de travail et de
+rÃflexion, mais semble trÃs prometteur.</li>
+<li>Tor ne fonctionne pas trÃs bien lorsque les serveurs ont des bandes passantes
+asymÃtriques (par exemple cÃble ou DSL). Comme Tor a des connexions TCP sÃparÃes entre
+chaque saut, si les octets arrivent correctement mais que les octets sortants
+sont bloquÃs sur place, les mÃcanismes de refoulement de TCP
+ne retransmettent pas vraiment cette information aux flux entrants.
+Peut-Ãtre Tor devrait-il dÃtecter s'il perd beaucoup de paquets sortants,
+et limiter la vitesse du flux entrant pour rÃguler cela lui-mÃme ? Je peux concevoir
+un schÃma de type augmentation-descente dans lequel on choisit un dÃbit "sÃr",
+que l'on augmente jusqu'Ã perdre des paquets, puis qui redescend, puis qui rÃaugmente. Nous
+avons besoin de quelq'un-e de fort-e en rÃseau pour simuler ce fonctionnement et aider à concevoir
+des solutions. De maniÃre gÃnÃrale, l'Ãvaluation des pertes de performances
+d'un tel systÃme pourrait peut-Ãtre - dans le cas oà elles sont grandes -
+servir de motivation pour reconsidÃrer la question du transport UDP.
+<li>Un sujet lià est le contrÃle de congestion : notre systÃme
+actuel est-il suffisant pour un usage intensif ? Peut-Ãtre
+devrions-nous expÃrimenter des fenÃtres de taille variable
+plutÃt qu'Ã taille fixe ? C'est apparu assez efficace pour cette <a
+href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php";>expÃrience
+sur ssh</a>. Nous aurons à faire des mesures et des rÃglages, et peut-Ãtre
+une rÃvision de Tor si les rÃsulats sont bons.</li>
+<li>Pour permettre à des dissident-e-s de se connecter sans Ãtre bloquÃ-e-s
+par les pare-feu de leur pays, nous avons besoin de dizaines de milliers de
+relais et pas seulement de quelques centaines. Nous pourrions imaginer un client Tor graphique qui
+aurait un bouton "Tor pour la libertÃ" pour activer l'ouverture d'un port et le relai
+de quelques KB/s de trafic pour le rÃseau Tor. (Quelques KB/s ne devraient pas Ãtre trop
+pÃnibles et il y a peu de risque d'abus puisqu'il ne s'agirait pas de noeuds de
+sortie.) Mais comment distribuer la liste de ces clients volontaires aux
+bons dissidents de maniÃre automatique, tout en ne permettant pas aux
+pare-feux au niveau national de l'intercepter et de lister ces clients ? Probablement, il faut faire
+intervenir la confiance, au niveau humain. Voir notre <a href="<page documentation>#DesignDoc">document
+prÃliminaire sur la rÃsistance au blocage</a> et notre
+<a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China";>entrÃe
+dans la FAQ</a> Ã ce sujet, puis lire <a
+href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship";>la section
+sur la rÃsistance à la censure de anonbib</a>.</li>
+<li>Les circuits Tor sont construits saut par saut, donc en thÃorie nous pouvons
+faire sortir des flux au second saut, au
+troisiÃme, etc. Cela paraÃt bien car cassant l'ensemble des flux sortants
+qu'un serveur peut voir. Mais si nous voulons que chaque flux soit sÃr,
+le chemin "le plus court" devrait comporter au moins 3 sauts dans notre logique actuelle, et
+les sorties suivantes seraient encore plus lointaines. Nous devons Ãvaluer ce rapport
+performance/sÃretÃ.</li>
+<li>Il n'est pas difficile de provoquer un DoS sur les serveurs et les serveurs de rÃpertoires Tor. Est-ce
+que les puzzles de clients sont la bonne rÃponse ? Existe-t-il d'autres approches rÃalisables ? Il y a un bonus
+si elles sont rÃtro-compatibles avec le protocol actuel de Tor.</li>
</ol>
-<a href="<page contact>">Contactez-nous</a> si vous avez avancà sur ces points !
+<a href="<page contact>">Contactez-nous</a> si vous avez avancà sur
+ces points !
</div><!-- #main -->