N’ayant pas de cahier des charges spécifique sur Cesium2, j’ai actuellement placé les avatars à la place des identicon dans l’annuaire lorsque le wallet dispose d’un avatar. Sinon, c’est l’identicon qui s’affiche:
C’est ce qui semble le plus logique aux premiers abords.
Cependant, je déterre un vieux sujet, mais je maintient ma position qu’en l’état, si l’identicon est censé avoir un rôle d’identification rapide d’un wallet, alors le mixer avec avatar interchangeable pose des problème de sécurité.
Il me suffit de mettre en avatar l’image de l’identicon d’un wallet que je veux usurper, et le tour est joué.
Je précise que c’est précisément cette raison qui m’a convaincu de finalement ne pas intégrer d’identicon dans Gecko.
Que pensez vous de ça, on en fait quoi ? En terme d’UX précisément svp.
En fait, on a le même problème également en ne gardant que les images… Quelqu’un peut copier celle de quelqu’un d’autre.
Je suppose que la seule option plus sécurisée serait de n’autoriser que les Identicon. Mais ce serais une perte de fonctionnalités pour les utilisateurs.
Avoir un affichage sur deux niveaux de lecture ? Par exemple (je suppose que l’affichage des avatars est une option)
l’option est désactivée
→ on afiche les identicones devant le pseudo + adresse
l’option est activée
→ on affiche les avatars mais pas les identicones. Avatar par défaut si pas d’avatar défini.
on affiche les identicones sur le hover (sur desktop) ou sur appui long (sur télécran), OU on affiche les identicones en petit à coté de l’avatar, un peu comme viĞnette affiche le logo Ğ1 :
Ce que tu dis est très pertinent je trouve. En fait tu tires un peu une idée que j’avais, qui était de simplement afficher les identicon en petit par dessus les avatar en bas à droite de l’avatar.
Mais seul dans mon coin, je ne m’étais pas convaincu.
Je n’ai pas bien compris ton “option”, si activé, on n’affiche pas du tout d’identicon en fait c’est ça ?
Je ne pense pas qu’une option soit une solution, la majorité des gens garderont l’option par default, et le but des identicon est de “s’imposer” à soit pour identifier brièvement un wallet de manière intuitive.
Je ne suis pas convaincu non plus par le hover ou appui long, pour des raisons similaire, la plupart ne se rendront pas compte que cette fonction existe.
Mais afficher soit l’identicon, soit l’avatar + identicon par dessus en petit en bas à droite, je trouve ça pas mal, car si on essai d’usurper un wallet avec un faux identicon, on le verra tout de suite car le vrai identicon sera par dessus.
A-t-on des retours d’utilisateurs qui utilisent effectivement les identicons pour vérifier un compte ?
C’est pratique comme remplacement d’un avatar quand il n’y a pas d’avatar, parce qu’on reconnaît quelqu’un d’un coup d’œil. Mais j’ai peur que l’entropie soit assez faible pour qu’on puisse les bruteforcer. L’entropie du souvenir qu’on a de l’identicon est encore plus faible, il suffit d’avoir la même couleur et une forme proche pour tromper la reconnaissance.
En plus, si je reconnais des identicons sur certains forums ou sur GitHub, c’est uniquement parce que l’avatar est le meilleur moyen de reconnaître immédiatement l’auteur. Si l’identicon apparaît à côté de l’avatar, je regarderai plutôt l’avatar (qui est plus facile à reconnaître), donc mon cerveau n’aurait aucune raison de retenir l’identicon.
Je préfère continuer à dire “dans le doute, vérifiez la clé publique ou les certificateurs” pour ce qui est de la sécurité. Les identicons ne sont pas un outil de sécurité.
Oui je suis d’accords avec ça aussi.
Aussi, ajouter l’identicon en petit par dessus l’avatar le rendrait illisible, on ne verrait rien du tout je pense, encore moins sur mobile.
Donc au final, autant juste laisser comme ça.
J’ai globalement jamais été convaincu par les identicones.
Si on reprend la question à la racine : comment peut-on attribuer une confiance à une entrée utilisateur ? Et du coup à mon avis c’est une question qui touche à la toile de confiance, il faut que les profils de données hors chaîne puissent être signés par des clés membres. Soit le profil directement, soit une délégation à la clé.
Certifier le profil c’est compliqué parce qu’à chaque changement il faut re-certifier. Ça me paraît pas faisable en pratique. Par contre, une confiance déléguée dans le style “étoile” c’est intéressant. On peut afficher un sur un profil s’il est membre ou s’il est non membre mais a reçu au moins N venant de clés membres (par ex 3).
Ça a l’avantage d’être plus global que simplement les identicones, ça marche aussi pour le texte de description (celui ci aussi peut être usurpé). Par contre c’est plus compliqué à implémenter et ça peut faire émerger le besoin de contre mesures par exemple une déclaration de perte de clé, une déclaration d’arnaque ou autre.
Et maintenant que j’y pense, il faudrait ajouter l’interdiction d’usurpation d’identité dans la charte/licence, ça me paraît le minimum.
Dans ce cas l’UI devrait bien indiquer ce que signifient les étoiles. Elles pourraient aussi signifier qu’on aime ou pas la personne, ou sa fiabilité lors d’échanges commerciaux, ou un favori/marque-page. Plutôt qu’une étoile, le visuel pourrait être un tampon comme les comptes vérifiés sur Twitter, si ça ne cause pas de confusion avec les certifications.
Idée : inclure dans le fichier de révocation les signatures des comptes portefeuille. Lors du chargement du fichier pour révoquer, on peut choisir quels comptes on veut révoquer (en ne publiant que les signatures concernées). Les signatures des portefeuilles ne sont pas envoyées en chaîne, seulement aux nœuds Cs+. Pour simplifier l’UI, choisir de révoquer une clé pourrait automatiquement sélectionner toutes les clés dérivées.
Problème : il faudrait enregistrer de nouveau le fichier de révocation à chaque nouveau compte portefeuille, c’est trop lourd et source de confusion. Mieux vaudrait des clés dérivées et du sharding de la clé principale. La modération Cs+ peut aussi être saisie, tout simplement.
Petite voix pragmatique: en terme d’UX, il faut vraiment faire attention à ne pas faire confondre les certifications avec toute autre forme d’approbation de donnée dans nos outils.
Le processus de certification est en soit quelque chose de difficile à faire comprendre intuitivement dans toute sa profondeur.
Rajouter d’autres couches de like et d’approbation risque d’ajouter de la confusion.
Le défis pour moi est surtout UX.
Mais je reste séduit par l’idée en soit.
sur un profil s’il est membre ou s’il est non membre mais a reçu au moins N 
venant de clés membres (par ex 3).