La période de tests s’est finie sur les apps compatibles v2 avec le démarrage de la Ğ1 sur Duniter v2. Les mauvaises habitudes ont-elles été prises et/ou gardées (taquin) ? Je voulais rédiger ce message bien avant ; durant la période de test sur la ĞTest #2.
Si les apps suivantes permettent l’authentification dans l’app, je recommande d’arrêter la distribution des apps via un serveur http et de privilégier la distribution via des paquets et/ou dépôts officiels, qui est à développer.
La v2 apporte la toile de confiance forgeron. Du coup, il n’y a plus de risque de perde le contrôle de la monnaie. Cependant, les utilisateurs peuvent toujours se faire voler leurs Ğ1. Cette dernière prend doucement de la valeur au fur et à mesure que le temps passe. Ça me semble une raison suffisante pour mettre en place ces mesures.
Autrement, si elles implémentent l’authentification uniquement via Duniter-connect comme Duniter-Portal et Duniter-Panel, pas de souci pour qu’elles restent en ligne.
Un site web de démo ou read-only peut toujours être disponible pour tester l’app sans authentification pour uniquement consulter la monnaie ou bien tester l’app. Comme ce fut le cas pour Cesium v1 demo.
Je comprends également que ça soit pratique d’avoir une distribution centralisée d’une app pour observer l’usage et les bugs d’une app. Dans le cas de Cesium, a été mis en place l’outil d’observabilité Sentry. Fonctionnalité qui ne serait plus disponible.
Je reviens sur ce sujet avec plus de douceur cette fois. Désolé pour la virulence que j’ai pu exprimer dans l’épisode précédent. Il s’est déjà passé 6-8 ans.
As you may know, G1ngko started out as a web wallet in response to this request:
I had just joined the G1 community (2023) and someone added me to the Spanish IT group, where they were discussing that potential web wallet and a possible telegram bot.
As a Flutter developer, I recommended using Flutter to build it, but no one took it on. So, at some point, since I prefer to walk rather than talk, I started developing it. Later, people asked for an app, etc., until now. And @kapis did the same with the superbot.
A lot of people still like to use the web version of G1nkgo (something I honestly don’t like). People without Android, or with old Androids, or with old iPhones, or… I don’t know.
For me, supporting the web version is a hassle, but maybe we can limit its functionality, like “try G1 with this instant wallet, but please install the app later…” (but I know that still this will let old junist with old devices, out of options).
By the way, as it’s related, I’ve been working these past few days on updating the Dockerfile and the generation of images/APKs/TARs via GitLab, though there’s been some regression in the tests parts:
There was also interest in having other instances besides g1nkgo.comunes.org, and I wanted to use docker as a deployment method.
Il me semble que l’idée globale derrière cette recommandation est qu’il est plus facile pour un attaquant de voler les identifiants ou d’extorquer la signature d’un payload avec la chaîne de confiance du web qu’avec la chaîne de confiance de dépôts logiciels. De plus, si on fait entrer dans les habitudes de donner son secret à une appli web, on augmente les risques de phishing. Il y a des raisons à la fois techniques et humaines à déconseiller de mettre en place ces systèmes.
J’étais également de cet avis avant, mais aujourd’hui je suis plus mitigé. Il y a tellement de failles possibles que le déficit de sécurité du web par rapport à un paquet me paraît vraiment petit devant les avantages que ça apporte.
Je pense que ça vaudrait le coup qu’on réfléchisse d’un point de vue global à des recommandations de sécurité pour développeurs et utilisateurs, à la fois d’un point de vue technique et humain.
J’ai trouvé une manière plus simple de formuler ce que je n’arrivais pas à dire avant :
Si jamais il y avait une extorsion de mot de passe, je pense que la cause racine aurait peu de chance de se situer au niveau de la chaîne de confiance du web (DNSSEC…), et plus de se situer au niveau de l’erreur humaine. À ce stade en effet il est plus risqué d’aller sur ceesium.app au lieu de cesium.app plutôt que d’installer Ǧeecko au lieu de Ǧecko (en raison des interfaces utilisateurs des magasins d’applications).
Cette extorsion de mot de passe n’aurait pas plus de chance de devenir massive dans le cas d’une application distribuée via HTTPS que via un gestionnaire de paquet.
Et la mesure de mitigation serait d’entraîner les utilisateurs à vérifier à deux fois que le nom de domaine est de confiance avant de saisir une phrase de restauration.
Dans ce contexte ça me semble pas absurde d’avoir une instance web officielle pour certaines apps. Et effectivement c’est beaucoup mieux d’un point de vue sécurité si l’app ne permet pas de saisir le mnemonic dedans, mais délègue cette responsabilité à une extension navigateur comme Duniter Connect.