Outils pour utilisateurs

Outils du site


kopimonk

KopiMonk

Au moment où beaucoup réfléchissent à automatiser les fermes d'autoblogs, le temps est venu que je diffuse un peu ma réflexion quant à un éventuel successeur de VroumVroumBlog.

Il n'y a, à l'heure actuelle, rien d'implémenté.

Cette page est largement incomplète: J'ai également une mindmap très détaillée sur cette réflexion que je n'ai pas encore publiée.

Notez aussi que cette page sera probablement amenée à changer d'URL. Consulter l'accueil du wiki.

Pourquoi le nom “KopiMonk” ? C'est une référence au Kopimisme et au fait que nous devenons, de plus en plus, des moines (Monk) copistes numériques. Nous nous attelons à la tâche afin que les écrits ne disparaissent pas. (Si vous avez une meilleure idée de nom, n'hésitez pas à la suggérer.)

Réflexion

Même si en soit la version actuelle (série 1.x de moi, et 2.x de BohwaZ) de VroumVrouBlog marche bien, il y a certains points qu'elle ne résous pas.

  • Source unique: Un autoblog s'alimente à une source unique. Si le site disparaît (pression sur hébergeur, blogueur ou le registrar (nom de domaine)), le site peut disparaître. Plus de source, plus de nouvelle publication. L'autoblog est mort, l'auteur est muselé.
  • Lourdeur de la mise en place des autoblog. Même s'il n'y a que 2 fichiers à mettre, c'est une opération manuelle et “lourde”. Cela ne facilite pas la réplication à grande échelle.
  • Pas d'anonymat/pseudonymat possible. Les auteurs peuvent être identifiés par le simple fait qu'ils ont un site web (nom de domaine, hébergeur…).

Voici comment j'entends résoudre ces problèmes:

Le nouveau (appellons-le KopiMonk en attendant de trouver un meilleur nom) garde les fonctionnalités de VVB (réplication de flux RSS), mais propose aussi un autre système de publication/réplication. Je m'explique:

  • Chaque auteur possède une clé publique OpenPGP avec laquelle il signe ses articles.
  • Cette clé permet de s'assurer qu'un article a bien été écrit par un auteur donné (même si celui-ci est anonyme). On a la garantie de l'authenticité d'un article.
  • Chaque KopiMonk peut choisir de répliquer les articles de plusieurs auteurs simplement en important leur clé publique (un simple copier-coller, valider).
  • De là, les KopiMonks reliés entre eux répliquent les articles des auteurs qu'ils acceptent.
  • Chaque KopiMonk possède une interface permettant à un auteur de publier un article signé (Le KopiMonk n'acceptera bien sûr l'article que s'il est correctement signé par un auteur qu'il accepte).
  • Chaque KopiMonk propose une vue affichant tous les articles d'un auteur donné.

Conséquences pratique:

  • Un auteur n'a plus besoin d'avoir un site web à lui pour publier. Il n'a plus besoin d'avoir un nom de domaine ni même un hébergeur. Il peut envoyer son article sur n'importe quel KopiMonk acceptant sa clé, et il sera répliqué partout.
  • L'auteur peut être anonyme, n'a plus besoin d'avoir un hébergeur précis, ni un nom de domaine et peut poster à travers TOR, ce qui empêche de le tracer.
  • Un article publié sur un KopiMonk est automatiquement répliqué: Les flux d'articles d'un auteur sont visibles sur plusieurs sites/domaines différents. La censure devient difficile (comme pour VVB).
  • Pour aller à l'extrême, on pourrait même imaginer que les KopiMonks fassent des recherches sur Google pour trouver des articles signés. L'auteur pourrait ainsi même poster sur pastebin: L'article serait repris dans les KopiMonks.

