Oui mais je parle simplement du fait qu’il est impossible d’empêcher un utilisateur d’inscrire des mots. Dire “on inscrit des hash” n’engage que toi.
Pour Cesium, je note l’idée de @1000i100 dans un ticket. ca ne devrait pas être trop dur à faire.
Le prefixe pour être : cs+:<HASH_COMMENTAIRE> voir même simplement cs+: si on utilise le hash de la TX comme référence, dans les noeuds Cesium+.
Cette solution permet simplement de chiffrer les commentaires, afin d’ajouter la confidentialité et l’identification forte de l’émetteur (via les clefs asymétriques et les algos crypto_box de NaCL).
2 Likes
Je crois que @cgeek n’arrive pas à se faire comprendre là 
Le protocole ne peut pas forcer les personnes à inscrire un hash. C’est impossible. Même si les clients utilisaient un hash, on ne pourra empécher personne de produire manuellement une transaction où dans le champs commentaire, il inscrit à la place du hash un texte en clair.
C’est la nature même du champs commentaire qui veut ça…
6 Likes
Perso je remets totalement en cause le besoin du champ commentaire.
@kimamila vient de démontrer que cesium pourrait s’en passer et stocker ailleurs qu’en blockchain les commentaires basés sur le hash de la TX.
Pour d’autre service (dont mon “satoshidice” version G1 que je suis en train de préparer), en l’état sans le HD wallet, faire automatiquement des actions basées sur des TX semble possible que par les commentaires. C’est un peu le point qui nous bloque je pense.
2 Likes
De même que dans Bitcoin, il n’était prévu de pouvoir mettre des données arbitraires dans une transaction, qui sont insérées via une astuce dans le script de verrouillage des fonds.
Outre le fait que l’on ne puisse pas obliger l’utilisateur à inscrire des hashes valides, il pourrait tout à fait fournir le hash d’un contenu illégal, disponible par exemple sur IPFS. On aurait donc toujours ce “problème” de données illégales “stockées” dans la blockchain.
5 Likes
Si l’on veux forcer le champs commentaire à être constitué de hash valide pour du contenu modérable (d’une façon à définir mais hors protocole), il serait possible de ne valider un nouveau bloc que si son hash de commentaire correspond à une entrée dans cette db externe (qui peut être décentralisé).
Cette vérification n’étant pas utilisé lors d’un sync ou autre découverte tardive du bloc, afin qu’une suppression du commentaire ne bloc pas la sync.
Les recommandations de la CNIL.
Est-ce qu’il est possible de mettre un commentaire en binaire plutôt qu’en ascii, puisque les blocs sont codés en JSON ? Pour éviter de stocker un hash en hexa ou en base 64 qui prendrait plus de place…
Le document de la CNIL vaut son pesant de cacahuètes ! Merci 
J’aime bien la page 6, sur les difficultés a appliquer le RGPD sur les blockchains publiques avec des noeuds hors UE
La page 7 va plaire a @1000i100 :
La CNIL considère que les données à caractère personnel devraient être enregistrées dans la
Blockchain, de préférence sous la forme d’un engagement cryptographique1. Si cela n’est pas
possible, un enregistrement sous la forme d’une empreinte obtenue avec une fonction de
hachage à clé est possible, ou, a minima, d’un chiffré, permettant d’assurer un haut niveau de
confidentialité.
Le principe commun à certaines de ces solutions est que la donnée en clair est stockée ailleurs
que sur la Blockchain (comme par exemple sur le système d’information du responsable de
traitement) et que seule une information prouvant l’existence de la donnée y est stockée
(engagement cryptographique, empreinte issue d’une fonction de hachage à clé etc.).
Ca confirme ta proposition.
5 Likes
Il y a déjà eu sur ce forum une discussion sur les données personnelles ?
Parce qu’à part un pseudonyme, en théorie il n’y a rien (je me souviens du débat justement de ne PAS intégrer des données identifiantes même chiffrées en blockchain au cas où, dans le futur, une clef se fasse casser)
Si il y a les commentaires des transactions, c’est une donnée personnelle que nous devrions, a mon sens, supprimer de la blockchain (par exemple en inscrivant qu’une preuve comme le recommande la CNIL).
1 Like
C’est Cesium+ et les nœuds Elasticsearch qui sont concernés surtout.
Le champ commentaire est une string.
Si on supprime ce champ, pour le nouveau champ qui accueille une “preuve” de type clef ou hash, on doit vérifier le type de clef lors de la vérification des données du bloc, non ?
Perso je propose de remplacer le type String par le type Hash (sha256), soit un tableau de 32 octets. Il ne sera fait aucune vérification sur ce champ si ce n’est qu’il est pris en compte pour la validité de la signature, mais ça évite un champ de taille variable et ça évite les attaques par injection.
EDIT : La preuve consiste en le fait que le document transaction est signé par son émetteur. Et n’importequel type de donnée tierce peut-être prouvée via le hash dans le champ “commentaire” qu’il conviendrai alors de renommer “extras”
1 Like
Pas forcément, par exemple “merci” n’est pas une donnée à caractère personnel. Mais il se trouve que les utilisateurs peuvent y inscrire une donnée à caractère personnel.
Qui en est responsable ? Certainement pas les calculateurs de blocs, ni les développeurs.
Si c’est un tableau d’octets, alors c’est un champ commentaire. A part limiter sa taille, c’est du pareil au même.
edit : à la limite, on peut forcer la chose en disant “ce tableau, interprété en ASCII, doit être écrit en héxadécimal”, mais même là on ne peut empêcher les gens d’écrire des valeurs qui, interprétés dans une autre base, écrivent un message à caractère personnel.
C’est peine perdue selon moi.
3 Likes
Ça dépend ce qu’on défini comme étant une donnée a caractère personnel. Si je verse des Ğ1 sur un compte avec comme commentaire “merci” on peut en déduire que je remercie le propriétaire du compte cible donc que ce n’est pas un versement vers un autre compte que je possède, on y décèle déjà des informations.
L’uid aussi est une donnée personnelle par exemple.
En effet les calculateurs de blocs et développeurs ne sont pas considérer comme des “responsables de traitement” dans le sens ou ses acteurs n’interviennent pas dans le choix de la nature des données émises et de la façon de les traiter en conséquence
Ne pas être responsable ne signifie pas que nous n’avons nécessairement rien a faire, nos choix techniques ont une influence sur le comportement des acteurs intermédiaires et des utilisateurs finaux.
Le simple fait de renommer le champ comment par extras et d’indiquer dans la documentation qu’il s’agit de “données libres utilisables par toute application tierce” influencera les développeurs des logiciels tiers (clients, pod Cesium+, et tout autre programme interagissant avec les nœuds Duniter).
Je pense que les mots et les symboles sont importants, l’idée n’est pas d’empêcher quoi que ce soit, tu dit a raison que c’est impossible, mais d’assumer que nos choix techniques génèrent des comportements et réfléchir a qu’est qu’on veut générer.
Si demain le champ commentaire n’existe plus et est remplacé par un champ extra ou seul un hash de 32 octets est inscriptible, les clients seront bien obligés de stocker les commentaires hors-blockchain pour être utilisables, et c’est le comportement qu’on souhaite générer.
Le fait que ceux qui le souhaitent trouverons toujours un moyen de stocker un commentaire directement dans les 32 octets en blockchain on s’en fou, qui se ferait chier a faire ça ??
Ce n’est pas parce que quelque chose est possible techniquement que ça ne sert a rien de le rendre plus difficilement possible, aujourd’hui on incite explicitement a stocker des commentaires en blockchain, et ça c’est de notre responsabilité 
4 Likes
Si l’on prend la définition de la CNIL, vu que c’est elle qui est référencée plus haut, alors il s’agit de toute information qui en elle-même permet de caractériser un individu. « Merci » ne permet donc pas de le faire.
En revanche dans ton exemple il y aurait bien une donnée à caractère personnel : ce serait plutôt le compte membre qui effectivement est censé permettre de caractériser un individu, à travers sa clé publique tout autant que par son pseudonyme. Mais ce n’est pas le commentaire en lui-même.
A noter que selon ce raisonnement, les comptes portefeuilles ne sont donc pas concernés.
Ni le protocole ni moi-même ne disons que ce champ est fait pour y stocker des mots humains. D’ailleurs j’en avais parlé aux RML7 je crois (à Laval), en indiquant qu’il s’agissait plutôt d’un champ technique pour y stocker des références (ex. : n° de facture, empreinte cryptographique, etc) pour les services au-dessus de la blockchain.
C’est vrai qu’il est possible d’y mettre des mots humains et que voyant cette opportunité nous avons tous tendance à le faire, mais ce n’est pas du tout son but initial. D’ailleurs il me semble que Sakia avait déjà entrepris une modification dans son interface pour refléter cet état de fait.
On peut aussi préciser le sens dans le protocole en disant « Technical Comment » si c’est ça qui dérange.
Ceux qui voudraient nuire à une personne par exemple, en inscrivant en blockchain ses informations personnelles et ferait un site pour bien les exposer aux yeux de tous.
Ok très bien je ne le savais pas
Je pense que dans une logique de minimisation de la taille de la blockchain il serait préférable que ces informations (n° de facture, empreinte cryptographique, etc) soient stockées ailleurs et que la blockchain ne contienne qu’une preuve de ses informations, donc un hash, qui a l’avantage d’être de taille fixe.
Et si l’on allait dans ce sens, alors « Technical Comment » ne conviendrais pas mieux, ce serait plutôt “extra” ou “user datas” ou autre terme générique mais le terme commentaire me semble trop spécifique.
Possible, encore que c’est à chacun d’en juger.
C’est vrai que dans le cadre des RGPD, les services tiers qui iraient stocker les informations de leurs utilisateurs en clair dans la blockchain risqueraient, eux, d’avoir quelques problèmes en tant que responsables de traitement.
1 Like
Je pense que juste renommer en “extra” est suffisant.
Pour un malveillant qui y exposerait des infos perso, là c’est de la responsabilité de celui-ci. Il y a toujours moyen d’utiliser la blockchain comme “mur” de manière + ou - simple. C’est aux clients de l’exposer ou non. Du coup il reste l’incitation, et là le changement de label convient pas mal.
Et comme ce n’est pas un commentaire, on peut le restreindre facilement (taille fixe par ex) il n’y aura pas de “perte de fonctionnalité”, juste “disparition d’un hack”.