Un prototype de Lupo Libero est disponible ! Pour rappel, Lupo est un futur service de stockage de fichiers sur internet, actuellement en campagne de financement participatif.
Voici les principales différences entre Lupo et ce qui existe déjà :
- toute la partie logicielle est sous licence libre MIT ;
- les fichiers (ainsi que leurs métadonnées) sont chiffrés (= verrouillés) de bout-en-bout (ou "côté client") : ils sont chiffrés avant d'être envoyés sur Internet, de sorte qu'ils ne peuvent être utilisés/lus sans le mot de passe de l'utilisateur ;
- le chiffrement n'est pas optionnel ;
- il est possible et simple de partager un seul fichier alors qu'ils sont tous chiffrés (très peu de services le permettent) ; aucun mot de passe additionnel n'est nécessaire pour chaque partage.
Ce prototype vous permet de visiter le futur service. Un guide présent sur chaque page vous donnera des informations sur le fonctionnement ainsi que des détails techniques.
À noter également que :
- le texte de la campagne de financement a été grandement simplifié ;
- le code source est disponible sur Github ;
- une page du wiki (sur Github également) liste les différences entre le prototype et la première version de Lupo Libero ;
- il y aura prochainement plus de détails sur l'implémentation sur ce même wiki.
Il ne reste plus que sept jours avant la fin de la campagne de financement. C'est très court mais si ce projet vous intéresse, vous n'avez rien à perdre à le soutenir :) : en cas de succès, certaines contreparties sont particulièrement intéressantes (des gigaoctets à vie) et en cas d'échec tous les contributeurs seront intégralement remboursés.
Aller plus loin
- Prototype (757 clics)
- Site de la campagne (Indiegogo) (485 clics)
- Site officiel (502 clics)
- Code source (github) (163 clics)
- Wiki (75 clics)
- Différences entre le prototype et la première version (130 clics)
- Dépêche sur la campagne de financement participatif (61 clics)
# Je n'ai pas très bien compris
Posté par SaintGermain . Évalué à 6.
Bonjour,
J'ai cliqué sur le site de la campagne, le site officiel, le wiki et les "différences avec les autres services" mais je n'ai toujours pas très bien compris.
(d'ailleurs "différences avec les autres services" est mal nommé je pense car le contenu n'est pas en rapport avec le titre)
Je copie-colle mon commentaire lors de la dernière dépêche sur le sujet :
Si vous faites cela pour le fun et pour apprendre, pas de soucis.
Sinon il me semble qu'il serait plus rapide de contribuer aux logiciels libres existants pour atteindre le même résultat ?
Par exemple rendre Tahoe-LAFS plus facile d'usage ou améliorer la partie chiffrement de Seafile ?
Je me trompe peut-être, mais c'est pourquoi j'aurais besoin d'un vrai comparatif avec les autres services/logiciels pour comprendre pourquoi je devrais donner à Lupo Lubero et pas aux autres.
En espérant que cela vous aide,
P.S. : Seafile j'ai finalement testé et approuvé ! Ce n'est pas encore au niveau de Dropbox mais malgré ses défauts (non rédhibitoires) j'ai l'impression qu'il prend le bon chemin pour y arriver.
[^] # Re: Je n'ai pas très bien compris
Posté par gnumdk (site web personnel) . Évalué à 2.
Comme je ne connais pas Dropbox, je suis curieux, quels sont les défauts en question? :)
[^] # Re: Je n'ai pas très bien compris
Posté par SaintGermain . Évalué à 3.
Pas mal de petits détails en fait.
Par exemple :
Je vais pas lister tous les petits détails car cela en ferait des tartines pour pas grand chose.
Le plus simple est quand même de tester Dropbox et de voir que beaucoup d'argent est dépensé de leur côté pour rendre l'expérience la plus facile et intuitive possible.
Mais je suis extrêmement content de Seafile car il a la fonctionnalité la plus importante à mes yeux : je reste maître de mes données ! ;-)
[^] # Re: Je n'ai pas très bien compris
Posté par lupolibero . Évalué à 4.
Bonjour,
Effectivement il y a une erreur pour "Différences avec les autres services", en réalité il s'agit de "Différences entre le prototype et la première version". Si un modérateur passe par ici, je le/la remercierais grandement de bien vouloir corriger cette petite erreur :) (ou de me signaler comment le faire, si cela est possible).
En ce qui concerne le fait de se baser sur un logiciel existant et de lui ajouter des fonctionnalités, c'est une question qui revient très souvent et je le comprends tout à fait : c'est une des richesses du libre que de pouvoir mutualiser. Mais il y a au moins un cas où cette stratégie n'est pas aussi intéressante qu'il y parait : lorsque l'on veut faire quelque chose de très différent de ce qui existe. Bien sûr la première version de Lupo, même si elle apporte des améliorations au stockage en ligne, pourrait très bien être bâtie en utilisant des briques existantes (SeaFile par exemple) mais pour nous cette première version n'est en réalité qu'une étape dont l'objectif est de créer un socle de stockage/synchronisation de données (quel que soit leur type, fichier ou autre) qui puisse facilement évoluer dans deux directions :
- ajout d'autre types de données (gestion de mots de passes, marques-pages, contacts, messagerie, etc.) ;
- décentralisation
Et c'est surtout ce deuxième point qui nous a fait choisir de ne pas réutiliser SeaFile ou un autre : il n'est absolument pas trivial de décentraliser un logiciel. Pour ne donner qu'un exemple (que je donne également sur le wiki ou dans le prototype) : l'authentification, sur SeaFile ou tout autre service centralisé, consiste à envoyer au serveur un identifiant et un mot de passe et celui-ci vérifie qu'ils correspondent bien à ce qu'il a stocké dans sa base de données. Dans un système décentralisé ce n'est pas possible : chaque noeud est un serveur donc qui peut vérifier et affirmer que je suis bien qui je prétends être ? La solution que nous avons choisi est celle de la cryptographie : le navigateur génère une clé de façon déterministe (et donc répétable) à partir de l'identifiant et du mot de passe. Cette clé servira à chiffrer les éléments importants de l'espace de stockage de l'utilisateur (d'autres clés de chiffrement, l'identifiant du répertoire racine, etc.). Et cette forme d'authentification ne nécessite pas de serveur.
De manière plus générale cette stratégie de préparation à la décentralisation consiste à transférer autant que possible les opérations du serveur vers le client (pour l'instant : le navigateur seulement). Dans notre cas le serveur n'est qu'une base de données, mais pas n'importe laquelle, une qui a de très grandes capacités de synchronisation : CouchDB. Je la cite car c'est là que nous utilisons vraiment de l'existant parce qu'il est tout à fait compatible avec les futures version de Lupo Libero et cela va grandement nous faciliter la synchronisation qui n'est pas une tâche aisée.
Et nous allons également utiliser autant que possible les technologies développées par d'autres logiciels libres, comme par exemple, zfec.
J'espère avoir bien répondu à votre question :)
[^] # Re: Je n'ai pas très bien compris
Posté par SaintGermain . Évalué à 2. Dernière modification le 24 juin 2014 à 16:57.
Merci d'avoir répondu mais malheureusement je n'ai qu'en partie la réponse à ma question : quel est vraiment la spécificité de Lubo Libero par rapport aux autres solutions ?
En substance vous décrivez Lubo Libero comme
Mais si je prends Tahoe-LAFS par exemple c'est décrit comme :
Donc sur le principe je ne vois pas très bien pourquoi vous ne pouvez pas vous appuyer sur Tahoe-LAFS qui est chiffré et décentralisé.
Mais ne répondez surtout pas à cet exemple spécifiquement, ce n'est qu'un exemple !
Ce que je souhaite vous faire comprendre en substance, c'est que vu le nombre important de solutions existantes sur le marché, le plus simple serait de faire un beau tableau avec les principales fonctionnalités de Lubo Libero et des autres solutions pour pouvoir vraiment comparer et comprendre.
[^] # Re: Je n'ai pas très bien compris
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Test
Posté par voxmundix . Évalué à 3. Dernière modification le 24 juin 2014 à 13:11.
Je suis en train de tester la bête :)
Se serait bien d'intégrer une barre de chargement en javascript pour l'upload histoire de savoir où en est le fichier :)
C'est bien pour le partage de fichier et la création d'un album photos/images/arts, par contre niveau vidéos/audio c'est pas terrible (nécessite le téléchargement du fichier complet, ne supporte pas le flux streaming comme un VLC lisant via sshfs/sftp).
Pour la partie partage semi-public d'un NAS ça peut le faire (ça évite le mal de tête de la gestion des droits linux ^ ^ ) :)
Bonne continuation et bonne chance :)
[^] # Re: Test
Posté par lupolibero . Évalué à 1.
Bonjour,
La barre de chargement est dans les bacs :)
Il est également prévu d'améliorer l'intégration d'un maximum de types de fichiers (vidéos, pdf, textes, etc.).
Mais je ne vous promets pas que tout ceci soit ajouté tout de suite :)
Merci pour les encouragements !
# Quelques remarques
Posté par obsidien . Évalué à 2.
Pour un outil qui propose du chiffrement de bout en bout, je trouve gênant qu'il n'y ait pas d'accès HTTPS par défaut à cette démo.
D'autre part, le fait que le partage soit limité aux utilisateurs inscrits est également problématique pour moi.
A part ça, c'est à mon avis dommage de partir sur une énième solution plutôt que de se greffer à de l'existant (Seafile, par exemple) déjà tout à fait fonctionnel.
Je vous souhaite néanmoins le meilleur pour ce projet.
[^] # Re: Quelques remarques
Posté par lupolibero . Évalué à 5.
Le HTTPS vous semble plus nécessaire pour un site qui fait du chiffrement de bout en bout que pour un site sans chiffrement ? J'avoue ne pas trop comprendre. Toutes les données sont chiffrées dans le navigateur donc ce qui voyage sur le réseau est chiffré (ainsi que ce qui est stocké sur le serveur).
Nous envisageons de permettre le partage avec les utilisateurs non inscrits. Je ne sais pas encore si cette fonctionnalité sera ajouté au prototype car si elle l'est, de part l'implémentation actuelle du système de chiffrement des fichiers, il y aura une grosse faille de sécurité (qui peut être acceptable pour un prototype) : la clé de l'utilisateur sera transmise dans une url. Bien entendu ce problème n'existera pas dans la première version de Lupo. La clé contenue dans l'url sera seulement celle du fichier partagé.
Je ne reviens pas sur les raisons qui nous ont poussé à ne pas utiliser SeaFile ou une autre solution existante car je viens d'y répondre longuement dans un autre commentaire (avant que vous ne postiez le vôtre).
Merci pour les encouragements :)
[^] # Re: Quelques remarques
Posté par obsidien . Évalué à 1. Dernière modification le 24 juin 2014 à 22:50.
Effectivement, autant pour moi pour le HTTPS c'était une erreur !
J'ai bien lu votre réponse qui apporte les éclaircissements donc j'avais besoin sur le pourquoi du comment vous n'êtes pas parti sur une solution existante type Seafile.
[^] # Re: Quelques remarques
Posté par simon2cyrene . Évalué à 2.
Pour une page d'authentification user/password, ce serait plus sérieux, non ?
[^] # Re: Quelques remarques
Posté par lupolibero . Évalué à 2.
Les identifiants ne sont pas envoyés au serveur donc cela n'apporte rien à cette authentification qui est de type cryptographique (voir le wiki)
[^] # Re: Quelques remarques
Posté par flan (site web personnel) . Évalué à 1.
Le HTTPS permet d'être sûr qu'on parle avec le bon serveur
[^] # Re: Quelques remarques
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Juste pour chipoter : le HTTPS permet d'être sûr que l'on parle avec un certificat plausible pour le site en question, avec une autorité de certification fournie dans le navigateur. Donc les cas gérés sont certificat obsolète, certificat pour un mauvais domaine, certificat MiTM à l'arrache, etc. Et les cas non-gérés : autorité de certification (méchants, employeurs, agences de renseignement, incompétents, etc.) ayant signé un certificat pipoté pour ce domaine, ou MiTM avec une autorité de certification conciliante.
De base, le HTTPS ne protège pas du fait que le certificat utilisé a changé entre hier et aujourd'hui, sans raison valable.
# Hmm
Posté par gnumdk (site web personnel) . Évalué à 0.
J'avoue que je comprend pas trop le projet :p
Ca s'appelle https
Et si le but est d'empêcher l'hébergeur d'avoir accès aux données, vu que ça doit prendre 10 secondes de modifier le code pour récupérer les identifiants des utilisateurs, non je vois vraiment pas.
Que je sache, quand j'envoie un fichier sur mon serveur seafile, les données partent chiffrées(https) et le restent si ma bibliothèque l'est.
Mais dans tout les cas (seafile ou ce projet), si je ne suis pas l'admin du serveur qui héberge les fichiers, forcément qu'il y'a moyen de récupérer les mots de passe des utilisateurs. C'est où que j'ai faux vu que j'imagine que j'ai loupé un truc.
[^] # Re: Hmm
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu as loupé un truc.
Qui te dis que l'admin du serveur a ton login/pass? Il a des fichiers chiffrés, point.
Tu penses chiffrage sur le cable ("https"), ça discute chiffrage de bout en bout (chiffré aussi sur le disque du serveur, jamais déchiffré par le serveur).
[^] # Re: Hmm
Posté par gnumdk (site web personnel) . Évalué à 6.
Mais le code javascript qui fait le chiffrement, il vient bien du site web de l'admin, donc si avec le login+mot de passe je peux déchiffrer les fichiers, qu'est ce qui empêche de modifier le js pour renvoyer les identifiants des utilisateurs à l'admin?
[^] # Re: Hmm
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 25 juin 2014 à 09:49.
Tu scannes le JavaScript à chaque fois (OK, impossible en pratique)
Tu n'utilises jamais une partie web. Tu as un client indépendant du serveur, installé une bonne fois pour toute sur ta machine.
Je n'ai peut-être pas assez regardé en détail l'offre, mais clair que si il y a une partie web avec du JavaScript, ben par design la sécurité est morte, autant s'installer un serveur seafile, niveau sécurité c'est pareil si tu gère le serveur, et si tu gère pas le serveur autant prendre Dropbox.
J'avais compris que le chiffrage se faisait niveau client, sans aucune interface sur le serveur (ça casserait tout la partie interessante sur la sécurité qui est mise en avant)
[^] # Re: Hmm
Posté par lupolibero . Évalué à 1.
Bonjour,
Un client "installé une bonne fois pour toute", ça n'existe pas (ou plus) car il est forcément mis à jour et le plus souvent automatiquement pour les petites mises à jour. Et il est tout à fait faisable de glisser la faille à laquelle vous faites référence (récupération des identifiants des utilisateurs) par ce moyen.
Avec le javascript, la mise en place volontaire de ce type de faille est juste un peu plus facile.
Nous étudions plusieurs pistes pour améliorer cela :
- stocker le code de l'application dans le navigateur et ne le modifier qu'en cas de réception d'une mise à jour dûment signée par la clé du gestionnaire du dépôt ; solution la plus intéressante puisque sans installation et donc utilisée par tout le monde, mais la faisabilité technique reste à valider ;
- proposer une extension de navigateur qui vérifierait que le code est correctement signé avant de l'exécuter, en utilisant le certificat HTTPS ; intéressant aussi parce que ça apporte une plus grande sécurité, mais la proportion de gens qui installeront cette extension risque d'être faible ;
- faire servir l'application par le daemon de synchronisation, ainsi elle n'est plus téléchargée à chaque fois ; comme la solution 1 sauf que ne fonctionne que sur les ordinateurs qui ont installé le daemon de synchronisation.
1.
Mais tout ceci vise surtout à résoudre le problème d'un attaquant qui diffuserait du code à notre place en piratant le serveur.
Se protéger de l'éditeur du logiciel est bien plus complexe… Mais ce type de problématique m'intéresse beaucoup. J'aimerais pousser loin la transparence (technique ici) pour arriver à réduire un maximum ce que j'appelle la "nécessité de confiance à un inconnu" : le fait d'avoir besoin de faire confiance à un inconnu ou groupe d'inconnus (l'éditeur) avant de pouvoir faire quelque chose (ici, accéder au service).
J'ai déjà pas mal réfléchi à tout cela mais votre message a indirectement attiré mon attention sur la confiance en un logiciel libre mais fréquemment mise à jour : s'il faut relire le code tous les jours pour savoir si on peut faire confiance au code ça n'est pas gérable.
[^] # Re: Hmm
Posté par gnumdk (site web personnel) . Évalué à 2.
A mon avis la solution de l'extension devrait être obligatoire pour ton projet, genre, tu veux envoyer des fichiers via l'interface web, tu installes l'extension, c'est pas la mort et c'est une très bonne garantie.
[^] # Re: Hmm
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 26 juin 2014 à 08:30.
A partir du moment où il n'y a pas de réflexion aboutie sur comment gérer la sécurité avec un serveur auquel on n'a pas confiance, j'avoue ne pas du tout voir l'interêt d'un n-ème projet de ce type. Autant prendre Seafile en libre, ou Dropbox en non libre.
La, perso, je vois juste un n-ième projet identique aux autres projets. Ca manque d'argument (de maturité) pour dire que ce sera mieux que les autres (sur quel point? pas sur la gestion de la confiance dans le serveur, on voit que la réflexion en est à "reste à valider")
Bon, certes, j'aime bien la licence MIT, mais de la à ce que ça fasse l'interêt d'un projet… Perso je ne suis pas assez anti-GPL pour ça, et pour les autres ça rique de limiter le nombre de personnes interessées.
[^] # Re: Hmm
Posté par SaintGermain . Évalué à 3.
Pour Seafile et Dropbox, il a déjà répondu plus haut : Lupo Libero est (sera ?) conçu pour être décentralisé.
Par contre je ne vois toujours pas très bien l'avantage par rapport à Tahoe-LAFS qui pour le coup est décentralisé et possède apparemment une très bonne approche d'un point de vue sécurité et confiance.
Certes, Tahoe-LAFS est GPL et après avoir testé; les performances ne sont pas extraordinaires (cela a peut-être changé depuis). Mais comme c'est grosso-modo un filesystem, on peut à peu près tout faire avec (mais les performances peuvent ne pas suivre, en particulier pour tout ce qui est DB).
Vu le nombre de personnes qui disent ne pas très bien comprendre l'avantage par rapport aux autres solutions, je suis surpris de voir que ma requête (qui date de la dernière dépêche) d'inclure un comparatif avec les autres solutions ne soit pas prise en compte (et même plutôt ignorée).
Je suppose qu'il est plus facile et moins chronophage de répondre au coup par coup à ce genre de question ? Euh…
[^] # Re: Hmm
Posté par lupolibero . Évalué à 4.
J'ai tenu compte de votre premier message, en ajoutant à la FAQ du précédente texte de campagne le détail des différences entre Lupo Libero et ce qui existe déjà. Voici la version actuelle (qui est dans le nouveau texte de la campagne de financement, bien plus en évidence) :
Visiblement ça n'est pas assez parlant.
Voici quelques logiciels concurrents et le numéro des items qui font la différence.
Dropbox : 1, 2, 3, 4, 5
SeaFile : 2 (pour le cloud hébergé par eux), 3 (il faut choisir de chiffrer une bibliothèque), 4 (il faut un mot de passe supplémentaire pour chaque bibliothèque chiffrée), 5 (on ne peut pas partager un seul fichier d'une bibliothèque chiffrée)
Owncloud : 2, 3, 4, 5 (pas de chiffrement)
Owncloud + encFS (ou autre solution de chiffrement côté client) : 4 (mot de passe pour déverrouiller encFS), 5 (on ne peut pas partager un seul fichier)
Tahoe-LAFS est vraiment un système différent : c'est un système de fichiers et non pas un "cloud" (stockage en ligne orienté partage). Ses performances - qui ne sont pas forcément gênantes pour une entreprise qui cherche un système de stockage pour son archivage - ne sont pas acceptables pour un produit grand public. Malgré toutes les différences affichés avec Dropbox et autres, avoir des performances similaires n'est pas optionnel. Et Tahoe-LAFS a clairement été construit avec d'autres priorités.
Personnellement j'aurais bien aimé travaillé sur ce logiciel car j'aime beaucoup le python, mais ses concepteurs en ont fait quelque chose d'extrêmement complexe (pour qu'il puisse s'adapter à toutes les situations, ce qui impacte probablement les performances) et donc de difficile à modifier. Avec Lupo nous partons sur des bases plus simples, plus claires et aussi plus orienté : nous ne souhaitons pas faire quelque chose d'aussi généraliste qu'un système de fichiers.
A noter que Tahoe-LAFS est depuis environ un an assez faiblement maintenu (https://github.com/tahoe-lafs/tahoe-lafs/graphs/contributors).
[^] # Re: Hmm
Posté par SaintGermain . Évalué à 4.
Merci d'avoir répondu et fait un effort pour la comparaison avec les autres solutions.
On y voit déjà un peu plus clair, même si ce n'est pas encore tout à faite exhaustif et plutôt partial :
Si je puis me permettre, les principaux points d'achoppement techniques du partage de fichiers en ligne sont :
Jusqu'ici je ne connais aucun logiciel (libre ou pas) qui possède toutes ces propriétés.
C'est amusant car si on lit la première phrase de leur site web :
Il y a donc un de vous deux qui se trompe sur ce que veut vraiment dire « cloud ».
[^] # Re: Hmm
Posté par lupolibero . Évalué à 1.
Le précédent texte de la campagne était très orienté moyen/long terme. De par les retours que j'ai eu, j'ai compris qu'il fallait surtout parler de ce que sera Lupo à court terme.
Je n'ai pas l'impression de cacher quoi que ce soit. J'ai précisé (dans le texte de campagne et dans le billet ci-dessus) ce que serait ce service et (dans le texte de campagne, dans le billet et dans les commentaires) ce qu'il apporte par rapport à ce qui existe. De mon point de vue les fonctionnalités qui "manqueront" dans la première version sont à la fois nombreuses et bien moins importantes que le chiffrement de bout en bout, le fait que le logiciel soit libre, etc. Exemple : il n'y aura peut-être pas de streaming pour les vidéos dans la première version.
Clairement cette dernière s'adresse à des personnes qui comprennent les enjeux du respect de la vie privée. Et les versions suivantes apporteront ces fonctionnalités qui rendent l'outil plus agréable à utiliser.
Euh, ça n'est pas évident ?
C'est pareil, sauf que Dropbox n'est pas libre.
Intéressant. Le Wuala d'il y a un peu moins de 10 ans correspondait assez bien à tout ça (pour la déduplication, je ne suis pas certain ; et en non libre), avant d'être racheté.
Et ce Wuala d'il y a un peu moins de 10 ans, c'est précisément notre objectif à moyen terme.
Est-ce que vous parlez de déduplication globale ou pour l'utilisateur seulement ?
Cela ne me surprends pas, même en français on a du mal à s'entendre sur ce terme : voir la définition dans Wikipédia qui renvoie au Cloud computing ce qui ne correspond pas du tout au sens que j'y mettais dans ma phrase (qui est plutôt le sens commun du mot : Dropbox & co).
[^] # Re: Hmm
Posté par SaintGermain . Évalué à 2.
Bonjour,
Bon je n'arrive pas à faire passer mon message sur votre manière d'expliquer votre solution.
Si après mûre réflexion, vous pensez que l'état actuel est bien clair et suffisant, peut-être tout simplement que je ne suis pas la cible.
Après un rapide coup d'oeil, Wuala est sorti en 2008 donc qu'il faisait tout ce que j'ai annoncé il y a 10 ans je doute un peu :
Très intéressant ce Wuala, je ne connaissais pas. Si effectivement vous arrivez à faire la même chose mais en libre, ce serait vraiment pas mal.
[^] # Re: Hmm
Posté par lupolibero . Évalué à 1.
Bonjour,
Oula effectivement, ma mémoire a quelque peu exagérer sur les dates… :)
Effectivement 2008 pour la version stable et septembre 2011 pour l'abandon du troc d'espace disque (et donc de la décentralisation). (petit historique sur Wikipedia-EN
A défaut de pouvoir tester, si vous voulez des informations sur le fonctionnement et la conception de l'ex-partie P2P de Wuala, j'ai trouvé ce document : http://www.slideshare.net/adunne/wuala-p2p-online-storage.
Wuala avait un potentiel énorme pour faire évoluer le web vers une large décentralisation. D'autres qu'eux auraient pu le faire si les sources avaient été disponibles…
La déduplication est effectivement un point critique. Celle des données de l'utilisateur peut être facilement implémentée et sans risque. Par contre la déduplication globale comporte les risques que cite l'article de Wikipédia : on peut déterminer qu'un fichier est déjà sur le réseau (et connaître son identifiant et donc potentiellement savoir qui l'a dans ses fichiers) et cela fragilise beaucoup le chiffrement d'un fichier dont le contenu serait connu sauf une partie.
Nous travaillons sur une solution qui résoudrait ces problèmes et permettrait la déduplication globale.
[^] # Re: Hmm
Posté par SaintGermain . Évalué à 1.
Je ne m'y connais pas trop mais cela semble contradictoire sur le principe : avoir un chiffrement sûr et pouvoir dédupliquer entre différents utilisateurs.
Après si on peut dédupliquer entre ses propres données ou entre utilisateurs ayant accepté un chiffrement commun (voir l'approche de Obnam sur le sujet qui repose en partie là-dessus) ce serait déjà très très bien !
J'ai un doute sur l'intérêt de la décentralisation pour le stockage/partage de fichiers. Quand je vois l'effort qu'a fourni Tahoe-LAFS et que c'est relativement inconnu, je ne sais pas s'il y a grand monde d'intéressé (c'est peut-être pas utilisable au quotidien pour l'utilisateur de base)
D'un autre côté BitTorrent Sync a l'air d'avoir bien perçé (pour le coup il semble que ce soit bien utilisable par l'utilisateur de base).
Je vous souhaite de réussir, bon courage !
[^] # Re: Hmm
Posté par lupolibero . Évalué à 0.
"pas de réflexion aboutie"
"Ca manque (…) (de maturité)"
"la réflexion en est à "reste à valider""
Ca m'apprendra à vouloir partager mes réflexions en toute transparence…
Pour votre information, Lupo Libero n'est pas encore développé et oui, il reste des choix à faire dans se conception.
"Ca manque d'argument (de maturité) pour dire que ce sera mieux que les autres"
"Autant prendre […] Dropbox"
J'en reste sans voix… Vous avez lu le texte de la campagne (les autres liens) ?
Il vaudrait mieux choisir Dropbox (non libre et sans chiffrement) plutôt qu'une solution libre chiffrant de bout en bout seulement parce que notre prototype n'a pas de mécanisme d'authentification du code ?
[^] # Re: Hmm
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 26 juin 2014 à 11:16.
Euh… Attendez, vous cherchez du fric non?
Avez-vous lu les commentaires?
Y en aura-t-il à la fin?
Dropbox est avec chiffrement (entre moi et eux en HTTPS, puis chez Amazon aussi en AES256), le savez vous? soritr que c'est sans chiffrement fait juste rigoler vôtre interlocuteur, car vous ne dites pas de quel chiffrement plus mieux bien vous imaginez. Désolé je n'ai pas compris comment vôtre solution est plus chiffrée que chez Dropbox : du moment où il y a une interface web et que je rentre mon pass dans du Javascript récupéré sur un serveur, j'ai autant de sécurité qu'avec Dropbox.
Pour le libre, il y a déjà plein de solutions (Seafiles…)
Et comme on vous l'a déjà fait remarquer, montrer vôtre incapacité à mettre vôtre démo en HTTPS (ça se fait en pas longtemps) pose des doutes (Dropbox est accessible en HTTPS, c'est sécurisé, vous votre GUI ne l'est pas alors que c'est simple à faire…)
Désolé, mais non, même en lisant, je ne comprend l'avantage réél (et non "on l'a écrit, donc ça le sera") de la solution proposée.
Et à la vue du "succès" (4% à 5 jours de la fin sur 1.5 mois) je crois ne pas être le suel à ne pas comprendre l'interêt…
Maintenant, à la vue des critiques vous pouvez jouer les Caliméros, ou comprendre qu'il y a d'abord une réflexion à faire avant de demander du fric.
La première chose dans un projet est : réfléchir. La deuxième est : faire passer le message.
Aucun des deux n'est présent pour le moment, et pas foule a l'air motivé pour payer pour une réflexion (ça, il y a des milliers de gens qui ont des projets en cours de réflexions… pourquoi vous et pas les autres?)
[^] # Re: Hmm
Posté par SaintGermain . Évalué à 4.
Note à Lupo Libero : Zenitram est un peu brut de fonderie, mais si on passe la forme, le fond de ses messages est souvent pertinent.
Il faut être indulgent avec les nouveaux, ils ne savent pas que tu te places souvent du point de vue utilisateur pragmatique (sensible ou pas aux logiciels libres).
Je crois que le problème de Lupo Libero c'est que la population visée n'est pas très claire et que le message a donc du mal à passer :
Encore une fois s'ils font cela pour se former, tester leurs idées ou pour s'amuser tout en laissant le tout sous une licence libre, c'est une démarche à encourager (au moins oralement). Par contre de là à donner des sous, il y a du chemin…
Mais bon on voit de tout dans le domaine du financement, on a pas fini d'être surpris :
1.2 millions de dollars pour l'appli qui fait Yo
$500k "Energy-Harvesting" Kickstarter Scam Unfolding Right Now
[^] # Re: Hmm
Posté par Sufflope (site web personnel) . Évalué à 6.
Je sais pas pourquoi d'un coup tu mets des accents circonflexes sur l'adjectif possessif « votre », mais il n'en prend pas, contrairement au pronom possessif (ou plutôt la locution pronominale possessive ? :-D) « le vôtre ». Du coup ça donne un air pédant (genre « je vais même lui mettre les accents comme ça il sera bien calmé »).
[^] # Re: Hmm
Posté par lupolibero . Évalué à 3.
Je vais essayer d'être plus clair.
Dropbox chiffre le transfert entre l'utilisateur et ses serveurs web (HTTPS) puis chiffre avant d'envoyer sur les serveurs de stockage (AES). Entre ces deux chiffrement Dropbox a accès à tous les fichiers de ses utilisateurs (et au mot de passe).
Personnellement cela me pose problème et donc je n'utilise pas Dropbox (ni ses concurrents qui procèdent de la même manière).
Ce que nous proposons c'est de chiffrer depuis l'ordinateur de l'utilisateur, et plus précisément, dans la version web, dans son navigateur. Donc oui, le chiffrement sera fait par du javascript qui viendra du serveur. Donc il y a un risque que le fichier javascript soit corrompu par un attaquant qui aurait réussi à accéder au serveur (qui n'est pas un moulin non plus) et à gagner des droits suffisants pour pouvoir modifier le bon fichier javascript. Comme je l'ai précisé dans un précédent message, il y a ce même risque avec les autres clients web (par ex, sauf erreur, SeaFile) et pour les clients lourds qui se mettent à jour automatiquement (rien empêche un attaquant de pousser une mise à jour qui lui permettrait de récupérer tous les identifiants et mot de passe.
Pour résumer nous avons une situation problématique (une entreprise à accès à toutes mes données) et une situation à risque (en cas d'attaque active contre le serveur, un attaquant peut accéder à mes données).
De notre côté, nous allons travailler à réduire un maximum ce risque. Mais même en attendant, personnellement, je préfère la 2e situation à la 1ère.
Pourquoi "incapacité" ?
Il me semble avoir expliqué dans un précédent commentaire que la chiffrement du HTTPS n'apporterait que bien peu de sécurité à des données qui sont déjà chiffrées en AES256.
Le HTTPS a un intérêt cette situation mais plutôt au niveau de l'authentification du serveur : pour éviter qu'un autre serveur se fasse passer pour le nôtre. Mais il s'agit d'un prototype, pas d'un service en production.
[^] # Re: Hmm
Posté par gnumdk (site web personnel) . Évalué à 2.
L'admin du serveur, il a juste besoin de son mot de passe root… Ou alors tu ne t'adresse qu'à de l'auto hébergement et du coup, dans ce cas là, seafile fait l'affaire. Donc oui je comprend de moins en moins l'intéret du projet…
[^] # Re: Hmm
Posté par Zenitram (site web personnel) . Évalué à 5.
A partir de la, c'est mort.
Sauf à avoir l'idée de génie, mais comme vous êtes en phase de réflexion… Vous voulez qu'on vous payer pour réfléchir, mais pourquoi vous et pas d'autres?
La, on est mort de rire. En fait, vous n'avez rien compris à la problématique de sécurité.
Le problème n'est pas de se protéger d'un attaquant qui aurait réussi à accéder au serveur.
Le probème est de e protéger de l'admin du serveur.
Oui, un peu de dorure "on est plus secure" qui dans les faits n'existe pas (vous dites vous-même que vous êtes à l'état de réflexion, ce qui veut dire : rien comme idée de faisabilité), c'est un marketing classique.
Désolé, sur LinuxFr il y a des gens qui s'interessent à la technique…
Vous êtes sérieux?
HTTPS permet aussi à ce qu'on ne voit pas l'URL.
HTTPS évite qu'on injecte un Javascript different (on parlait de sécurité du JS, non?)
HTTPS évite d'accéder à un serveur différent (ce n'est pas suffisament important pour vous, vraiment?)
Oui, mais vous voulez du fric pour un truc axé sécurité alors que vous ne prennez même pas la peine de mettre HTTPS sur le serveur qui est un des trucs les plus simples à faire.
Ca fait rigolo, du moins pour moi.
Désolé, je n'ai toujours pas compris ce qui vous différencie des concurrents en pratique.
Et il me semble ne pas être un utilisateur de base (je m'interesse à la sécurité de mes données), alors pour quelqu'un qui est un simple utilisateur…
Après, comme dit, le 4% (qui est un sacré échec) me fait dire que je ne suis pas le seul à voir aucun interêt particulier de ce projet. Soit l'interêt est inexistant, soit il est très mal expliqué (avec option que le créateur du projet ne sait pas de quoi il parle au niveua sécurité, plus on creuse plus on rigole sur les énormités)
[^] # Re: Hmm
Posté par lupolibero . Évalué à 2.
Tout d'abord une petite question sur quelque chose que je ne m'explique pas : pourquoi une telle agressivité ?
On se connait ? J'ai été agressif envers vous ?
Pour vous c'est réflexion ou action ? Il n'est pas envisageable de paralléliser ? De mon côté je ne fonctionne pas comme ça. Oui nous commençons la réalisation alors que tout n'est pas figé.
Petite parenthèse sur le récurrent "vous payer pour réfléchir" : tous les logiciels que vous utilisez ont eu une phase de conception, pendant cette phase des gens ont été payé à réfléchir. Et dans le cas d'un logiciel libre cela ne me choquerait pas que le financement couvre la phase de conception vu qu'il n'est pas vendu à la fin (ce qui permettrait de récupérer les fonds qui auront payé la conception). Dans notre cas, on peut dire qu'il reste entre 5 et 10% de conception à finaliser.
"LA problématique de sécurité" ? Je doute qu'il n'y en ait qu'une seule. Et je me suis attaché à les séparer clairement dans mes précédents messages là où vous les mélanger : il y a la situation de l'admin qui modifierait le code pour obtenir des mots de passe et il y a le hacker qui s'introduirait sur le serveur et ferait de même.
Si, au lieu d'être agressivement "mort de rire" vous vouliez bien répondre à mes arguments un par un, l'on pourrait avoir une discussion constructive. J'ai déjà apporté pas mal d'éléments de réponse sur ce sujet mais vous les avez totalement ignorés.
J'ai l'impression que votre lecture déforme complètement ce que j'ai écrit. Je n'ai pas dit "on est plus secure". J'ai dit : d'un côté il y a un problème, de l'autre il y a un risque de problème ; de mon côté je préfère le risque. Mais chacun est libre de faire son choix. Et si vous préférez Dropbox, cela ne me pose aucun problème. Par contre si vous dites qu'il vaut mieux utiliser Dropbox, là je ne suis pas d'accord.
Vous faites exprès de ne pas citer la phrase qui est juste après ? "Le HTTPS a un intérêt cette situation mais plutôt au niveau de l'authentification du serveur : pour éviter qu'un autre serveur se fasse passer pour le nôtre."
Si vous voulez nous condamner seulement sur ce point, libre à vous.
Pourquoi ne pas poser des questions précises sur les arguments que j'avance comme faisant la différence ?
Ce que je retiens de vos propos (en excluant toute l'agressivité), c'est que pour vous le chiffrement de bout en bout n'apporte rien parce qu'il est possible qu'un administrateur mal intentionné puisse modifier le code et récupérer les données des utilisateurs (en récupérant d'abord les identifiants). Je vous ai répondu :
1. les logiciels qui sont mis à jour automatiquement (donc même sans JS) ont le même problème
2. nous travaillons à améliorer ce point et nous sommes prêt à aller très loin pour arriver à une solution qui soit plus sécurisée que les clients lourds.
Et du coup vous sortez de vos gonds parce que l'on voudrait "être payer à réfléchir", ce qui, comme déjà dit plus haut, n'est pas vraiment le cas.
De nouveau de l'agressivité en appuyant sur ce "sacré échec" pour la deuxième fois (votre précédent message se terminait de la même manière). Ca vous apporte quelque chose d'essayer de nous rabaisser ?
Oui c'est un échec et il est (comme souvent) très instructif. Et je suis d'accord sur un point : il montre que nous n'avons pas réussi à trouver notre public.
[^] # Re: Hmm
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 27 juin 2014 à 12:36.
Il y a différentes façon d'être aggressif. L'une est de prendre les gens pour des idiots incapable de déchiffrer une annonce en leur demandant du fric au passage.
Et hop une nouvelle connerie énorme…
Désolé, quand j'ai travaillé sur ma phase de conception je n'étais pas payé (j'ai investi mon temps).
Pour les autres, il y a eu des gens qui ont cru dans la personne qu'ils payent, qui corient dans les compétances de la personne embauchée. mais la problème : cette personne manque…
Question : vous être salarié (donc oui vous êtes payés par l'initiateur du projet, qui vous a embauché car il croient en vos compétance) ou l'initiateur du projet (dans ce cas, ben en phase de conception vous payez de votre temps plutot que de demander du fric)?
Savez-vous ce qu'est un projet?
Moi je dirai 95%. Du moins 95% de la partie qui vous démarque du reste.
vous n'avez pas répondu à la question : pourquoi vous et pas mon voisin qui a l'air d'en savoir autant que vous? C'est à vous de montrer que vous êtes plus compétant que mon voisin pour avoir du fric.
Le problème est que je n'ai vu aucun argument sérieux. Ceux donnés laissent penser que vous ne connaissez pas le domaine. Comment alors être constructif? Si vous voulez du consulting, pas de problème, mais je facture (ça ne devrait pas vous déranger vu que vous estimez qu'on doit être payé à concevoir et ça fait partie de la conception)
Vous n'avez pas démontré en quoi il y a un problème de l'autre côté. C'est du mensonge que de dire que Dropbox est un problème et pvous juste un risque : dans les deux cas, l'admin du serveur peut lire, et dans les deux il le fait quand il a envie et ne le fait pas quand il n'a pas envie. Ou laors je n'ai pas compris et on revient dans la problèmatique de l'incapacité à expliquer le projet.
Oui, mai ensuite vous dites "rien à foutre de ça" ce qui me fait rire pour quelqu'un qui veut me convaincre que la sécurité lui importe. Comment convaincre d'une sécurité avancée si vous ne savez déjà pas mettre en place une sécurité de base? Je suis aggressif? Ben vous vous foutez de ma gueule quand même…
Quels arguments?
encore une fois, je crois ne pas être le suel à ne rien comprendre quel avantage a votre idée sur ce uqi existe déjà.
Mais de quel public parlez-vous?
Vous pouvez le prendre comme une aggression, mais demandez-vous aussi pourquoi c'est un échec. Cet échec est instructif? Ben votre réponse montre qu'il manque encore beacoup.
Mais je vous rassure : je vais en rester la, j'essaye de ne plus poluer les commentaires, je croi avoir tout dit.
Ah oui, je suis peut-être aggressif parce que vous insultez les concurrents en faisant croire que votre solution est meilleure, sans le démontrer, et vous continuez à le faire après que d'autrese (même pas moi) vous le disent plusieurs fois qu'ils ne voient pas en quoi vous êtes mieux. J'avoue : je n'aime pas qu'on rabaisse les absents sans démonstration, je préfère le faire en face en pointant les problèmes.
Encore une fois, je n'ai rien compris de ce qui vous démarque des autres qui existent déjà. Je suis sans doute stupide. Ou alors c'est que c'est mal expliqué ou que c'est du vent (on a déjà essayé de me vendre tellement de choses révolutionnaires sur le papier…).
Note: j'avais commencé à simplement moinser la dépèche devant l'ininteret de l'offre après avoir creusé un peu, j'ai réagi en commentaire seulement après avoir lu les trucs qui me paraissent énormes au niveau manque de sécurité. Le premier commentaire n'ai pas de moi est c'est : " je n'ai toujours pas très bien compris." N'est-ce pas grave?
Ce n'est pas à moi de poser les questions, c'est à vous de me convaincre que vous avez un projet interessant.
[^] # Re: Hmm
Posté par Kerro . Évalué à 1.
Agressif != factuel
J'ai lu en diagionale, mais les propos de Zenitram ne sont pas agressifs (ils le sont très rarement je crois).
Le n-ième mec qui sort le concept de la mort-qui-tue sans avoir pris le temps d'utiliser son cerveau, ça gave, et ça fait gignol.
Tu ne t'es pas fait jeter immédiatement parce que ton annonce est plutôt bien ficelée et on a l'impression au premier abord qu'enfin quelqu'un a pondu un truc correct. En fait le projet n'est pas encore à l'étape d'avoir défini comment ça tient la route. En gros vous en êtes toujours au crayonnage sur la nappe du restaurant. Alors vraiment pas la peine de venir faire de la retape.
# différences avec mega ?
Posté par swap38 (site web personnel) . Évalué à 2.
Pour l'instant le proto ressemble un peu a mega.co.nz (ce qui est déjà pas mal !).
J'ai déjà bien compris que lupo est libre et prévu pour être décentralisé mais y a-t-il d'autres différences (techniques ou autre) avec la future première version ?
[^] # Re: différences avec mega ?
Posté par lupolibero . Évalué à 3.
Je ne pense pas. Il est même très probable que Mega ait plus de fonctionnalités que n'en comptera Lupo dans sa première version :)
Par contre dans les versions suivantes, cela devrait changer. Deux exemples : ajout de fonctionnalités de réseaux sociaux (profils, messagerie, messagerie instantanée, etc.) et de travail collaboratif.
Et bien sûr il y a les deux différences majeures que vous citez :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.