Les soucis que je vois actuellement avec cette approche:

  • Le blogueur moyen ne saura pas forcément manipuler des clés OpenPGP. Il faudrait proposer une interface simple de création de clés. (PS: Il existe des libs javascript capable de manipuler des clés OpenPGP, cf. PrivacyBox.de)
  • Il faut trouver des libs de crypto asymétrique qui marcheraient dans php (Ce qui doit réduire d'autant le nombre d'hébergeurs chez qui ça marcherait, étant donné que la plupart n'ont pas gnupg installé ou accessible).
  • Quid des attachements ? (images, pdf…). Texte riche ? (Markdown, autre ?)
  • Quid des modifications d'article ? Suppression par l'auteur ? (Est-ce souhaitable ? Si l'auteur peut supprimer un article, il pourrait être forcé à le supprimer.)

Je ne sais pas à quel point mon idée est réaliste (surtout le fait de manipuler des clés OpenPGP, ce qui pourrait rebuter un bon nombre d'auteurs).

Notes:

  • En cas d'injonction, l'admin d'un KopiMonk doit avoir la possibilité de supprimer virtuellement un article (en blacklistant par exemple le hash de l'article).
  • On pourrait imaginer un vizhash de l'empreinte de la clé OpenPGP pour avoir une icône identifiant l'auteur.
  • Pourrait-on imaginer d'inclure du DHT là dedans ? (plutôt que juste choisir de répliquer un auteur, l'admin alloue une quantité définie d'espace de stockage qui participerait à l'espace de stockage global).
  • On pourrait peut-être envisager un stockage à l'aveugle des articles comme Freenet ?
  • Chaque KopiMonk pourrait avoir sa PrivacyBox.de, ce qui permettrait aux auteurs de publier en passant par ce site.

Concernant les flux RSS traditionnels:

  • Il serait intéressant d'inclure le protocole XSAF.
  • Un admin pourrait décider de se synchroniser avec un ou plusieurs autre KopiMonk: Tout flux RSS ou auteur ajouté à ces KopiMonks serait ainsi automatiquement ajouté au sien.

Discussion

Yoplaid, 2012/08/27 13:56

J'suis pas spécialiste mais si je peut contribuer…

Pour l'open PGP et une interface, jette un coup d'oeil : http://crypto.stanford.edu/sjcl/

pour la crypto côté serveur, peut être openssl … ou bien encore http://packages.zendframework.com/docs/latest/manual/en/modules/zend.crypt.public-key.html

pour les attachements ? selon la taille, pourquoi ne pas simplement les encoder en base64 ?

pour les modifications d'articles, solution toute simple, avoir plusieurs révision d'un même article un peu comme un wiki ? ainsi l'article peut être mis à jour mais les anciennes versions non modifiable.

Un peu chiant ton antispam ;)

Sébastien SAUVAGE, 2012/08/27 14:04

Pour SJCL, je connais, c'est ce que j'utilise dans ZeroBin, mais la branche principale ne fait pas de crypto asymétrique. Et la branche de dev ne supporte que ECC, ce qui ne marchera pas avec OpenPGP (qui utilise DH/DSS et RSA).

Pour le module Zend, visiblement ils utilisent l'extension OpenSSL de php. Pourquoi pas. Ou alors utiliser directement le module OpenSSL de php: http://php.net/manual/fr/book.openssl.php

En fait, pour les attachements, je verrais bien les articles sous forme de fichier zippé contenant tout (article (txt, ou html), images, etc.) ce qui permet d'avoir en un package complet: l'article et ses attachements, le tout facile à signer.

Le coup des révisions, c'est effectivement à mon avis la meilleure idée. Toujours présenter par défaut la dernière version de l'article, mais permettre la consultation des versions précédents (l'idée m'avait déjà chatouillé dans VVB).

yoplaid, 2012/08/28 20:37

En réfléchissant au format zip, je vois quelques problèmes en perspective notamment concernant le stockage. Si j'ai bien compris le KopiMonk qui se synchronise récupère le zip, le dézippe pour exploiter le contenu, mais il doit conserver le zip afin de pouvoir le propager. Donc tel que je le vois il faut conserver l'article sous 2 formats, donc utilisation presque doublé de l'espace disque. (à moins que tu as une autre idée en tête…)

Moi j'imagine plus l'article dans un conteneur texte avec l'article en texte(ou html ou bbcode…) et les médias (images je suppose) en base64. Donc 1 seul fichier pour la réplication / exploitation. J'y vois des avantages, limitation des requêtes en exploitation, contenu directement accessible (ssh, notepad, pour décoder du base64 suffit de googler pour trouver des outils on/off-line), traitement côté serveur plutôt light, utilisation de parser pour signaler un éventuel spam/script …

Pour les inconvénients, je dirais que si les médias sont lourds (en poids) le base 64 alourdit un peu plus le poids (sur certains média j'ai constaté jusqu'à 170%), pour des médias vidéos/audio: pas testé mais je ne le sens pas trop, nouvelle problématique concernant l'historique du contenu (bien que j'ai une idée en tête) …

jbfavre, 2012/08/27 14:20

3 problèmes, après une très (trop) rapide lecture: * Chaque auteur possède une clé publique OpenPGP avec laquelle il signe ses articles. * Cette clé permet de s'assurer qu'un article a bien été écrit par un auteur donné (même si celui-ci est anonyme). On a la garantie de l'authenticité d'un article. Quel mécanisme sera utilisé pour remonter à l'auteur en partant de la clef ? Si je créée une clef “au nom de” sebsauvage, comment sera-t-elle détectée comme fausse ?

