[or-cvs] Added more French translations

[phobos@xxxxxxxx]

Update of /home/or/cvsroot/website/fr
In directory moria:/tmp/cvs-serv11407

Added Files:
	donate.wml people.wml volunteer.wml 
Log Message:
Added more French translations


--- NEW FILE: donate.wml ---
## translation metadata
# Based-On-Revision: 1.18
# Last-Translator: isydor@xxxxxxxxxx

#include "head.wmi" TITLE="Dons !"

<div class="main-column">

<h2>Donnez au projet Tor!</h2>
<hr />

<p>
Si vous utilisez Tor et souhaitez aider à son développement, pensez à faire un don au projet.
</p>

<p>
Depuis Octobre 2005, l'EFF n'a plus de ressources pour financer le Projet Tor. Votre don aidera Roger et Nick à se concentrer sur le développement de Tor plutôt qu'à faire la chasse aux mécènes et à devoir passer du temps dans d'autres emplois. <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#Funding";>Aidez-nous</a> à garder le projet Tor actif !
</p>

<form id="subscribe" action="https://www.paypal.com/cgi-bin/webscr"; method="post">
  <p>
Le meilleur moyen de nous soutenir est de devenir un "membre du projet Tor" en effectuant un <b>versement mensuel</b>. Des dons suffisants nous permettent de nous inquiéter moins des finances et de nous concentrer davantage sur le développement. Vous pouvez devenir membre en cliquant sur l'un de ces boutons (Vous aurez besoin d'un compte <a href="http://paypal.com/";>PayPal</a>):<br />
<input type="radio" name="a3" value="50.00" />$50
<input type="radio" name="a3" value="20.00" checked="checked" />$20
<input type="radio" name="a3" value="10.00" />$10
<input type="radio" name="a3" value="5.00" />$5
<input type="hidden" name="p3" value="1" />
<input type="hidden" name="t3" value="M" />
<input type="hidden" name="sra" value="1" />
<input type="hidden" name="src" value="1" />
<input type="hidden" name="no_shipping" value="1" />
<input type="hidden" name="no_note" value="1" />
<input name="submit" type="submit" class="button" value="Don!" />
<input type="hidden" name="cmd" value="_xclick-subscriptions" />
<input type="hidden" name="business" value="donations@xxxxxxxxxxxxx" />
<input type="hidden" name="item_name" value="Tor Project Membership" />
<input type="hidden" name="return" value="http://tor.eff.org/";>
<input type="hidden" name="cancel_return" value="http://tor.eff.org/donate";>
</p>
</form>

<form id="donate" action="https://www.paypal.com/cgi-bin/webscr"; method="post">
  <p>Vous pouvez aussi faire un <b>don unique</b> (via PayPal, mais ne nécessitant pas de compte):<br />
<input type="radio" name="amount" value="100.00" />$100
<input type="radio" name="amount" value="50.00" />$50
<input type="radio" name="amount" value="20.00" checked="checked" />$20
<input type="radio" name="amount" value="10.00" />$10
<input type="radio" name="amount" value="" />autre
<input type="hidden" name="no_shipping" value="1" />
<input name="submit" type="submit" class="button" value="Don!" />
<input type="hidden" name="cmd" value="_xclick" />
<input type="hidden" name="business" value="donations@xxxxxxxxxxxxx" />
<input type="hidden" name="item_name" value="Tor" />
<input type="hidden" name="return" value="http://tor.eff.org/";>
<input type="hidden" name="cancel_return" value="http://tor.eff.org/donate";>
</p>
</form>

<p>Vous pouvez faire un don déductible d'impôts <b> -- ATTENTION : nous - traducteurs - n'avons pas encore vérifié si c'est valable en dehors des USA --</b> par <b>chèque ou mandat</b> à l'ordre de l'Electronic Frontier Foundation, qui a accepté de recevoir les dons pour le projet Tor. N'oubliez pas de mentionner "Tor donation" sur le chèque <i>et</i> l'enveloppe. L'EFF vous renverra un accusé de réception pour votre déclaration d'impôt si vous donnez votre adresse. Pour des dons de 65$ et plus, l'EFF ajoutera un <a href="http://tor.eff.org/tshirt.html";>éclatant t-shirt Tor vert</a> si vous le demandez &mdash; n'oubliez pas de préciser la taille (S/M/L/XL/XXL), ainsi qu'un second choix de taille si la première n'est pas disponible, et une adresse pour l'envoyer. Envoyez vos dons à :<br />
EFF<br />
Tor donation<br />
454 Shotwell St.<br />
San Francisco, CA 94110<br />
</p>

