Concernant la perte de mots de passe il me semble qu’il est déjà obligatoire dans cesium de télécharger son document de révocation lors de la création d’un compte membre.
En revanche, je suis opposé a l’idée de rendre obligatoire les questions secrète, je n’ai jamais été favorable a cette idée qui peut constitué une faille de sécurité (on peut potentiellement trouver les réponses au questions par enquête sociale).
Ce qui est différent pour les crédentials car il doivent être générés aléatoirement (comme indiqué dans les recommandations de sécurité).
La possibilité de créer des questions secrète doit donc rester optionnelle, a la liberté de l’utilisateur 
Tu répond a un cas cité par moul qui correspond a une erreur de saisie dans la clé publique, et non pas a une erreur de destinataire, les Ğ1 en question sont donc arrivées sur un compte qui n’appartiens a personne.
Pour ce type de problème c’est un nouveau format d’adresse avec checksum intégrée qu’il faut mettre en place, @Tortue avait déjà proposé un format de checksum aux rml9 , ça pourrait d’ores et déjà être intégré dans Cesium. Mais pour que ce soit efficace il faudrais que se nouveau format (pubkey avec checksum) soit utilisé partout (cesium, silkaj, gchange, gannonce, pages web avec pubkey G1, etc).
Une autre solution (que je souhaite a long terme), serait de passer a un système d’adresses similaire a celui du bitcoin pour lequel la checksum serait intégrée de base dans l’adresse, il serait alors quasiment impossible de saisir une adresse “inexistante” (par quasiment j’entends encore moins probable que de gagner au loto plusieurs fois de suite).
@bpresles en revanche on s’éloigne ici du sujet de ce post. Il me semble que les 2 problématiques que tu expose ne font pas parties des arguments en faveur d’une fermeture de Cesium web.
L’argument principal étant le possible vol en masse de clés privées de membre pour s’en servir pour calculer tout les blocs et donc prendre le contrôle total de la blockchain (ce qui est possible aujourd’hui en volant une quinzaine de clés membres et en disposant d’une très grosse puissance de calcul).
Il faut bien comprendre qu’une tel attaque est d’autant plus dangereuse qu’il est très difficile de la voir venir, un membre lambda ne se rendra pas compte qu’il se met a trouver des blocs, le membre lambda n’a pas Duniter et ne regarde pas ces truc la.
L’argument secondaire étant le possible vol en masse de clés privées de membre pour s’en servir pour créer et certifier plein de faux comptes (attaque sybil), bien que ce scénario d’attaque est moins crédible car le membre lambda se rendra plus facilement compte qu’il émet des certifications qui ne sont pas de son fait, et donc le signalera ici et donc nous l’inviterons a révoquer son compte et pourrons réagir et enquêter, nous pourrons même exclure en dur les pubkey incriminés, c’est infiniment plus traçable, visible et lent que l’autre scénario d’attaque, c’est pour cette raison que je suis convaincu que se second scénario ne peu pas mettre en péril la Ğ1.