* De là, les KopiMonks reliés entre eux répliquent les articles des auteurs qu'ils acceptent. Comment relier les KopiMonks entre eux ? Découverte auto ? Enregistrement manuel de la part de chaque admin ? Si le réseau de KopiMonks grossit vite, ça fait être une horreur.

Enfin, mais ce problème n'est pas nouveau, c'est bien gentil de répliquer tout ça, mais ça pose une question: OK, mon article est répliqué sur tout l'internet, c'est trop cool… mais comment les gens trouveront les URL alternatives ?

Une réflexion maintenant: tout ce mécanisme de réplication et tout le toutim, on pourrait peut-être s'inspirer de ce qui existe déjà: StatusNet par exemple avec OStatus, Salmon et SHA-1. Également, on pourrait (devrait ?) regarder du côté de choses comme ActivityStream et consort

Sébastien SAUVAGE, 2012/08/27 14:38

Les clés devront être obtenues de personnes de confiance, éventuellement vérifiées par les moyens traditionnels. Ceci dit, le mécanisme de web-of-trust convient parfaitement: Si je vois qu'une clé a été acceptée par x autres KopiMonk (auxquel je fais confiance), je peux à mon tour accorder confiance en cette clé. On pourrait imaginer de mettre une note de confiance aux différents KopiMonks auxquels on se relie, et n'accepter automatiquement les clés que si la confiance dépasse un certain seuil (comme ce qui se fait en gestion des clés avec OpenPGP). En prime, rien n'empêche d'accepter des clés nouvelles et non vérifiées d'auteurs anonyme (au bon vouloir des admins).

Autre façon de faire: Si Mitsukarenai accepte une clé, je serais d'avis de l'accepter aussi immédiatement. On pourrait ainsi mettre en place une acceptation automatique des clés en flaguant certains KopiMonk comme “de confiance”.

Pour relier les KopiMonk entre eux ? Par peer exchange, ça me semble une bonne idée (ça reste léger si on limite le nombre de peers dans la liste.). Il ne faut bien entendu pas que chaque instance envoie ou aille lire toutes les autres, ça serait l'horreur. Un protocole naïf pourrait peut-être suffire (prendre 5 hôte au hasard dans la liste reçue par peer exchange pour aller échanger les données). Reste encore le problème du bootstraping (Il ne faut pas que mon site soit le point central de démarrage du protocole). Pourquoi pas tout simplement googler ?

comment les gens trouveront les URL alternatives ?
Je n'ai pas encore la réponse. On pourrait imaginer un message indiquant que l'article n'est pas trouvé, et proposerait la redirection vers 5 autres peers ayant (peut-être) l'article (sachant que chaque article aurait un identifiant unique).

on pourrait peut-être s'inspirer de ce qui existe déjà
Oui il y a sûrement plein de protocoles existants qu'on pourrait réutiliser.

Bref… il y a pas mal de pistes à explorer, d'idées à reprendre… et beaucoup de problèmes à résoudre :-)
Je l'ai dit, ce n'est pas simple.

Yoplaid, 2012/08/27 17:16

J'ajoute mon grain de sel pour la propagation d'articles / découverte de KopiMonk : 6 KopiMonk (A,B,C,D,E,F)

chaque KopiMonk doit pouvoir gérer une liste des KopiMonk qu'il connait et la date de la dernière exploration qu'il en a fait.

A connait 4 KopiMonk B, C, D, E. Sur les explorations que A à fait, A date du plus ancien au plus récent B,C,D,E.

A interroge B (la plus anciennes exploration) : http/example.com/?status=“timestamp du dernier article de A UTC” B retourne (en json/XML… par exemple)

  1. le timestamp (UTC) du dernier article de B ou la liste de tout les articles plus récents que le timestamp de A (si article + récent : A récupère les articles postérieurs à son timestamp)
  2. B peut aussi retourné sa liste d'auteur web-of-trust
  3. la liste datée des X derniers KopiMonk que B a explorés depuis le timestamp de A (D,E)(A met à jour ça liste en fonction de la liste de B) (on peut ajouter leur statuts (200,40X,50x) pour un créer un “service de santé du réseau KopiMonk”)
  4. la liste des nouveaux KopiMonk non exploré par B ou récemment ajouté a la liste de B (disons que F viens d'être ajouté à la liste de B) (A ajoute les nouveaux KopiMonk à sa liste avec un timestamp @ 0 UTC)
  5. B si il ne connait pas A, peut le rajouter à une liste alternative pour un contrôle manuel avant de l'intégrer au réseau KopiMonk (ce qui n'empêche pas B de proposer ses articles à A)

