Stéphane Bortzmeyer a écrit 645 commentaires

Et en quoi est-ce que TLS va protéger la vie privée ? Il y aura la requête DNS, les adresses IP utilisées et même (cf. mon article, qui notait ce point du RFC) le fait que cette machine s'était déjà connectée… Bref, TLS ne protège que le contenu, ce qui est déjà pas mal mais n'est pas le sujet du RFC, qui se focalise sur les méta-données, bien plus dures à protéger.

DNSSEC garantit l'authenticité des requêtes, mais ne fait rien pour la confidentialité.

Quant à IPv6, non, il a pile la même sécurité qu'IPv4 http://www.bortzmeyer.org/ipv6-securite.html

Il faut lire le RFC (ou mon résumé) qui justement explique cela. Indication : il n'y a pas que les données, les méta-données sont très sensibles aussi.

Un exemple est fourni par IP lui-même. Le mode non-connecté fait qu'il faut mettre l'adresse IP source dans chaque paquet (il faut bien que les réponses et les avis de non-remise soient transmis). Donc, le destinataire connait l'adresse IP source. Ce n'était pas obligatoire. X.25 avait un autre système où le réseau établissait la connexion et où le destinataire ne connaissait pas forcément le numéro de l'appelant (merci à Rémi Desprès pour ses explications à ce sujet).

Mon but n'est pas de dire qu'il faut revenir à X.25 :-) simplement de montrer qu'il y a eu des choix, qu'ils n'étaient pas obligatoires (« une autre technique est possible ») et que ces choix ont des conséquences pour la vie privée. C'est le thème principal de ce RFC : un protocole n'est pas purement technique.

Autre exemple, le DNS : le résolveur transmet au serveur faisant autorité la totalité de la requête, pas juste le domaine pour lequel le dit serveur fait autorité. Le serveur de la racine sait ainsi qu'on regarde linuxfr.org. Il y a des bonnes raisons pour cela (le problème est en effet complexe, ici, la bonne raison, c'est le fait que le résolveur ne connaisse pas les "zone cuts") mais d'autres protocols faisaient différemment.

Le "il suffit" est trop court. Il faut aussi être sûr du logiciel, donc, au minimum, logiciel libre, sinon, aucune sécurité.

Oui, j'ai peut-être eu tort de mentionner PRISM, c'était pour attirer l'attention mais, en effet, techniquement, c'est un problème différent.

Par contre, c'est tout à fait faux de dire qu'il y a déjà "pas mal de matière sur le sujet [les protocoles]" ou alors il faut citer des références. Pour le DNS, par exemple, je n'ai jamais rien vu.

Enfin, "cryptage" n'est pas le bon mot http://www.bortzmeyer.org/cryptage-n-existe-pas.html

L'utilisation des backticks dans ce script m'interpelle. À quoi peuvent-ils bien servir dans ce cas ?

Mais je ne crois pas que les créateurs de SeenThis l'aient jamais présenté comme un Twitter-Like, complet avec toutes ses fonctions, y compris la porte vers PRISM. La dépêche originale de cette discussion parlait effectivement de Twitter mais c'est maladroit et cela ne se retrouve pas sur le site de SeenThis.

Oui, ce serait un vrai truc intéressant. Yakafokon.

Non, pas du tout, l'objectif n'était pas de copier Twitter. Déjà, c'est du shortblogging, pas du microblogging. Ensuite, c'est plus orienté Web qu'API. Et il doit y avoir plein d'autres différences. À commencer par la plus énorme : les conditions d'utilisation. Lisez-les avant d'utiliser Twitter.

Un article de chercheurs intéressant, qui explore les mêms thèmes : http://arxiv.org/abs/1202.4503

L’article « A Critical Look at Decentralized Personal Data Architectures » est un court résumé des problèmes que pose la conception d’un rézosocio décentralisé ou réparti. Les auteurs notent à juste titre que le problème est difficile et que les projets issus d’un bistrot et spécifiés en cinq minutes sur un coin de table n’avaient aucune chance d’affronter réellement Facebook ou Twitter. L’article décrit bien ces difficultés et les problèmes que cela pose (dans mon exposé à Pas Sage en Seine, je mentionnais uniquement le problème de la découverte mais il y en a d’autres). Ils notent également que les propriétés qu’on attend d’un rézosocio sont souvent contradictoires et qu’il va falloir faire des choix.

Les auteurs critiquent à juste titre la confusion fréquente qui est faite entre caractéristiques techniques d’un système et les valeurs qu’on défend.

