Proposition : un document qui spécifie les prérequis minimaux que doit remplir toute application qui permet de gérer un compte Ğ1

Applications
1

Il y a des discussions éparses çà et là depuis des années autour des prérequis de sécurité des applications qui permettent de gérer un compte Ğ1, ainsi que des prérequis nécessaires pour s’assurer que les certificateurs respectent la licence Ğ1.

Mais il n’y a pas de document officiel de référence définissant des critères objectifs permettant de déterminer si une application est conforme pour être recommandée sur les sources de référence (comme le site duniter.org, par exemple).

Je propose donc que l’on discute sur ce topic du contenu d’un tel document. Je commence par un premier jet sur lequel je serais ravi d’avoir vos retours :

Critères de conformité d’une application Ğ1 :

  • Afficher par défaut le solde des comptes en nombre de Ğ1 avec deux décimales. D’autres formes d’affichage sont possibles, mais ne doivent pas constituer le choix par défaut.
  • Afficher le solde d’un compte comme étant la quantité totale de Ğ1 dont le compte est propriétaire. Cela doit donc inclure les Ğ1 verrouillées ainsi que les DU non réclamés, s’il y a lieu.
  • Afficher le texte entier officiel de la licence dans la langue de l’utilisateur et s’assurer qu’il l’a lu en entier avant de l’autoriser à confirmer son identité.
  • Afficher un tirage aléatoire de N questions dans la langue de l’utilisateur lorsque celui-ci est sur le point d’émettre une certification, et s’assurer qu’il y a bien répondu. S’il a mal répondu, refuser toute émission de certification pendant 24 h. Liste de questions (il reste encore à les officialiser dans un document) : Questions pour certifier dans Cesiumv2 - #5 by Natha
  • Toute création d’un nouveau compte Ğ1 doit proposer par défaut la création d’un compte via un mnemonic conformément à la RFC 0018 Multilang Mnemonic. (La création ou l’import d’un compte par d’autres méthodes est tolérée pour des raisons de compatibilité, mais ne doit pas être mise en avant).
  • S’assurer que l’utilisateur a bien noté sa phrase de restauration avant de l’autoriser à devenir membre de la Toile de confiance.
  • S’assurer que l’utilisateur a bien noté sa phrase de restauration avant de l’autoriser à utiliser son compte si le solde du compte dépasse 100 DU (exprimés en nombre de DU courants).
  • Demander à l’utilisateur sa phrase de restauration avant d’exécuter un transfert de plus de 100 DU.
  • La phrase de restauration, ou tout secret permettant de retrouver tout ou partie de la clé privée de l’utilisateur, ne doit jamais être stockée en clair dans une mémoire non volatile.
  • La phrase de restauration, ou tout secret permettant de retrouver tout ou partie de la clé privée de l’utilisateur, ne doit jamais rester stockée en clair dans la mémoire vive pendant plus d’1 h. Ce qui implique que toute mise en veille ou tout verrouillage de l’appareil doit déclencher la suppression des secrets en mémoire si l’app ne peut pas avoir la garantie du système qu’elle pourra s’exécuter en tâche de fond pendant la durée restante.
  • Toute suppression des secrets doit réécrire tous les espaces mémoire qui les contenaient avec des zéros : une simple désallocation ne suffit pas, car la donnée n’est pas réellement supprimée de la mémoire tant qu’elle n’a pas été réécrite.
  • Le logiciel doit être open source avec une licence libre ou ouverte. Liste des licences acceptées : AGPLv3, GPLv3, MIT, Apache 2. Le lien vers le dépôt du code doit être accessible depuis un menu de l’application.
  • Le logiciel doit être disponible au minimum en anglais, en français et en espagnol.
  • Le logiciel doit permettre d’exporter la phrase de récupération dans un format texte brut importable dans d’autres logiciels : les 12 mots à la suite, dans une chaîne UTF-8 normalisée, chacun séparé par un espace. Aucun numéro ni saut de ligne. Si le logiciel ne conserve pas la phrase de restauration, l’export n’est obligatoire que lors de la création du compte. L’application doit alors s’assurer que l’export a bien été effectué par l’utilisateur avant de supprimer toute trace de la phrase de restauration.

Avoir un tel document, avec une version faisant foi sur le GitLab de Duniter, permettrait de décider de manière objective quelles applications doivent être listées sur les sites officiels (duniter.org, monnaie-libre.fr, etc.).

