Cesium : Nouvelle version v1.7.0-rc1 (beta)

Une nouvelle version 1.7.0-rc1 de Cesium est disponible, pour les beta testeurs

Nouveautés

Traductions

Affichage des clés publiques + “identicon”

Des images valent mieux que de long discours :slight_smile:

  • Affiche des clé publique, revu comme convenu avec les autres devs :

  • Affichage d’une icone représentant la clef (ici à droite)
    image

Carte des membres

Quelques optimisations pour que la carte des membres fonctionne à nouveau.
Mais elle est encore très lente :slight_smile:

2 Likes

Chouette, une nouvelle version de Cesium ! :slight_smile:


As-tu lu ce poste au sujet des identicon basé sur la VRF ?

Si on décide de sa baser là dessus d’ici 1 an, ce n’est peut être pas super d’habituer les gens à d’autres générations d’identicons ?

Bon de toute façon les address de chacun vont changer après la migration donc quelque soit la méthode…

Mon avis est toujours le même: je reste convaincu qu’il ne faut pas d’identicon dérivé de la clé publique ni de son checksum ni de tout input pouvant être choisi directement par l’utilisateur.

@kimamila peut tu stp retirer cette fonctionnalité dangereuse de cesium ? sinon on va devoir expliquer aux utilisateurs qu’ils ne doivent pas se baser dessus, ça va complexifier le support utilisateur et mettre en doute la confiance en tout le système à la 1ère grosse attaque de phising.

1 Like

J’ai déjà répondu à tes remarques.
Je redis qu’avoir un checksum n’est pas la clef publique, mais une info de vérification en plus.
De même, une identicon n’est pas la clef, mais une info de vérification en plus.

Combien y a t’il de checksum possible en tout ? Combien le cerveau humain est capable d’en retenir ?

Combien y a t’il d’identicon possible en tout ?
Tous les cerveaux humains mémorisent ils de la même manière les codes (un chk) et les formes ?
A quoi sert un checksum pour une personne visuelle, qui retient mal les chiffres ? (Comme moi)

Et enfin, pourquoi le client substrate js utilise des identicon elle aussi ?

Même si chaque compte avait la photo exacte du visage de son détenteur, de manière unique donc, et étant donné que nous déjà 20000 comptes dans la G1, qui peut croire qu’il retiendrait parfaitement et se baserait uniquement sur ces photos (pourtant très précise, d’une excellente entropie) pour authentifier un compte ?

Mais tu n’écoute pas, tes réponses montre que tu n’a pas compris ce que j’explique. Je ne suis pas contre les identicones, je dit juste qu’elles doivent être dérivées d’un input qui ne peut pas être choisi par l’utilisateur pour empêcher les attaques ed phising.

Polkadotjs est réservé aux développeurs et utilisateurs avancés, les utilisateurs finaux des projets basés sur substrate n’utilisent généralement pas polkadotjs, mais une application dédiée développée par le projet.
De plus, lis utilisateurs cible de ces projets ne sont généralement pas les mêmes.

Je me soucie de protéger les utilisateurs cible de la Ğ1, qui n’ont pas le recul technique nécessaire et qui pourront se faire facilement avoir par une attaque de phising.

1 Like

En fait ces identicônes ne sont pas pires que la checksum actuelle, si on les utilise mal.

Serait-il envisageable d’ajouter des popups expliquant ce que c’est, comment s’en servir (vérifier une erreur de saisie ou retrouver une clé parmi plusieurs déjà connues) et l’insécurité d’un mauvais usage ?

Elles sont pire dans le sens où la plupart des gens ne regardent que les images, où en tout cas voit les images en premier. Ils vont beaucoup plus se fier à une image qu’il retiendrons facilement qu’à un checksum qu’il ne retiendrons pas. Le checksum n’a d’intérêt que pour se prémunir des erreurs de saisie manuelle.

1 Like

De manière plus pragmatique, sur mobile j’ai un dilemme purement UX.
Je ne peux pas afficher et les photos de profiles, et les identicon sur une même page, qui contiendrai déjà un qrcode et la photo, ce serait beaucoup trop chargé.

Je ne peux pas non plus afficher la photo de profile si présente, ou l’identicon à sa place si non présent, ce serait évidemment le fishing assuré.

Ce qu’a fait Kimamila sur Cesium semble pas mal, en petit à côté de l’address, mais dans une liste de recherche par exemple, je pense que ce serait trop chargé si on y affiche aussi les photos de profiles.

Donc juste si on autorise les images de profiles lié aux portefeuilles, pas d’identicon sur mobile.

Une solution serait de dissocier la nation d’utilisateur de celle de portefeuille, avec les données qui vont avec et tout ce qui s’en suit, pas envie de me lancer là dedans.

Donc au final, je suis pas pour les identicon dans Gecko, mais si d’autres clients en utilisent, quels qu’ils soient, ça ne me pose pas de soucis.


Pour lutter contre le fishing, je suis plus d’avis à le traiter différemment, par exemple avec cet écran prototypé par boris:

  • Seraient considéré comme « jeune ou innexistant » bien voyant un portefeuille sans transactions
  • Seraient considérés comme « Arnaque potentielle », avec fond rouge encore plus voyant, toute addresse signalé comme arnaque via les utilisateurs.

Au final c’est un peu ce que fait Cs+, pas mal de gens signals des portefeuilles via Cesium, et Cesium l’indique.

Pour le reste, le checksum, associé à l’accompagnement à la saisie, et les suggestions de recherche optimisés (afficher en premier les match d’address complète exact, puis dans les metadata proches avec le plus de transactions effectués, ect …) me semble suffisent.

1 Like