Vue Réseau : affichage (dégradé) des noeuds, quand le site tourne en HTTPS. Il reste encore des bugs sur cette partie. Notamment, les noeuds non SSL finissent par disparaitre avant le temps ;(
Voilou.
Et la suite ?
D’un point de vue de la sécurité, il reste un gros travail à faire.
Je rappelles au passage que Cesium n’est pas en version stable (v0.X oblige !).
il faudra donc :
ne pas stocker la clef privée, même temporairement. J’ajouterai une option dans les paramètres, pourq que chacun puisse choisir sont mode de fonctionnement :
réauthenthification à chaque opération
réauthenthification toutes les X minutes
et peut etre une option pour définir un code pin, plus court, à saisir à chaque ordre de paiement. A voir
Mais pourquoi ??? C’est complètement ET inutile ET dangereux ! Cesium tout comme Sakia doit permettre de consulter n’importe quelle pubkey, cela n’implique en rien une quelconque signature ! La signature n’est nécessaire que et uniquement que pour signer des documents ! Transactions + Certifications + Demande d’entrée + Renouvellement, c’est tout (+ création d’un compte, mais ce n’est pas une signature, c’est générer une pubkey - quoi d’autre !?). Ce qui ne demande de signature que lors de l’opération, tout le reste n’est que consultation et ne demande absolument rien de spécial à l’utilisateur !
Uniquement pour ceux qui voudraient stocker une (ou plusieurs) clé(s) privée(s) (d’un ou plusieurs porte-monnaies, mais surtout pas du compte membre !?) pour raccourcir le temps de la signature…
EDIT : réauthenthification toutes les X minutes (Si opérations - nécessitant la signature - effectuées)
Je parle du Cas d’Utilisation suivant : “Je veux faire plusieurs opérations à la suite”, dans lequel l’utilisateur souhaite s’authentifier une fois et pas à chacune de ses opérations.
Cf ce qui se fait dans les portails bancaires actuels.
Mais j’entends bien que ce CU ne t’intéresse pas. Tu pourras donc utiliser l’option adéquate.
Ok, mais c’est risqué… Pourquoi ne pas “faire plusieurs opéraitons à la suite”, et ne réaliser la signature qu’à la toute fin pour générer le ou les documents, de manière à ne pas exposer la clé, surtout sur un client web ?!
Ne vaudrait-il pas dédier Cesium avant tout sur ce qu’il fait de mieux = la consultation graphique très chouette, et réserver son utilisation de clé privée préférentiellement à des porte-monnaie où l’on conseille l’utilisateur de n’y mettre que relativement peu de monnaie !? Ainsi le risque sera grandement limité. Et réserver les opérations de stock lourds à des clients dédiés qui fonctionnent en local offline (typiquement Sakia en mode offline) !?
Ce serait un boulot important que de faire cela : stocker les documents à signer, dans un genre de panier, et les valider à la fin. Pourquoi pas…
Cesium peut très bien donner naissance à un client lourd, intégrant son propre navigateur. Un ticket est ouvert à ce sujet.
Par ailleurs, l’usage de l’application sur smartphone est très comparable à celle d’un laptop, chez soi, avec un client lourd. D’ailleurs l’applciation Android peut très bien s’installer sur une tablette, qui ne quitte jamais la maison, contrairement à un smartphone.
On peut aussi imaginer un smartphone qui reste à la maison. Quel différence avec un client lourd sur un PC fixe ?
Le Cas d’utilisation “Utiliser Cesium pour la consultation uniquement” (et pas forcément sur mes comptes) n’était pas dans mes objectifs. Mais rien n’empêche d’autres personnes de le faire. Mon objectif est bien de disposer d’un client pratique et ergonomique pour faire mes opérations.
On est loin de pouvoir arriver à cela, avec Sakia comme n’importe quel autre outil. Il suffit d’essayer pour s’en convaincre.
Notamment parceque, n’ayant pas accès au réseau, ton “client offline” ne peut pas générer lui même les documents à signer (par exemple, il ne peut connaitre les Blockstamp à inclure dans le doc). Il se contente simplement de signer un document qu’on leur présente, sans pouvoir vérifier si les info incluses existes ou non en BlockChain.
Le cas d’utilisation pourrait être “Signer les documents sans exposer ma clef sur Internet (=via un appareil déconnecté)” : (cf ticket #399)
l’utilisateur demande au logiciel client connecté de généré un document qu’il souhaite signer sans exposer sa clef, via un client offline;
le logiciel client connecté génére le document, sans la signature, puis émet le document, par exemple sous forme d’image (QR Code) ou via NFC
le client offline lit le document (et valide son format) et renvoi à son tour la signature, sous la même forme (QRCode ou NFC)
Le logiciel client connecté lit la signatuire et la vérifie, puis émet sur le réseau le document signé.
Tout se passe comme si uniquement la procédure de signature était donc déléguée du client connecté vers le client déconnecté.
(au passage, c’est exactement la fonctionnalité que pourrait remplir une carte avec fonction de cryptage intégrée, comme existant pour le BitCoin aujourd’hui).
La différence c’est Androïd qui est un poil fumeux… + le hardware qui n’est pas clair, sinon on aurait déjà des OS “mobiles” 100% libres, or ce n’est pas le cas.
Certes, il n’empêche que saisir une clé privée pour démarrer une consultation qui est toujours préalable à toute opération n’est pas une opération ni nécessaire, ni naturelle. A contrario stocker des clés publiques sur un client ne génère aucun risque. Une recherche par ID ou par début de clé permet de consulter n’importe quels comptes, y compris les siens, sans aucune saisie de clé secrète. Le bouton préalable “se connecter” sur Cesium est donc superflu et inutilement dangereux.
Un client comme Sakia n’a pas de raison de ne pas avoir la blockchain en local, il devrait l’avoir d’ailleurs, au pire il peut se connecter à un noeud Duniter local offline qu’on aura synchronisé préalablement (et même un noeud miroir suffit pour ça).
A l’avenir, même si ca vous parait pénible, je parlerais d’avantage de CU (Cas d’utilisation) afin que chacun comprenne ce que fait Cesium ou ce qu’il ne fait pas.
Par exemple, il n’implémente pas le CU “Consulter d’autres comptes que les miens”, mais bien “utiliser ma clef pour faire plusieurs opéraitons à la suite”.
Erreur, cela fait plus d’un an que je suis sous UbuntuPhone. Les prochains devraient sortir d’ici un an, j’ai bon espoir là dessus vu comment avance les MàJ.
J’utilise Firefox OS depuis 2 ans, c’était un super projet et je suis super content de l’utiliser. Malheureusement, le développement a complètement cessé au sein de la fondation et la communauté a un rythme presque éteint sur ce sujet…
Ubuntu phone avait un très bon rythme de développement jusqu’à janvier dernier, et j’avais commencé à me tourner vers cette solution suite au quasi arrêt de FFOS, malheureusement, cette fois, c’est la communauté qui semble avoir mis un coup d’arrêt à l’entreprise qui développe Ubuntu, lisez plutốt : http://www.numerama.com/tech/238172-mark-shuttleworth-voir-des-gens-brillants-faire-des-choses-brillantes-grace-a-ubuntu-cest-ma-fierte.html
Je pense donc que ce n’est pas une priorité aujourd’hui de s’occuper d’autre OS pour ordipoche que LineageOS et CyanogenOS les descendant de feu CyanogenMod (un fork plus libre d’android, le tout étant limité par le hardware comme l’a dit Galuel). FFOS étant du pure web, il n’y a rien à faire, Cesium s’y installe très facilement déjà.
Bon en même temps, le build vers ubuntu phone n’a pas l’air trop impossible
Mais, messieurs (@FugazziPL, @Thatoo…) , quels cibles choisir pour le build sur téléphone :
Mais hors de question que je m’en sépare !