On peut pousser plus loin … “service de santé du réseau KopiMonk”, liste des articles publiés par B, indice de web-of-trust sur l'ensemble du réseau …

Si je suis à côté de la plaque ou si cette option à été mentionnée, ne pas m'en vouloir ;)

Pour la suppression d'un article, pourquoi ne pas proposer de “cacher” l'article (complètement ou avec un accès par mot de passe) ou de le rendre complétement anonyme après validation

Yoplaid, 2012/08/27 17:36

Oups… Désolé pour le côté brouillon, my bad…

“De là, les KopiMonks reliés entre eux répliquent les articles des auteurs qu'ils acceptent.” Ne serait-il pas plus simple et efficace de répliquer tous les articles à travers le réseau et laisser chaque admin le loisir de publier les auteurs / articles de leurs choix sans que celui-ci n'est un rôle dans la réplication ?

“Suppression par l'auteur ? (Est-ce souhaitable ? Si l'auteur peut supprimer un article, il pourrait être forcé à le supprimer.)” Ne pourrait-on pas laisser à l'auteur le choix de cacher ses articles / ou de libérer la paternité de ses articles (tout en le conserver sur le réseau de propagation/réplication)

Sébastien SAUVAGE, 2012/08/27 21:01

Réplication systématique ? Justement, j'hésite entre: choix des clés pour publier seulement certains auteurs (comme VVB actuellement, au final), ou alors allouer un espace de stockage qui réplique tout (comme Freenet).

J'ignore quelle est la meilleure solution.

Le soucis de répliquer tout, c'est que ça pourrait s'engorger de spam, et je pense que les webmasters en souhaitent pas ça. Et même sans spam, déjà avec ma trentaine d'autoblogs hébergés, je dépasse 1,7 Go. Je ne suis pas certain que tout le monde souhaite ça sur son hébergement.

Sébastien SAUVAGE, 2012/08/27 21:03

Pour la suppression par l'auteur, je pense que ton idée originelle de l'historique est la bonne. Il faut bien voir que par injonction judiciaire, si on t'oblige à supprimer un article et que tu en as les moyens, tu sera fautif si tu ne le fais pas.

yoplaid, 2012/08/27 21:36

L'idée derrière l'abandon de paternité, et qu'en cas de pression, l'auteur peut mettre à jour son article à jour et en abandonner la paternité après, le gars est “couvert” de part la diffusion inébranlable de sa mise à jour et par l'incapacité total de prouver son lien à la mise à jour. La garantie que les admins ont de ne pas avoir un “pétage de câble” de l'auteur réside dans leur capacité à retirer l'article de la publication. Je m'enflamme ou ça reste cohérent avec ton projet ?

Wardormeur, 2012/08/27 20:12

Projet très interessant qui reprend bien l'ideologie de VroumVroumBlog en version P2P :D Juste une remarque : ” “De là, les KopiMonks reliés entre eux répliquent les articles des auteurs qu'ils acceptent.” Ne serait-il pas plus simple et efficace de répliquer tous les articles à travers le réseau et laisser chaque admin le loisir de publier les auteurs / articles de leurs choix sans que celui-ci n'est un rôle dans la réplication ? ” Laisser une telle possibilité, c'est la porte ouverte à un easy-DDOS/pourrissage des hosts. La solution serait alors d'etablir 2 états et d'instaurer un master acceptant tout et “filtrant” le spam/clé pgp et des relais se basant sur les masters. Sauf que c'est “contraire” à l'idée de base.

“Ne pourrait-on pas laisser à l'auteur le choix de cacher ses articles / ou de libérer la paternité de ses articles (tout en le conserver sur le réseau de propagation/réplication) ” La possibilité de suppression ne devrait pas être implementée puisque le but même du processus est d'empecher la disparition des-dits articles. Je plussoie donc pour la liberation de parternité des articles.

Sébastien SAUVAGE, 2012/08/27 21:06

