> je pense toujours que si mettons 30% de la population dispose d'une bonne connection symmétrique, le débit dans ces réseaux devrait augmenter.
Clairement, oui... de toute façon, plus il y a de gens à les utiliser, plus les darknets collaboratifs auront de bande passante, hein ;)
J'illustrais surtout qu'à bande passante globalement disponible, avec le routage anonymisant, il faut vraiment choisir entre débit par utilisateur, et anonymat... et donc que, aussi pratique que ce soit (lorsque des sites merdent, ou sont refusés aux français, etc, je me sers de Tor, et en général, je finis par accéder à ce que je veux), ce n'est pas un remplacement à tout (pour le P2P de media, clairement, ce n'est pas génial).
> D'ailleurs je ne parle pas de tor mais plutôt de gnunet ou freenet, qui sont basés sur les mêmes principes, mais pour lesquels il n'y a pas besoin de "sortir", puisque l'information est stockée au sein du réseau lui-même.
Je connais beaucoup moins freenet (des éons que je ne l'ai pas testé... et la grosse flemme d'installer Java dans un conteneur OpenVZ, ce que j'ai lu promettant des problèmes avec la manière d'OpenVZ de partager la mémoire entre les VM, et les allocations apparemment massives des applis Java) et gnunet (essayé une fois quelques mois avant la sortie de Lenny - le paquet Debian bloquait toute la machine lors du script postinst, et je n'ai pas pris le temps de chercher plus loin depuis)... mais il y a aussi des services cachés dans Tor : on peut tout à fait y héberger des services à l'intérieur du darknet, sans avoir besoin de sortir du réseau [1].
N'empêche qu'il faut s'y déplacer, même si on n'en sort pas... et qu'un nœud lent pourrit la communication...
Les réseaux anonymisants sont tout à fait utiles, mais davantage en complément du Net classique qu'autre chose, m'est avis ; évidemment, plus de connexions symétriques changeraient la donne, mais un Net équitable n'a malheureusement pas l'air d'être une préoccupation de premier plan des acteurs-dissaïdeurs...
[^] # Re: Avènement des réseaux p2p anonymes et cryptés
Posté par Aefron . En réponse au journal [HADOPI] Avènement des réseaux p2p anonymes et cryptés. Évalué à 3.
Clairement, oui... de toute façon, plus il y a de gens à les utiliser, plus les darknets collaboratifs auront de bande passante, hein ;)
J'illustrais surtout qu'à bande passante globalement disponible, avec le routage anonymisant, il faut vraiment choisir entre débit par utilisateur, et anonymat... et donc que, aussi pratique que ce soit (lorsque des sites merdent, ou sont refusés aux français, etc, je me sers de Tor, et en général, je finis par accéder à ce que je veux), ce n'est pas un remplacement à tout (pour le P2P de media, clairement, ce n'est pas génial).
> D'ailleurs je ne parle pas de tor mais plutôt de gnunet ou freenet, qui sont basés sur les mêmes principes, mais pour lesquels il n'y a pas besoin de "sortir", puisque l'information est stockée au sein du réseau lui-même.
Je connais beaucoup moins freenet (des éons que je ne l'ai pas testé... et la grosse flemme d'installer Java dans un conteneur OpenVZ, ce que j'ai lu promettant des problèmes avec la manière d'OpenVZ de partager la mémoire entre les VM, et les allocations apparemment massives des applis Java) et gnunet (essayé une fois quelques mois avant la sortie de Lenny - le paquet Debian bloquait toute la machine lors du script postinst, et je n'ai pas pris le temps de chercher plus loin depuis)... mais il y a aussi des services cachés dans Tor : on peut tout à fait y héberger des services à l'intérieur du darknet, sans avoir besoin de sortir du réseau [1].
N'empêche qu'il faut s'y déplacer, même si on n'en sort pas... et qu'un nœud lent pourrit la communication...
Les réseaux anonymisants sont tout à fait utiles, mais davantage en complément du Net classique qu'autre chose, m'est avis ; évidemment, plus de connexions symétriques changeraient la donne, mais un Net équitable n'a malheureusement pas l'air d'être une préoccupation de premier plan des acteurs-dissaïdeurs...
[1] http://www.torproject.org/docs/tor-hidden-service.html.en