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).
- 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.
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?