Sinon, je suis bien d'accord que Skype, facebook Messenger, whatsapp, Viber, Line, Hangout, and co sont des services où le client se fait plumer de haut en bas ses données persos. Mais je pensais que le sujet était déja arrivé plus haut donc, voila.
Désolé pour mon ton un poil aggressif, tu as parfaitement raison sur la partie technique.
Ton article était un peu dénigrant à mon gout sur des solutions qui partent de base qu'une bonne intention : Améliorer la vie privée des communications de manière Libre et ouverte même si ce n'est pas fait de manière parfaite.
Donner un token aux contacts dont j'accepte les messages. Ce token, envoyé avec les messages à ma destination permettrait au messages d'etre traités prioritairement par rapport aux autres messages reçus.
Les messages d'inconnus (sans token) doivent avoir une preuve de travail, ce qui limite un peu le spam.
Ton modèle est un Web of Trust avec une preuve de travail pour l'entrée initiale.
Le gros du problème se situe au niveau de l'entrée initiale. Il est trés difficile d'équilibrer un système de preuve de travail comme le fait Bitcoin. Quelqu'un disposant d'hardware spécifique ou de CG pourra sans peine Spammer un réseau car disposant d'une puissance de calcul des millions de fois supérieurs à celui d'un pauvre telephone portable.
Mais l'idée est innovante oui :)
Recevoir les messages par l'intermédiaire d'un serveur (comme un serveur de mail). Ce serveur pourrait filtrer les messages avec ou sans token pour transmettre en priorité à mon smartphones ceux qui ont un token.
Si tu autorise le serveur à lire/comprendre ce "token", tu ré-introduis le problème de traçabilité associé aux méta-données. Tu pourras toujours construire un graphe de contacts et de relations associés à ce dit "token".
Le système de priorité est aussi un problème pour le serveur :
Que faire des messages "low priorité" ? les stocker ? si c'est du spam, ça peut aisément prendre une place importante.
Ensuite, pour les nouveaux contacts, il pourrait y avoir un autre token à envoyer par l’expéditeur qui dépende de sa clé privée et de ma clé publique de telle sorte que le serveur pourrait détecter les demandes de messages répétées d'un même expéditeur sans pour autant savoir quel est l’expéditeur ni le contenu du message.
Donc tu veux une signature qui n'est pas une signature ? ça me semble un peu flou ça :)
Je prendrais plutôt le problème sous une autre approche :
Privilégier les connexion P2P autant que possible au lieu de passer par un serveur tiers, spécialement dans le cas d'une messagerie synchrone.
Autoriser un système de federation de serveurs non hiérarchique comme pour SMTP, XMPP ou SMS/MMS pour favoriser une administration distribuée des serveurs.
[^] # Re: ou pas
Posté par Firwen (site web personnel) . En réponse au journal Messagerie sécurisée, attention à votre carnet de contact !. Évalué à 1.
Désolé pour mon ton un poil aggressif, tu as parfaitement raison sur la partie technique.
Ton article était un peu dénigrant à mon gout sur des solutions qui partent de base qu'une bonne intention : Améliorer la vie privée des communications de manière Libre et ouverte même si ce n'est pas fait de manière parfaite.
Ton modèle est un Web of Trust avec une preuve de travail pour l'entrée initiale.
Le gros du problème se situe au niveau de l'entrée initiale. Il est trés difficile d'équilibrer un système de preuve de travail comme le fait Bitcoin. Quelqu'un disposant d'hardware spécifique ou de CG pourra sans peine Spammer un réseau car disposant d'une puissance de calcul des millions de fois supérieurs à celui d'un pauvre telephone portable.
Mais l'idée est innovante oui :)
Si tu autorise le serveur à lire/comprendre ce "token", tu ré-introduis le problème de traçabilité associé aux méta-données. Tu pourras toujours construire un graphe de contacts et de relations associés à ce dit "token".
Le système de priorité est aussi un problème pour le serveur :
Que faire des messages "low priorité" ? les stocker ? si c'est du spam, ça peut aisément prendre une place importante.
Donc tu veux une signature qui n'est pas une signature ? ça me semble un peu flou ça :)
Je prendrais plutôt le problème sous une autre approche :
Privilégier les connexion P2P autant que possible au lieu de passer par un serveur tiers, spécialement dans le cas d'une messagerie synchrone.
Autoriser un système de federation de serveurs non hiérarchique comme pour SMTP, XMPP ou SMS/MMS pour favoriser une administration distribuée des serveurs.