Cela permettrait aussi aux développeurs d’applications de savoir clairement quels critères ils doivent remplir, et nous permettrait de faire des retours constructifs aux développeurs d’applications non conformes, basés sur des règles objectives plutôt que sur des visions personnelles de la manière dont une bonne application devrait fonctionner.

Qu’en pensez vous?

2

Non, Gecko résume déjà de manière digeste les points à connaitre sur la licence au moment de confirmer son identité, avec une case à cocher symbolisant l’accords de l’utilisateur face à ces principe. Avec un lien vers la licence complète pour ceux qui veulent. Bien plus productif que d’afficher un document légale énorme dont on est certain qu’il ne sera juste pas lu. De très loin.

No way, c’est du bullshit. L’UX de Cesium1 a ce sujet était catastrophique, c’est la meilleur idée qui a pu être inventé pour énerver les gens au plus haut point. Au bout d’un moment c’est bon on a compris tes questions arrête de me les poser à chaque fois que je certifie.
L’enfer recréé au sein d’un app, brillant.

Ca me semble être l’évidence même, qui oserait ne pas faire ça de nos jours ?

3

Bonne idée d’avoir ce document de référence, sur les bonnes pratiques d’un logiciel wallet.

Je suis d’accord avec ça, à ajouter dans Tikka asap.