L’article étant assez court, pas mal de points ne sont traités que sommairement. Par exemple, les auteurs critiquent les systèmes décentralisés comme obligeant M. Michu a installer et à gérer son propre serveur, oubliant complètement qu’on peut parfaitement utiliser des serveurs gérés par d’autres (associations, entreprises à but lucratif, groupes de copains, etc). Tous les systèmes décentralisés (à commencer par le courrier électronique) avaient pourtant cette possibilité depuis longemps.

L’article erre aussi parfois vers la caricature lorsqu’il explique qu’on ne peut jamais avoir un contrôle complet sur ses données, laissant entendre que, dans ce cas, autant laisser tomber et aimer Facebook. L’idée qu’on puisse vouloir limiter les dégâts (sans pour autant avoir un contrôle complet) ne semble pas mentionnée.

Autre manque, l’idée d’éducation et d’évolution. Pour les auteurs, la mentalité actuelle de M. Michu semble une loi naturelle, non susceptible de changement (« M. Michu s’en fiche de la vie privée »).

« On est sur le web, il faut faire court » On n'a pas la même conception du Web. La page « Seenthis, c'est quoi » fait 5500 caractères. Si c'est trop long à lire, c'est que l'humanité est foutue et doit être remplacée par une espèce supérieure.

Non, SeenThis a une architecture centralisée. Il n'est pas prévu de communication, à part celle que permet déjà le Web (les liens). Le cahier des charges de SeenThis n'était pas du tout de faire une Nième tentative ratée de rézosocio décentralisé.

Excellente idée (XMPP). J'attends le code source avec impatience.

J'attends avec impatience les superapplications Web libres qui vont, je n'en doute pas, être développées avec ces merveilleuses technologies.

Comme je ne programme pas du tout en PHP, je ne vais pas répondre sur la technique mais sur le projet : SeenThis est avant tout un projet éditorial. Son but est le contenu, l'interaction, etc. Les auteurs disent ouvertement que ce n'est pas le code qui les intéresse.

À mon humble avis, il serait donc bon de ne pas discuter que de la technique mais aussi des choix sociaux, de l'interaction etc.

Notez qu'il y a une discussion (critique) de cet article et surtout de ses commentaires sur SeenThis http://seenthis.net/messages/154404

Une très bonne analyse juridique, montrant notamment que l'avocate de Linkeo ne s'y connait pas mieux en droit que Linkeo en sites Web.

Non, les URI "ni" ne sont pas forcément des URL. Ils peuvent l'être (si on met l'autorité) mais ce n'est pas obligatoire.

Et le but est justement de faire mieux que les URN. Ceux-ci ne sont pas « actionnables », on ne peut pas s'en servir pour récupérer une ressource. C'est bien pour cela que les URN ont eu peu de succès en pratique. (Avant les "ni", il y avait eu une proposition de faire la même chose avec des URN, draft-thiemann-hash-urn, mais elle n'avait pas abouti.)

L'article de l'Usine Nouvelle est médiocre. Il s'attaque à une exagération (fin de l'Internet, on va tous mourir) pour passer à une autre (il ne s'est rien passé, tout a été inventé, on vous ment).

La réalité est sans doute plus simple mais apparemment trop nuancée pour certains : il y a bien eu une attaque de grande ampleur, elle a impacté Cloudflare et donc ses clients, le reste de l'Internet a continué à vivre. Et le marketeux de Cloudflare a trouvé malin d'exagérer (exagérer, pas inventer) pour rapporter du business à sa boîte.

Google, ce ne sont pas des tanches. Oui, ils connaissaient le problème et ont documenté leurs solutions :

https://developers.google.com/speed/public-dns/docs/security

Et après, il se moque de M. Michu qui a mis son courrier chez Gmail ? Pas très cohérent.

Cf. la discussion sur le DNS dans l'article de départ (très intéressant, cet article). Évidemment, si on active le service de courrier électronique, le logiciel mettra un MX dans la zone. Évidemment, si on active le service de messagerie instantanée, il mettra un SRV dans la zone.

J'ai quand même un peu l'impression (arrêtez-moi si je me trompe) que pas mal de gens qui commentent n'ont pas lu l'article de départ.

Je n'ai jamais envisagé comme unique solution l'hébergement à la maison, avec un ADSL lent et une adresse marquée comme "résidentielle". J'ai au contraire longuement détaillé l'autre possibilité, celle d'un hébergement sur une machine d'un fournisseur IaaS. Le problème de l'adresse IP disparait, dans ce cas (ainsi que plusieurs autres répétés ici).

Il ne fait apparemment que serveur de fichiers et blog (pas courrier ou IM).

Je comprends cette motivation, je suis pareil :-) Mais la fiabilité et la sécurité d'une machine peu administrée nécessitent une politique plus restrictive. (Après, les hackers pourront toujours faire ce qu'ils veulent, c'est du logiciel libre. Mais il faut que ce soit clairement dit que ce n'est pas le fonctionnement normal.)