+1 Le spam est en effet un problème majeur, d'où mon idée de permettre aux admins de choisir qui publier. On peut quand même automatiser l'acceptation de nouveaux auteurs (nouvelles clés) par le système de confiance (ajout automatique des clés d'auteurs des KopiMonk auxquels vous faites confiance).

yoplaid, 2012/08/27 21:20

Projet très interessant qui reprend bien l'ideologie de VroumVroumBlog en version P2P :D Juste une remarque : ” “De là, les KopiMonks reliés entre eux répliquent les articles des auteurs qu'ils acceptent.” Ne serait-il pas plus simple et efficace de répliquer tous les articles à travers le réseau et laisser chaque admin le loisir de publier les auteurs / articles de leurs choix sans que celui-ci n'est un rôle dans la réplication ? ” Laisser une telle possibilité, c'est la porte ouverte à un easy-DDOS/pourrissage des hosts. La solution serait alors d'etablir 2 états et d'instaurer un master acceptant tout et “filtrant” le spam/clé pgp et des relais se basant sur les masters. Sauf que c'est “contraire” à l'idée de base.

Pour le DDOS, à part droper/limiter les demandes d'updates à un certain taux, je ne voit pas de solution. Les trucs qui me font un peu peur avec le système de réplication/propagation/hébergement sûr les articles seulement publié par l'admin, c'est que le jeune auteur inconnu/peu connu/ne bénéficiant pas du mécanisme de web-of-trust publiant sur un KopiMonks un peu en retrait/peu connu/avec un faible indice web-of-trust, ne puisse pas bénéficier de la même “qualité” de propagation / lisibilité que les autres auteurs.

J'ai aussi envisagé le problème de pourrissage de host, bien que imparfaites les seules solutions que je vois sont -1- que chaque KopiMonks communique une liste des articles publiés (ou non publiés) et si, sur l'ensemble du réseau un article n'est pas publié à un certain haut pourcentage durant plus d'un lapse de temps donné, chaque KopiMonks l'efface et bloque ça propagation. -2- que chaque KopiMonks fasse périodiquement le ménage de son côté sur les articles non publiés et bloque une éventuelle réception du même article … -3- jouer sur le web-of-trust positif et négatif.. Si A et B ont un lien d'approbation l'un vers l'autre, si A signale un article (red flag / spam …) B ne le récupère pas …

J'ai une préférence pour la 3

Wardormeur, 2012/08/28 00:21

Problème que j'expose alors dans le cas 3 : A a pour Monk reconnu B & C. B bloque un contenu que C ne bloque pas, que récupère alors A? L'admin doit-il alors dresser une priorisation de ses peers ou accepte-t-il en cas de contradiction, ou juge-t-il “automatiquement” en fonction du degré moyen d'acceptation dans ses peers (auquel cas l'impartialité risque d'être biaisé par la vitesse de diffusion du protocole/système global)

yoplaid, 2012/08/28 01:57

J'ai bien précisé que les solutions que j'ai trouvé été imparfaite ;)

La 3° solution est celle que je préfère mais demeure sans doute la plus problématique.

Au fait, ça serait un un développement en solo ou tu es ouvert à un coup de main ?

Le lapin masqué, 2012/08/28 18:00

Seul problème dans tous les cas : la censure devient automatisée. Si elle est souhaitable pour le spam, effectivement, il ne faut pas que l'antispam puisse devenir, par une quelconque méthode, un moyen de censure. Il faut donc que l'admin puisse au moins voir ce qui n'a pas été publié automatiquement et puisse décider de le publier quand même.

AMHO, il faudrait définir plusieurs “niveaux de confiance” ou “comportement de confiance” :

- kopimonk “personnel” où on réplique uniquement les feuilles des auteurs validés - kopimonk “groupe” où on réplique les feuilles des auteurs validés et les feuilles répliquées, avec filtre automatique (WOT/degré de confiance moyen/etc.) - kopimonk “meta” qui réplique les feuilles des auteurs validés et les feuilles répliquées, sans filtre

Chaque kopimonk indiquera son “comportement de confiance”.

Pour la signature par PGP, effectivement ça risque de rebuter des auteurs, surtout dans le cas d'un auteur “sans site”, mais il est assez simple de faire une interface pour ça (il me semble d'ailleurs que ça existe déjà, même en JS effectivement)

Le problème d'un tel projet c'est qu'il y a tellement de fonctionnalités qu'il est difficile de tout mettre sur un seul fil de discussion “à plat”. C'est là qu'un tracker est quand même carrément utile ^^

En tout cas, volontaire pour filer un coup de main ou mettre à disposition des ressources.

Bob, 2012/08/28 18:29

Quelques idées supplémentaires dans le sujet, mais plus sur un fonctionnement push que pull : http://www.fdn.fr/-Conferences-.html (la conférence sur l'effet Flamby).

yoplaid, 2012/08/28 19:38

