Ça fait un moment que je réfléchis aux options que nous avons pour étendre la toile de confiance à d’autres cas d’usage et j’en ai peut-être déjà parlé sur le forum, mais je ne retrouve plus où. Les problématiques de spam ou de confiance pourraient trouver une solution assez simple sur le modèle des chaînes de certificat utilisée avec TLS mais au lieu d’avoir une origine dans un certificat racine unique, avec une origine dans la toile de confiance.
Exemple de cas d’usage : on reçoit un message privé signé et on veut savoir s’il s’agit d’un spam ou d’un message légitime. Le message vient avec une chaîne de certificats dont le premier est signé par un membre de la toile de confiance ğ1. Si ce membre ne fait pas partie d’une blacklist, on considère le message non spam. S’il s’avère que le message est en fait du spam, on peut ajouter ce membre à notre blacklist. Chaque nouvel arrivant peut s’il le veut ajouter une blacklist publiée par la personne de son choix.
On pourrait appliquer ces chaînes de certificat à tous les comptes ğ1. Si un compte a une activité qui nous déplaît (données Césium+, transactions spammeuses), on ajoute le membre qui a signé son certificat racine à notre blacklist et on peut :
- censurer ses documents dans notre nœud Duniter
- ne pas prendre en compte ses données Césium+ dans nos statistiques
- masquer ses annonces sur ğchange
J’anticipe que des personnes s’interrogent sur la dés-anonymisation que cela pourrait impliquer :
- on ne certifie pas forcément que ses comptes, mais on peut avoir confiance en ceux d’autres
- on peut créer des personnes morales cosignées par plusieurs membres et qui agissent comme tiers de confiance, également blacklistables
Voilà à quoi ressemblerait un certificat de la chaîne :
Type de certificat (antispam, confiance dans les données, blacklisting...)
Clé publique (pour chaînage)
Date d'émission
Date d'expiration
Signatures
Et on peut évidemment affiner le système par exemple en ajoutant un poids sur la blacklist. Le dernier certificat de la chaîne reçoit un poids 1 et ses signataires 1/n où n est le nombre de signataires et ainsi par récurrence jusqu’à la racine. Ensuite on peut invalider une identité en fonction de son poids, ajouter des révocations… Mais déjà mettre en place un truc basique permettrait de limiter la casse.
1 Like
Je comprend pas tout, dans l’idée j’ai la sensation que cela ressemble au réseau proposé par @qoop, même si j’ai aussi du mal à comprendre son système.
Je dis ça au cas ou vous pourriez trouver le moyen de partager vos idées sur le sujet.
En gros, la cryptographie permet de s’assurer qu’un message a été signé par une clé privée associée à une clé publique donnée. Si je reçois un message M provenant d’un compte non membre C mais qu’il est accompagné d’une chaîne de signatures A → B → C → M où A est un compte membre, alors si je fais confiance à A pour bien distribuer ses signatures, je peux estimer que B et C sont aussi dignes de confiance, et que le message M est légitime. Au contraire, si A est connu pour des comportements de spam, on peut imaginer que le message M ne soit pas légitime.
1 Like
Je suis sceptique sur la complexité ajoutée par rapport à la simple blacklist des comptes émetteurs de spam dans Cesium.
Que ce soit le système Cesium ou le système que j’ai publié en RFC avec la signature et le chiffrement en ed25519, identique à Cesium mais utilisable hors Cesium, un simple système de blacklist en fonction de l’émetteur me semble suffire.
Et puis le principe pyramidal des chaînes de certificats centralise la confiance dans un seul certificat maître qui, s’il est corrompu ou hacké, fait s’effondrer la pyramide.
En restant au niveau des émetteurs, on est plus horizontal, avec une meilleure granularité. Amha.
La blacklist ne suffit pas, il suffit de créer un nouveau compte pour en sortir, et il n’y a pas de limite à la création de compte. Regarde par exemple Spam : dessin sur la carte Cesium+. Dans ce que je propose, il n’y a pas un seul certificat maître, mais autant que de membres de la toile de confiance ğ1. Et si on blackliste, ça s’applique à quelques comptes membres. La personne physique ne pourra pas créer de deuxième compte dans le respect de la licence.
1 Like
De mon côté, j’ai une idée simple pour éviter de nouveau ce genre de problème (prévisibles).
Dans les Pod CS+ les accès dépendent de l’existence d’un profil. Il suffit donc de rendre impossible (ou difficile) l’enregistrement d’un profil par un non humain.
C’est un problème archi connu, avec plein de solutions opérationnelles : validation par email, code a recopier a partir d’une image, etc.
Commençons déjà par la, non ?
2 Likes
Oui, le captcha qui demande de faire une opération bête ça me paraît bien 
Il faut que je retrouve la version de @Neil qui était pas mal.
Un nœud demanderait un captcha pour créer un profil ? Mais alors il pourra toujours recevoir des nouveaux profils des nœuds pairs et non des clients, et donc les spammeurs pourront toujours exploiter l’API internœuds… (si j’ai bien compris le système)
Quant aux captchas il ne faut pas que ce soit uniquement visuel, cela exclurait les aveugles et les mal-voyants.
1 Like