Je plussoie @jytou et je réitère ma proposition de ne pas fermer nos instance web de cesium mais d’y interdire la connexion d’un compte membre, c’est assez simple a développer. Je propose qu’on lance un crowfunding pour la réalisation de ce développement, on a déjà plusieurs antécédents ou un crowfunding a trouvé son développeur après coup 
6 Likes
Je suis assez d’accord pour limiter les instances web aux accès en lecture seule + comptes portefeuilles uniquement. Et je suis volontaire pour l’implémenter dans Cesium.
Cela étant dit, il faudra aussi terminer la version macOS desktop aussi pour que tous les OS desktop majeurs aient une version non web isntallable.
Aujourd’hui j’arrive à la builder en app macOS, mais comme sur tablette iOS, il y a un certain nombre d’élément de la GUI qui disparaissent au delà d’une certaine largeur de fenêtre (i.e: les éléments normalement visible sur le web et en desktop (Windows/Linux) ne le sont pas sur iPad et macOS). J’ai pas encore pris le temps de regarder pourquoi, mais de toute façon il va falloir pour apporter un vrai support à la fois sur iPad et macOS.
Je pourrai regarder cela par la même occasion.
11 Likes
La sécurité est importante, mais ne doit pas nous faire virer dans la paranoïa…
Il me semble que couper brutalement des services auxquels les utilisateurs actuels de la Ḡ1 ont l’habitude d’accéder serait désastreux!
Je trouve dommage d’implémenter la suspicion pour un système qui pour moi défend la liberté et le non-jugement. Et plutôt que de s’inquiéter pour un danger qui n’existe pas forcément…
On pourrait essayer d’établir une Node WOT.
Par une charte que s’imposent les opérateurs d’interfaces à la Ḡ1 (Cesium et ceux à venir…) définissant de façon commune un protocole de sécurité à respecter (audit du code, signature pgp, hashage, etc…) qui permettrait de définir à minima une relation de confiance.
NB: Il ne faudrait pas oublier les propriétaires de noeuds Duniter non plus… La sécurité de clefs membres y est en jeu également… Rien ne garanti qu’un noeud duniter ne puisse pas être compromis… et qu’un vol massif de clefs ait lieu… Bon j’arrête. Je redeviens parano 
1 Like
Alors je ne suis pas d’accords avec cette analyse:
- Retirer les fonctionnalités impliquant les identifiants se répercuterai automatiquement sur toutes les instances hébergés décidant simplement de mettre à jours Cesium. Au bout de 6 mois, les instances obsolètes (et je ne pense pas qu’il en reste vue le peut d’instance actuellement hébergé justement, et le lobbying qu’on fera auprès des admins) seraient évidament repéré, et il est évidement beaucoup plus simple de maintenir une liste noire d’instance Cesium obsolètes ou proposant le login et surtout convaincre les gens d’en choisir une autre, que si seul des instances “dissidentes” se permettent d’héberger Cesium sans possibilité d’empêcher le login…
- Supprimer nos instances web va évidament avec une interdiction! Celle d’interdir aux gens d’héberger Cesium!! Je trouve franchement cette interdiction plus lourde que le première.
Je comprends tes remarques, mais je pense que avoir des instances hébergées en lecture seule va devenir pénible à la longue pour les utilisateurs et compliqué à expliquer pour les promoteurs/formateurs :
- Alors c’est simple : y a des bons sites Cesium où tu ne peux rien faire que regarder et des mauvais sites où tu peux tout faire mais faut pas c’est mal, des bons chasseurs et des… etc, pigé ? non ?.
Alors que dire aux utilisateurs que si c’est sur le web, c’est un piège, n’y va pas, point barre. C’est clair, net et précis. Cesium est une application, pas un site web. Comme Candy-crush.
Et on recentre les énergies sur les packages plutôt que sur un Cesium à deux vitesses qui compliquerai l’écosystème et la communication. (Qui la complique déjà, la preuve : cette discussion ne devrait pas avoir lieu). Amha.
N.B.: @kimamila, Cesium est une application fantastique et précieuse pour l’écosystème, ce n’est pas pour l’interdire où réduire son importance que je soutiens la nécessité de l’arrêt de l’hébergement web, mais (après une sérieuse réflexion de ma part) pour une sécurisation et une simplification de ses usages. Et je pense sincèrement que Cesium en tant qu’application multi-plateforme PC, Mac, Linux, Android, etc, a tout à y gagner. Bien amicalement.
3 Likes
J’ai travaillé sur la version web sans support de la création et de l’identification d’un compte membre. Vous trouverez une archive de cette version à cette adresse: https://www.cloud-libre.eu/index.php/s/wWxqrpio2zQHReK
L’implémentation actuelle consiste à:
- Ne pas du tout proposer la création de compte membre sur le web, le scénario de création déclenche automatiquement la création d’un compte portefeuille simple.
- A l’identification, si le couple identifiant secret/mot de passe correspond à un compte membre et que Cesium s’exécute sur navigateur (ionic.Platform.is(‹ browser ›)), alors le message d’erreur suivant s’affiche:
« La connexion à un compte membre n’est pas autorisée depuis un navigateur web.
Télécharger la version mobile ou ordinateur de Cesium. »
Je suis intéressé par vos retours et remarques.
7 Likes
Il y a quelque chose qui m’échappe techniquement: si on a saisi des identifiants de compte membre sur une site usurpé qui cherche à récupérer ces données, peu importe le message qui apparait alors, le mal est déjà fait, ou il y a un truc qui m’échappe?
Est-ce qu’il ne faut pas plutôt alerter le visiteur AVANT de saisir ses identifiants? Mais alors rien n’empêche un site mal intentionné de ne pas afficher cette alerte…
2 Likes
@jul Exact, on peux ajouter un message d’information dans la fenêtre d’identification dans ce cas.
Il peut aussi y avoir la solution de n’autoriser aucune authentification depuis le web, seulement de la consultation en lecture seule, en retirant (au build) directement le code servant à l’identification et aux opérations nécessitant l’identification.
Car sinon une instance compromis peut toujours activer le code désactivé sur le browser, s’il est présent.
Est-ce que cela conviendrait que sur navigateur cela soit de la lecture seule ? Ce qui veut dire désactivation de toutes les opérations nécessitant l’identification (création de compte, identification, virement…) ?
Voici un build qui est purement en lecture seul: https://www.cloud-libre.eu/index.php/s/DjHqrrdJN8aaXzi
1 Like
Oui c’était ma proposition
Au passage le certificat SSL de g1.duniter.fr est expiré, plus rien ne garanti que cela pointe toujours au bon endroit depuis Dimanche…
Je crois que seul @kimamila à accès à ce serveur.
J’ai modifié l’archive de la version lecture seule, en ajoutant un message d’info sur la page d’accueil invitant à télécharger la version mobile ou ordinateur: https://www.cloud-libre.eu/index.php/s/DjHqrrdJN8aaXzi
L’important est que l’utilisateur ait vu en premier des instances honnêtes (conseillées par les premiers certificateurs par exemple), donc soit au courant du problème. Il est sensibilisé pour la suite.
1 Like
Merci @bpresles mais ça me semble un peu trop restrictif, on pourrai conserver la connexion par clé publique afin de permettre la consultation d’un compte
@elois
En fait, on peut déjà via l’annuaire accéder à n’importe quel compte, y compris le sien, par clé publique ou pseudo.
Je peux effectivement ajouter un lien qui ouvre une modal permettant de taper une clé publique ou pseudo et rediriger directement sur la page du compte, sans véritable authentification.
3 Likes
Désolé de faire le rabat joie, mais vous faites exactement ce que je préconise de ne pas faire.
-
Un Cesium où l’on peut rentrer des identifiants va permettre de capturer des comptes membres, message d’erreur ou pas. A proscrire car totalement inutile.
-
Un Cesium web en lecture seule à très peu d’intérêt et si une personne trouve un site ou l’on peut se connecter il ira, et bon courage pour communiquer et prévenir tout le monde. Vous ferez comment ?
Vous allez créer une confusion en terme de communication qui n’est pas souhaitable.
Je vous suggère de consacrer votre énergie à la transition vers un web sans Cesium, par le choix d’une date butoir, un accompagnement des utilisateurs et un renforcement des énergies sur les packages mac, pc, linux, android…
Voilà, fin de la parenthèse rabat joyeuse… Vous pouvez continuer a exercer vos légitimes libertés et vos contributions qui sont précieuses.
Pour ma part je continue à dissuader les utilisateurs d’utiliser les instances web et travail au retour de Sakia qui, avec l’aide d’autres contributeurs, deviendra j’espère un client sécurisé de référence, convivial et complet.
5 Likes
Pareil, j’essaye tant bien que mal d’aller dans la même direction avec Silkaj, qui reste en ligne de commande pour l’instant vu le peu d’énergie disponible. L’énergie est actuellement focalisée sur le cœur.
Au vu de ce fil de discussion, il n’y a que les développeurs de clients de bureau, mobile, CLI qui voient ce problème de Césium d’un mauvais œil. Surement, car ils savent quels sont les problèmes encourus.
Vu le non consensus de la manière de gérer ce problème dans les différentes approches, le meilleur est que chacun applique la méthode qui lui semble la plus juste au vu des arguments étayés dans ce fil de discussions.
3 Likes
J’ai aussi l’erreur du certificat SSL expiré (en essayant d’utiliser un lien cesium sur gannonce), et j’ai aussi une erreur sur mon appli cesium sous android qui me dit que g1.data.duniter.fr est injoignable ou adresse invalide.
Du coup je suis un peu perdu, l’appli android a quand même besoin d’un des se connecter à un nœud de données, est-ce considéré comme « dangereux » aussi ? (le comportement est le même sur les versions desktop ?)
Et l’appli me propose d’utiliser un autre nœud de données (g1.data.le-sou.org), comment est gérée la confiance avec les autres nœuds ? Est-ce équivalent ? (sur le sujet du certificat SSL sur le forum duniter, quelqu’un dit qu’il manque des données)
Moi qui me disais à l’époque que cette toile de confiance décentralisée a surement des failles.
Ben, je pense qu’aujourd’hui ça ne soit plus la priorité, et que c’est bien ce genre d’outils qui ouvre une faille exploitable très aisément pour la confiance en notre monnaie.