Bien la vidéo, c'est vrai qu'il y a plein d'idées. Mais perso, je raffole pas trop du système de push, à moins d'avoir une équipe derrière et les ressources qui vont biens qui permettent de rebondir en cas de problème. Sans parler du fait que le pusher attire les projecteurs sur lui.

yoplaid, 2012/09/04 17:03

Yop, still alive ? ça avance côté réflexion ?

Pour la reconnaissance de paternité / identification auteur, en lieu et place d'utiliser openpgp (pas de lib full php trouvée et sans ça, pas accessible pour la grande majorité des hébergeurs) pourquoi ne pas adopté un système de clé publique/clé privée homemade ?

clé public = sha1( random(50) )

clé privée = sha1 ( ( phrase || mots clés ) + salt )

en utilisant une phrase ou des mots clés avec chiffres, casse, lettres et tout le tremblement qui font un bon mot de passe.

Dans le formulaire de rédaction d'article, l'auteur signe avec sa clé public, et hors du <form> : sa clé privée, on génère l'id le l'article côté client.

Pour l'id de l'article un simple sha1( clé privée + clé public + article )

J'ai pris du sha1 pour l'exemple…

Tu va sans doute me dire, et la crypto côté serveur ↔ client (du moins sans https)… bon là un peu tordu, mais j'ai une idée : on utilise un captcha image (ou autre) et jCryption (ou SJCL) … on génère le captcha avec le formulaire (donc la clé du captcha est connu par le serveur), l'utilisateur tape le captcha hors <form>, on crypte sa clé public (ou autre) avec sa réponse au captcha ( sha1 (captcha user + clé public) ) et le serveur peut recevoir le <form> en crypté tout en vérifiant la validité de sha1 (captcha user + clé public) … :D

http://www.jcryption.org/ https://github.com/HazAT/jCryption

Faudra peut-être modifier un peu jcryption pour coller à la procédure.

ou voir si moyen de décrypter avec SJCL côté serveur.

à noter que pour la liaison server ↔ server, il y a sans doute moyen de s'inspirer de cette procédure avec un autre moyen que le captcha.

Me suis pas relu mais il me semble que l'idée est là …

Le lapin masqué, 2012/09/04 17:33

Et en cas de corruption/vol de la passphrase, quelle serait ta stratégie de révocation ? Comment la propager efficacement et en toute sécurité à tous les kopimonks ?