<p>Les dons importants sont évidemment les plus utiles. Nous acceptons aussi les <a href="http://2827792.e-gold.com/";>e-gold</a> à présent. Si vous préférez un autre moyen de faire un don (par exemple un virement banquaire à l'européenne), <a href="mailto:donations@xxxxxxxxxxxxx";>dites-le nous</a> et nous trouverons un moyen.
</p>

  </div><!-- #main -->

#include <foot.wmi>
--- NEW FILE: people.wml ---
## translation metadata
# Based-On-Revision: 1.5
# Last-Translator: isydor@xxxxxxxxxx

#include "head.wmi" TITLE="Auteurs"

<div class="main-column">

<h2>Tor: Auteurs</h2>
<hr />

<p>Le Projet Tor est un projet du <a href="http://freehaven.net/";>Free Haven Project</a> conçu comme un élément de construction pour des systèmes de communication et de publication anonymes et anti-censure. Tor est développé par <a href="http://freehaven.net/~arma/";>Roger Dingledine</a> et <a href="http://www.wangafu.net/~nickm/";>Nick Mathewson</a>, avec l'aide de nombreux volontaires internautes.</p>

<p>Tor a été conçu par Roger Dingledine et Nick Mathewson de Free Haven et <a href="http://www.syverson.org/";>Paul Syverson</a> du <a href="http://www.nrl.navy.mil/";>Naval Research Laboratory</a> (Laboratoire de Recherches Maritimes), et est basé sur l'idée de <a href="http://www.onion-router.net/";>routage en oignon</a> développée initialement au NRL (LRM).</p>

  </div><!-- #main -->

#include <foot.wmi>
--- NEW FILE: volunteer.wml ---
## translation metadata
# Based-On-Revision: 1.23
# Last-Translator: isydor@xxxxxxxxxx

#include "head.wmi" TITLE="Contribuer"

<div class="main-column">

<!-- PUT CONTENT AFTER THIS TAG -->
<h2>Quatre 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,<a href="<page donate>"> prenez s'il vous plaît un moment pour faire un don et aider les prochains développements de Tor</a>. Et 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 WindowsXP, car nous essayons d'utiliser des centaines de sockets alors que le noyau de Windows ne semble pas capable de faire ça. <a href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems";> S'il vous plaît, 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 d'un moyen d'intercepter les 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.
-->
<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>
<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 perdre un aller-retour complet dans Tor à 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 des taux variables selon les moments de la journée. Plutôt que de coder ça 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 largeur de la bande passante. Potentiellement ce serait un script lancé par cron, ou se lancerait à certains heures (ce qui est certainement plus portable). Est-ce que quelqu'un pourrait faire ça pour nous, nous l'ajouterons à <a href="<cvssandbox>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 depuis un noeud de sorte donné</a>, mais ce serait pratique de n'avoir qu'à spécifier un pays, et que le serveur de sortie soit choisi automatiquement. Le meilleur plan est de récupérer le répertoire de Blossom, et d'utiliser un client local 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 fasse ce qu'il faut ensuite.</li>
<li>En parlant de localisation géographique, quelqu'un devrait faire une carte de la Terre avec un point pour chaque serveur Tor. Il y a des points de bonus si elle se met à jour dynamiquement à 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 est-ce que ça jouerait sur la confidentialité, et par ailleurs avons-nous d'autres choix 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 à l'aide de javascript, java, activex, flash, etc, s'ils ne les désactivent pas. Est-ce qu'il existe 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>
S'il vous plaît, aidez Matt Edman a documenter et faire des how-tos 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 <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO";>les programmes de la liste que nous avons dressée et qui contient</a> ceux qui peuvent être configurés pour utiliser Tor.</li>
<li>Nous avons besoin d'une meilleure documentation traitant de l'interception dynamique de connexions et leur envoi à travers Tor. tsocks (Linux), dsocks (BSD),et freecap (Windows) semblent être de bons candidats.</li>
<li>Nous avons une liste gigantesque 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 ? Aidez-nous s'il vous plaît à les tester et à documenter les résultats.</li>
<li>Aidez-nous à traduire le site et la documentation dans d'autres langues. Allez voir <a href="<page translation>">règles de traduction</a> si vous voulez le faire. Nous avons besoin de personnes pour maintenir les versions existantes en Italien, Français et Suédois - regardez la page <a href="<page translation-status>">d'état des traductions</a>.</li>
</ol>

<a id="Coding"></a>
<h2><a class="anchor" href="#Coding">Conception et Code</a></h2>
<ol>

<!--
<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>Actuellement les descripteurs de services cachés sont stockés uniquement sur quelques serveurs de répertoires. C'est mauvais pour la protection des données privées et pour la robustesse. Pour améliorer la robustesse, nous allons devoir affaiblir encore la protection des données sur les descripteurs de services cachés en multipliant les miroirs des serveurs de repértoires. Idéalement nous aimerions séparer entièrement le système de stockage/recherche 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 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>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 --- ainsi il exige d'avoir son propre thread ou processus. Et Tor est forcé à 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.) Si c'est le cas (où si nous pouvons faire en sorte que ça le soit), nous devrions les intégrer à Tor. Voir <a
href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html";>le message de Agl</a> à propos d'une approche potentielle. 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. Personne ne l'a jamais testé, cependant. Est-ce qu'une personne voudrait bien nous envoyer une carte pour nous dire ce qu'il en est ?</li>
<li>Comme les serveurs Tor doivent stocker et renvoyer chaque unité d'information traitée, les serveurs Tor à haut débit finissent par utiliser des dizaines de Mo de mémoire rien que pour la mémoire tampon. Nous avons besoin de meilleures descriptions de son fonctionnement pour prévoir ses variations de taille. Peut-être que ça peut se modéliser à 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&amp;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="<cvssandbox>tor/doc/tor-spec.txt">tor-spec.txt</a>).</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. Deviens célèbre en étant cité-e pour la sortie d'une nouvelle version gràce à toi !</li>
<li>Dans quelle mesure est-ce difficile de modifier bin 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>? 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 d'un lien sont mises en attente lorsqu'un seul paquet est perdu, et cela signifie que nous ne pouvons raisonnablement supporter que des flux TCP. 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 diminuer de taille. Nous avons aussi proposé <a href="<cvssandbox>tor/doc/tor-spec-udp.txt">une spécification pour Tor et UDP</a> &mash; critiquez-là 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 vous tenez beaucoup à IPV6, commencez par aider sur ce sujet.</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 essayer 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 ont en défense et aussi sur la perte d'utilisabilité (à quantifier) de Tor en prenant les cas où la défense est efficace ?
</li>
<li>"L'attaque par comparaison 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 accepte cela comme intrinsèque et donc inévitable. Tout d'abord, est-ce vrai ? Quelle quantité de trafic - et avec quelle distribution - est nécessaire avant 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 bourrage ou de modelage de trafic fonctionnent mieux que d'autres ?</li>
<li>"L'attaque par zones de routage" : Le plus souvent dans la littérature il est considéré que le chemin réseau entre Alice et son noeud d'entrée (et entre le noeud de sortie et Bob) est 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 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 assymé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.
Sans doute Tor devrait détecter lorsqu'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 redescend, puis 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 : Est-ce que notre système actuel est suffisant pour un usage intensif ? Peut-être que nous devrions expérimenter des fenêtres de taille variable plutôt que de taille fixe ? Ça a semblé 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 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 régler ça 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 lors du second saut, du troisième, etc. Ça paraît bien car ça casse 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 selon notre logique, et les sorties suivantes seront toutes plus lointaines. Nous devons évaluer ce rapport performance/sûreté.</li>
<li>Il n'est pas difficile de provoquer un DoS sur les serveur et les serveurs de répertoires Tor. Est-ce que les puzzles de clients sont la bonne réponse ? Qu'est-ce qu'il existe comme 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!

  </div><!-- #main -->

#include <foot.wmi>