J’ai une case à cocher lors de la création d’un compte. Mais le meilleur moyen est de la redemander lors d’actes importants pour la WoT. En la demandant lors de la création d’une identité (première certificat ET lors de la confirmation de celle -ci. A ajouter à Tikka asap.

Je propose plutôt de demander le mnémonique si le montant d’un transfert dépasse une certaine somme (à déterminer, voir configurable dans une application comme Tikka, mais 100 DU c’est pas mal), pas le solde du compte.

Je verrai avec Deepseek pour respecter au maximum tes recommandations de sécurité pour les secrets en mémoire vive dans Tikka.

4

Tu parles d’un transert entrant ? A quel moment faire la vérification du coup ?
Si tu parles d’un montant sortant, non seulement je ne comprends pas l’intéret, mais en plus c’est le pire moment pour demander quelque chose de cette sorte au user :sweat_smile:

5

Sortant, bien sûr. Si le PIN a été dévoilé et que le voleur veut tout transférer ?

C’est juste une proposition ! Pas taper ! :sweat_smile:

6

Ahaha, attention tu ne sais pas a qui tu t’adresse, je suis le grand méchant enfin désigné !!

Blague à part non c’est juste une remarque sur le fait qu’en terme d’UX, ce n’est pas le bon moment pour embêter l’utilisateur.

7

Et il y a un monde où Gecko serait enlevé des listings car n’insiste pas assez sur la licence, même pas une sorte de tuto infobulles dessus.

Donc c’est quand qu’on aura “se connecter avec votre wallet”, sur forum monnaie libre et jiyujin, avec Ginkgo et Gecko, et avertissement de sécurité avant de se connecter avec Ginkgo car il s’agit d’être réglo?

Depuis un moment qu’on demande, Ginkgo n’a en effet toujours pas un accès facilité à la phrase de récupération.
Ce qui gêne la compatibilité.

Par contre Ginkgo insiste bien sur la notion d’exportation et permet même de le copier coller.

8

A quel moment ?

Merci d’ouvrir soit un topic dédié à ce sujet, soit une issue, en expliquant en détails les endroits concernés et les propositions ou piste.

Aucun soucis avec ça, mais il faut en débattre de manière à s’assurer que l’UX est correct, accessible, pertinente.

9

Ben moi je considère que l’affichage en DUğ1 devrait être l’affichage par défaut. Depuis toujours cela aurait du être ainsi dès le départ, les ğ1 sur le compte sont sans intérêt, l’unité relative est la plus importante pour une monnaie respectant la TRM.

J’ai trouvé cela assez énervant sur césium 1, je n’ai pas vraiment envie de revoir ça.

10

Ça pourrait être un compromis acceptable à condition que la case à cocher précise quelque chose du genre “J’atteste avoir entièrement lu et approuvé la licence Ğ1”.
Même si certains ne la liront toujours pas en entier pour autant, l’utilisateur sera davantage conscient qu’il est censé le faire, et donc certains le feront là où ils ne le faisaient pas avant.

Ce n’est pas parce que beaucoup de gens ne lisent pas les conditions légales qu’il ne faut pas leur demander d’attester qu’ils l’ont fait.

L’UX est très importante, mais elle ne doit pas être placée au-dessus de la sécurité de la toile de confiance. Ce qui pourrait éventuellement être fait, c’est de ne plus poser N questions après les X premières certifications. Puis de ne reposer N questions qu’une fois par an pour une piqûre de rappel.

Le fait que ça énerve les gens ne doit pas être un argument. Moi aussi, ça m’énerve quand je dois répondre à des questions sur mon app bancaire pour faire un investissement (laissez-moi faire ce que je veux avec mon argent bordel). Et pourtant, certaines de ces questions m’ont permis de prendre conscience de certains risques que je ne voyais pas, et d’y réfléchir à deux fois avant de réaliser l’investissement que j’avais prévu.

Mon point, c’est que la plupart des utilisateurs qui croient respecter la licence n’ont pas réellement conscience de tous les points sur lesquels il faut être vigilant, et que poser quelques questions me semble être la seule manière de leur apporter cette vigilance.

Après, en termes d’UX, il doit être possible de rendre ça le plus digeste possible. gcheck est un exemple d’interface pour rendre ça dynamique et pas trop pénible : https://gcheck-1be171.pages.duniter.org/

C’est un moyen, mais pas le meilleur selon moi. Le meilleur moyen me semble être plutôt de demander aléatoirement un ou deux mots de la phrase lors de la création du compte, comme le font la plupart des wallets crypto.
À partir du moment où cette demande aléatoire de quelques mots a été faite une fois, et que la phrase complète est redemandée, par exemple une fois par an, pour être sûr qu’elle n’est pas perdue, ça me semble suffisant. Je ne vois pas de nécessité à redemander la phrase complète lors d’actes importants pour la WoT.

C’est une bonne idée, je vais l’ajouter, mais c’est différent de mon point et ne le remplace pas. Mon point est le scénario suivant:

  1. L’utilisateur crée un portefeuille à la volée sans noter sa phrase.
  2. L’utilisateur reçoit une grosse somme.
  3. L’utilisateur constate cette grosse somme sur son compte puis continue d’utiliser son compte pour de petites dépenses en croyant que cette grosse somme est acquise et sécurisée.

Avec ta proposition, l’utilisateur dans mon scénario ne se verra jamais demander de noter ou saisir la phrase de récupération, alors qu’il a une grosse somme sur son compte, qu’il risque donc de perdre avec le temps, car plus le temps passe, plus la probabilité de perdre ou casser son téléphone augmente.

C’est pourquoi il me semble nécessaire de s’assurer que l’utilisateur a bien noté sa phrase dès que l’app détecte qu’il a un solde élevé, sans attendre qu’il fasse une grosse dépense qui n’arrivera peut-être jamais s’il n’en a pas besoin.

C’est un bon point à rajouter dans la liste des critères : permettre l’export de la phrase de récupération “facilement”. Le problème, c’est comment définir “facilement” de manière objective ?

C’est ton point de vue, mais ce qui compte ici, ce ne sont pas les points de vue des utilisateurs habitués, mais quel doit être le paramétrage par défaut pour les nouveaux utilisateurs qui débarquent et qui ne savent même pas qu’il est possible de compter en DU.

Les nouveaux sont habitués à l’euro (ou à la monnaie fiat de leur pays), et sont habitués à compter en quantitatif depuis toujours. Afficher en DUğ1 rajoute une barrière à la compréhension, déjà bien difficile pour un nouveau.

Une fois la personne informée et plus à l’aise, elle peut décider de basculer l’affichage en DUğ1 si elle préfère, mais le comportement par défaut devrait toujours privilégi

11

Avoir à deux clics grand max à partir de la page coffre ou compte, sans logos incompréhensibles ou petits caractères intermédiaires, la possibilité de cliquer sur “afficher la phrase de restauration”, " copier la phrase de restauration", “exporter la phrase de restauration dans un fichier” ou toute solution donnant la phrase lisible, au moins pour les autres wallets.

12

Je crois que les moments pertinents pertinent pour poser des questions à l’utilisateurs ce serait :

  • au moment d’accepter une invitation à devenir membre sur la licence !

  • au moment du renouvellement d’adhésion pour les mot de la phrase de récupération !

  • pour les compte compte non membre une fois par an demander un mot de la phrase de restauration, avec la possibilité de passer si on n’as pas la phrase sous la main, et réaffichage de la demande a chaque connexion tant qu’un mot n’as pas été donné. Cette demande pourrait être plus fréquente au début (genre un mois après la création du compte) et de moins en moins avec le temps qui passe une fois tout les deux ou trois ans (a voir)

13

voici ce qui s’affiche(ra) sur Gecko après une invitation:

image
image473×1026 99.2 KB
image
image465×1034 57 KB
image
image466×1038 69.4 KB
image
image462×1034 73.5 KB
image
image462×1028 48.6 KB

image
image673×1134 99.2 KB
Capture d'écran 2026-09-16 171602
Capture d'écran 2026-09-16 171602672×1134 37.3 KB

14

D’accord avec quasi tous les points, mais je diviserais en deux listes :

  • prérequis stricts
    • affichage solde deux décimales
    • affichage solde total
    • afficher texte entier licence
    • mnemonic multilingue compatible
    • dérivation ed25519
    • pratiques de sécurité des secrets en mémoire
    • logiciel libre (jusqu’à la chaîne de build parce que la supply chain attack est très simple)
    • la création d’une identité (première certif) doit passer par un rappel des critères à vérifier sur le compte cible
  • intentions
    • vérifier la compréhension de la licence (à la place des N question aléatoires)
    • s’assurer que l’utilisateur note sa phrase de restauration (il n’y a pas moyen de le forcer, c’est plus une histoire d’intention)
    • rappeler à l’utilisateur de copier sa phrase quand beaucoup de Ğ1 sont présentes sur son compte (le critère de 100DU me paraît arbitraire, l’intention c’est “beaucoup”, à chaque dev/communauté d’en décider)
    • le logiciel doit être ouvert aux contribs d’i18n (c’est plus une intention, ça ne force pas à soi-même faire les traductions)

Parce que certains points sont à mon avis trop subtils pour trouver des bons critères objectifs qui ne cassent pas les couilles à tout le monde. Pour ceux là on peut avoir des lignes directrices, des références, des exemples, mais on doit reconnaître que c’est un travail en cours et que des évolutions sont possibles. Faire comme ça renforce les points stricts sur lesquels il ne faut pas faire de concession (la sécurité et interop par exemple).

15

J’ai trouvé sur Ginkgo le truc pour afficher la phrase de restauration en deux clics, ça s’appelle afficher la graine.

16

Excellent initiative @elois. I agree also with @HugoTrentesaux .

17

ça y est, je prend le temps de passer par là.

Je rejoint @HugoTrentesaux sur le fait de catégoriser.

Pour moi il faudrait identifier le minimum de critère qu’on considère vraiement indispensable dans tous les softs qui :

  • ont accès à un mnemonic (donc ceux qui permettent de créer un compte notament)
  • permettent d’émettre des certifications (ce ne sont pas forcément les même critères)
  • permettent d’agir depuis un compte (même si la crypto de signature est délégué à un autre soft)

A coté de ça, on peut avoir des recommandation et bonnes pratiques.

Les enjeux à considérer selon moi au travers des fonctionnalités ou absence de fonctionnalités d’un soft :

  • ce qui met en danger la communauté dans son ensemble
  • ce qui met en danger l’utilisateur
  • ce qui dissuade l’utilisation
  • ce qui dissuade la contribution (cahier des charges dissuasif pour un nouveau dev)

Dans les dangers il y a ceux de sécurité technique (perte ou usurpation de secret) mais aussi ceux d’usage/ergonomie (habituer les gens à dire qu’il ont lu et accepte quelquechose qu’il n’ont pas lu habitue à mentir/dévalorise la crédibilité d’un engagement, de même que leur demander de saisir leu mnémonic toutes les 5 minutes de peur qu’il l’oublie banalise la saisie de secrets)

De mon point de vue, on (les dev et la communauté Ğ1 en général) a été traumatisé par les pertes de brainwallet en v1. Il y a des bonnes pratiques en v2 qui me semble utile, mais le zelle me semble contre-productif fasse à des attaques du type : “J’ai développé un super nouveau site pour les juniste, regarder il est tout beau il permet plein de chose, saisissez votre phrase de récupération membre pour l’utiliser” (sauf que le site collecte les mnemonic). Si on veut se protéger de ça il faut réduire les situations où l’utilisateur a à saisir son mnémonic de manière à ce que ça reste un geste important et exptionnel que de fournir ses secrets, plus particulièrement les secrets membres.

Une bonne manière de faire selon moi serait d’avoir :

  • un compte maitre / compte de haute sécurité (compte membre, compte principal d’une asso…) qui sert à recevoir des Ğ1, à certifier (pour un compte membre), et à déléguer des droits à des comptes moins privilégiés. Ce compte, on ne le dévérouille que rarement, et peu de logiciels ont besoin de pouvoir agir depuis se compte.
  • un/des compte courant approvisionné automatiquement jusqu’à un plafond par le compte de haute sécurité pour permettre les opérations courante sans avoir besoin de dévérouiller les secrets du compte maitre/compte de haute sécurité.
  • des comptes sociaux/spécialisé capable de prouver leur appartenance au proriétaire d’un compte de haute sécurité donné, mais dont le lien peut être révoqué sans révoquer l’identité maitre. Ainsi je peux laisser un avis vérifié sur un produit sur un site dont la confiance n’a pas besoin d’être maximale, car je n’ai jamais à saisir de phrase de récupération ni même de code de dévérouillage au quotidien. Les seul cas où je dois dévérouiller le compte maitre, c’est depuis l’app qui le gère, et seulement pour accorder des droits à un compte secondaire dont je dispose ou au compte d’une tierse personne (en le certifiant par exemple)

De cette manière on pourrait par exemple avoir un compte de notification relié à l’identité maitre, dont on peu lire les notifs sans avoir besoin de dévérouiller l’identité maitre. Par exemple, pas besoin d’aller sur le compte maitre pour savoir que j’ai une certification en liste d’attente que je peux émetre. En revanche, pour l’émettre, il faudra que je dévérouille le compte maitre.

Sur un marché, le compte courant fera l’affaire et pourrait permettre de paiement simple, sans contact, mais si je dépasse un certaine somme, il faut que je passe par un compte avec un plafond plus élevé, dévérouillable avec un code PIN. Et si j’ai besoin d’encore plus, là seulement, je doit dévérouiller mon compte maitre (ou un compte de haute sécurité multi-sig que plusieurs personnes doivent signer pour pouvoir émettre une transaction).

Une app sans gestion membre/certification n’a pas besoin de cocher les prérequis en lien avec les certification

Une app qui manipule des comptes plafoné pourraient avoir des prérequis de sécurité de clef moindre, plus particulièrement là ou ça apporte des gains d’UX.

Une app dont l’UX est inhabituelle (affichage du solde fantaisiste par exemple) risque de créer de la confusion, mais ne me semble pas présenter un danger irréversible ni pour l’utilisateur ni pour la communauté. Elle dissuade peutêtre son propre usage, mais c’est aux utilisateur d’en juger.
C’est entre autre les choix d’UX qui pousse les dev à faire des appli différentes pour couvrir les même besoin avec une vision différente. Si on doit normaliser des choses, avec un tel document, selon moi ce n’est pas l’UX.

  • L’interopérabilité des phrases de récupération/restauration/mnemonic OUI clairement
  • Des bonnes pratiques de sécurité sous le capot, qui n’impacte pas l’utilisateur, pluôt oui.
  • Des bonnes pratiques de sécurité qui impacte l’utilisateur/l’UX, avec parcimonie, là où c’est vraiement nécessaire, pas plus.
  • Le respect des règles défini ailleurs → un aide mémoire pourquoi pas, mais la source de vérité est ailleurs. Pas besoin de créer un document qui dit qu’il faut afficher la license quand on certifie si la license le dit elle même. Si elle ne le dit pas, peutêtre que c’est à elle de le dire.
  • l’affichage en DU, en Ğ1, le multi-langue… on peut faire des recommandation mais pas obliger quoi que ce soit en la matière selon moi.
18

Donc ta proposition, c’est de demander aux gens de créer et de noter 3 mnémoniques différents au lieux d’un seul ? Là où G1nkgo par exemple, à l’heure actuelle, ne propose même pas d’en noter un seul à l’utilisateur ?
C’est bien ça ?

19

Just solved

verificacion_frase_recuperacion_quiz_fr_claro
verificacion_frase_recuperacion_quiz_fr_claro411×800 15.2 KB