Pour le coup, ça me semble plus simple de créer une lib php “homemade” (en créant une classe qui va bien j'suis sûr il y a moyen de faire ça bien) gérant bien l'openpgp plutôt que de faire un nouveau protocole qui n'apporterait pas forcément grand chose et qui serait soumis à des failles potentielles plus grandes.

Le lapin masqué, 2012/09/04 17:47

Même si l'idée est plutôt bonne en soi hein, c'est pas le problème. Mais la gestion de l'évènement “corruption de la clé privée” est très lourd à gérer pour le coup… En dehors de cette petite faiblesse de protocole, les technologies proposées sont intéressantes à mon sens et permettent tout à fait la sécurité des transmissions même sans https, ce qui est loin d'être négligeable.

Ça soulève d'ailleurs la question de la “lourdeur” au niveau machine ; je suis personnellement de ceux qui s'en foutent, mais ce n'est pas le cas de tout le monde. Il faudrait déterminer si cela entre en ligne de compte.

yoplaid, 2012/09/04 19:34

Bon la crypto, c'est pas mon fort, donc je fais avec mes humbles connaissances …

Pour ce qui est lib collant à openpgp, il y a un projet déjà entamé sur github https://github.com/bendiken/openpgp-php (il me semble qu'il y a encore du boulot vu les quelques “todo” dans le code et qu'il semble être à l'abandon), à voir : qualité du code, les perfs et la possibilité de porter ça en js (ou lib js openpgp “compatible”)…

Pour la révocation, en partant de l'idée que la clé privée n'est communiquée qu'à un réseau restreint de kopimonks, l'auteur à la possibilité d'utiliser l'abandon de paternité (voir une procédure de changement des clés, faisable mais ça me parait plus/trop lourd …) + bannissement des clés corrompues sur le réseau. L'idée est que la passphrase ne soit communiquée qu'en cas de suspicion de clé privée corrompue … C'est à dire : l'admin d'un kopimonks pense que l'un des auteurs à une clé privée corrompue (ou que l'auteur trouve un article portant sa signature sans qu'il en soit réellement l'auteur), il met un redflag sur l'auteur, le red flag est “pushé” sur le réseau wot, chaque kopimonks du wot publie un encadré sur les articles de l'auteur l'invitant à vérifier sa clé privée via un formulaire, l'auteur entre sa passphrase, l'admin fait un contrôle si la passphrase est “humainement compréhensible et cohérente (sur au moins 1 mot en autorisant le l33t(…))”, si c'est le cas et que l'auteur reconnait que tout les articles portant sa signature sont le fruit de ses mimines, alors fausse alerte, si problème ⇒ abandon de paternité et suppression(?) des articles suspicieux.

L'idée de la “pass phrase” est qu'au cas où un kopimonks fuitent les clés privées (piratage / sabotage …), est de casser les coui..es au vil pirate avec une dernière “protection” à casser, ce qui peut laisser un peu de temps pour colmater la faille / prévenir l'auteur. Si la clé privée est salée et en sha256 ou sha512, ça peut lui prendre du temps de trouver une pass phrase qui répond aux critères …

Je pense qu'il faudrait utiliser le push kopimonks ↔ kopimonks pour tout ce qui est demandes exceptionnelles (révocation / partage des clés …) et l'autre système pour la propagation des articles.

Pour la lourdeur, faudrait faire des benchs, mais à voir les sources de https://github.com/bendiken/openpgp-php, je pense que c'est kifkif voir un poil en dessous.

Petite question, la problématique de “corruption de la clé privée” n'est-elle pas la même avec openpgp ? Je veut dire en cas de fuite des clés ?

Le lapin masqué, 2012/09/05 10:36

Pour PGP, tu as un certificat de révocation créé en même temps que la clé qui te permet de la révoquer.

Le gros problème dans le processus que tu décris est qu'en entrant la passphrase sur un site tiers, il n'y a aucun moyen de savoir si ledit site ne récupère pas la passphrase en clair, du coup… Ça ne me semble pas viable a priori.

yoplaid, 2012/09/05 12:22

Oui, problème dans ma procédure …

Par contre avec le système de red flag → notification article → l'auteur check les articles

→ si ok : un simple formulaire demandant clé public et clé privée → le red flag est levé au bout de X jours

→ si problème : formulaire demandant clé privée + clé public + pass phrase → abandon de paternité / abandon des clés … En gros, si l'utilisateur transmet la pass phrase, les clés sont foutues … L'avantage c'est que l'on peut faire ça sans que l'admin ne joue le moindre rôle à partir du red flag et que, même s'il récupère les clés, celle-ci sont bannies du réseau.

Faut être conscient que si l'admin peut modifier les sources de sont kopimonk, il n'y a pas grand chose à faire … openPGP ou pas …

Soit dit en passant plus je me renseigne sur l'openpgp, plus je trouve ce système intéressant. Mais une question, ne risque t'on pas d'avoir des auteurs qui utilisent la même clé publique pour protéger leurs mails et sur kopimonks, et dû coup d'être identifiable IRL ?

[troll]plus j'ai le nom “kopimonk” en tête, plus je confond avec “pokemon”[/troll]

Julmx, 2012/11/17 20:41

Salut,

ayant longuement réfléchi à ce concept génial de SebSauvage, je vous fais part de mon idée. Je ne suis pas vraiment développeur alors tous vos retours sont bienvenus.

Dans les solutions proposées, le 2ème problème (facilité de mise en place et donc réplication à grande échelle) n’est pas vraiment résolu.

Mon idée est de se baser sur des liens magnet (un lien magnet permettrait de télécharger les données d’un article) :

Un article (images, vidéos, et autre inclus ?) est transformé en fichier + lien_magnet, puis, mis à disposition sur le réseau torrent. Tous ceux qui disposent du lien magnet peuvent répliquer l’article. Un lien magnet permet d’identifier un article de manière unique et aussi de le trouver.

ainsi :

  • pas besoin d’avoir un serveur pour répliquer les données. avec le script ou plug-in adéquat interfacé avec mon client torrent (ex : transmission) je peux participer à la réplication des données. Si mon PC est parfois éteint, ce n’est pas bien grave, je peux quand même participer ⇒ tout le monde a un PC et une connexion internet…
  • pas d’annuaire ou autre à gérer pour savoir qui participe a répliquer tel blog. Le lien magnet suffit pour retrouver l’article n’importe où.
  • la charge de la réplication est automatiquement répartie
  • si un article est très disponible (beaucoup de seeders), je peux choisir de ne pas télécharger les données, et réserver mon espace disque à d’autres. Je vérifie périodiquement si le nombre de seeder ne descend pas en dessous de n, auquel cas, je récupère les données.
  • très difficile à censurer, rien n’est centralisé et pas d’hébergeur à contacter.

en cas d’injonction légale, je peux bannir un lien magnet

Au moins 3 problèmes se posent :

  1. Comment passer de l’article au lien magnet a amorçer le seed ?
  2. comment rendre l’article consultable avec un simple navigateur ?
  3. par quel mécanisme, je suis prévenu de la publication d’un nouvel article publié par quelqu’un que je veux bien répliquer ?

Pour le premier point, je pense qu’il faut dans un 1er temps proposer un service web qui se charge de créer le magnet à partir du flux rss et de le propager. Par la suite, on peut envisager un client desktop ou un des addon pour les moteurs de blog qui se charge de le faire sans être dépendent d’un service tiers.

Pour le 2ème point, il faut là encore s’en remettre a un service web qui récupère les données et affiche correctement l’article. On peut aussi imaginer un plug-in au navigateur ou bien au client torrent qui se charge de faire le boulot de récupération des données et affichage. Ceci permettrai d'être totalement indépendant d’un service web.

Enfin, le 3éme problème nous amène à l’autre aspect de ce que j’envisagerai : passer par le protocole XMPP. Je le connais assez mal et il y a sans doute des façon plus élégantes de l’utiliser que ce à quoi je pense.

un auteur de blog est identifié par son compte XMPP type jabber. Quand il publie un article, son bot envoi le lien magnet à tous ceux qui acceptent de le répliquer par XMPP, la chaîne est ainsi démarrée. Dans le cas le plus simple (voir problème 1) c’est le service web ami qui se charge de créer le lien magnet à partir du flux RSS puis le broadcaster aux autres bots XMPP amis.

Si le blog est fermé, l’auteur peut continuer a publier avec un compte XMPP, il suffit qu’il puisse continuer à distribuer des liens magnet via XMPP. (l’anonymat est possible). Pas de source unique, enfin si : le compte xmpp quand même… on peut cependant imaginer que l’auteur puisse signer (openPGP ?) ses messages et donc être reconnu s’il change de compte XMPP…

Pour accepter d’héberger quelqu’un, il faut que j’ajoute son ID XMPP à une liste, a partir de là, mon bot XMPP accepte tous les liens venant de ce compte. Je peux aussi choisir d’ajouter automatiquement tous les ID que SebSauvage (or anyone i trust) accepte. Je peux aussi faire du stockage aveugle avec une portion de disque allouée.

Tout cela nécessite de faire un protocole de communication entre bots, mais mon pavé est déjà assez lourd comme ça (pour un truc que vous trouverez peut être sans intérêt d’ailleurs). Du coup je ne développe pas plus cette partie ;) j’ai encore plein d'idées ;)

Du point de vue utilisateur, on peut faire quelque chose d'à la foi simple à utiliser, qui permet la réplication à grande échelle et très difficile à censurer.

Le point faible est sans doute les services web des problèmes 1 et 2, ils demandent pas mal de développement et risquent d'être assez lourd à installer. Cependant, ils ne sont pas indispensables , ils servent seulement à faciliter l'accès au mécanisme dans un premier temps. Tout continue à fonctionner si un server tombe. Ils n’ont pas besoin d'être nombreux pour que les données soient répliquées à grande échelle. Ils peuvent être remplacés du jour au lendemain….

Allez, je m’arrête là. Bravo si vous avez lu jusque là ! J’espère que c'est a peu près clair, au moins les grandes lignes du mécanisme.

Dites moi si je suis débile

julmx, 2012/11/18 22:42

Quelques idées :

la meilleure stratégie, pour atteindre notre but est peut être de privilégier dans un premier temps la réplication à grande échelle. Permettre au plus grand nombre de participer, même sans server (cf mon post précédent).

Si le système est conçu pour être évolutif, il sera toujours possible d'ajouter des fonctionnalités comme la signature des articles par là suite.

peut être utile a la propagation des articles : http://xmpp.org/extensions/xep-0163.html

une liste de librairies pour XMPP : http://xmpp.org/xmpp-software/libraries/

Esprit, 2014/09/09 11:33

Bonjour à tous,

Je suis pas loin de deux ans en retard mais je viens de tomber sur la page et je voulais juste signaler que si le projet fini par aboutir un jour, je serai fier de donner un peu d'espace sur un serveur pour contribuer au partage et à la diffusion des articles.

Entrer votre commentaire. La syntaxe wiki est autorisée:
 ______  ____    ____   __ __   ___ 
/_  __/ / __ \  /  _/  / //_/  / _ \
 / /   / /_/ / _/ /   / ,<    / ___/
/_/    \____/ /___/  /_/|_|  /_/
 
kopimonk.txt · Dernière modification: 2014/07/12 13:26 (modification externe)