CaliOpen est un projet libre (GPLv3) qui a pour but de créer un nouvel outil de communication sécurisé. Il ne cherche pas à créer un clone libre et sécurisé de Gmail mais un outil suffisamment original pour attirer les utilisateurs, et les inciter à mieux protéger leur vie privée.
Le projet en est à ses tout début, il n’y a donc pas encore de démonstration fonctionnelle, mais il y a déjà du code en cours d’écriture.
Aperçu
Un petite copie d'écran de l'interface utilisateur actuelle, pour donner une idée.
Les acteurs
Le projet est soutenu par Gandi et La Quadrature du Net. L'absence de mentions légales sur le site ne permet pas de connaitre les responsables du site, ni la possible nature entrepreneuriale du projet. Néanmoins, le nom de Laurent Chemla, co-fondateur de Gandi, apparait sur la page de présentation. Sur le compte github, Aymeric Barantal, également lié à Gandi, semble être le développeur le plus actif ces derniers temps.
Le constat
La création de CaliOpen est partie d'un simple constat : pour protéger la vie des utilisateurs, il faut de la décentralisation, or un serveur de courriel reste très difficile à installer et à configurer. De plus, il n'y a pas eu d'avancée sur le courriel depuis des dizaines d’années, c'est pourquoi il est de plus en plus délaissé pour d'autres modes de communication.
D'autre part, après les révélations de Snowden, et le constat de Quinn Norton, il est clair qu'il est indispensable aujourd'hui de penser d’abord à la sécurité.
Quels seront les atouts de CaliOpen?
CaliOpen place l'ergonomie au centre de son projet, considérant qu’elle est son principal atout par rapport aux autres solutions déjà existantes.
- Installation simple : installer un serveur de courriel est long et difficile, et nécessite un investissement important dans sa maintenance ; CaliOpen a pour but d'être aussi facile à installer qu’un CMS comme Wordpress ou Dotclear.
- Unification des outils de communication : aujourd’hui, on utilise de nombreux canaux de discussion différents ; l'interface utilisateur se veut simple et regroupe ces différents canaux (courriel, Jabber, Twitter, Facebook, SMS, etc).
- Vues personnalisées : elles vont permettre de reproduire les fonctionnalités spécifiques à certains moyens de communication (classement par sujet pour les courriel, dossiers, etc).
- Mise en exergue de la confidentialité des informations échangées : CaliOpen veut mettre en place un système qui encourage les utilisateurs à améliorer leur confidentialité (voir plus bas).
- Adaptation du niveau de confidentialité autorisé : en fonction du type de connexion réseau ou du logiciel client utilisé, consulter ses données chiffrées peut être une mauvaise idée. CaliOpen n’affichera que les données avec un certain niveau de confidentialité qu’on peut régler par terminal.
- Simplification de la gestion des messages : ils sont ordonnés principalement en fonction de leur niveau d'importance, allant d'important à indésirable.
CaliOpen n'a pas seulement pour objectif de développer un outil simple et utile, mais également de faire évoluer les mentalités !
Vers une culture du chiffrement
Si la question de la protection de la vie privée commence à peine à faire surface pour le grand public, il n’est pas encore commun de chiffrer ses données.
CaliOpen met en place une barre de confidentialité visible par tous ses contacts, qu’il faut tenter de maintenir au niveau le plus élevé. Le projet compte sur l'aspect ludique d’une compétition de confidentialité entre contacts pour inciter ses utilisateurs à chiffrer leurs données, leur faire prendre conscience de l'importance de cette confidentialité et ainsi améliorer la diffusion de cette confidentialité de pair à pair.
CaliOpen souhaite également introduire une dégradation du niveau de confidentialité si on force l’affichage de données sensibles sur un terminal non-sûr (par exemple, la lecture d’un courriel chiffré sur une connexion non sécurisée).
Futur
La structure est informelle pour le moment, mais l’outil sera (à terme) supporté par une association. Même si CaliOpen a vocation à permettre la création de services commerciaux (nombreux j'espère), ce ne sera pas fait sous le nom du projet lui-même.
Il est possible cependant qu'une structure commerciale transitoire doive être créée si une levée de fonds devenait nécessaire pour en assurer le développement initial.
Appel à contribution
L'équipe de CaliOpen recherche des développeurs Pyramid (framework de développement web côté serveur en Python) et Angular.js (framework de développement web côté client en JavaScript) pour accélérer le projet, car pour l’instant il n’y a qu’un seul développeur pour l’interface web.
Aller plus loin
- Site officiel de CaliOpen (1755 clics)
- Code source (GitHub) (257 clics)
# Un peu flou tout ça
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 05 juin 2014 à 13:14.
Salut,
est-ce qu'il y a des gens impliqués dans le projet dans les contributeurs de la dépêche (je dis ça à cause du « je » dans « nombreux j'espère ») ?
Bon c'est un projet dont j'avais déjà entendu parlé (j'ai loupé la conf à l'Ubuntu Party, mais je me rattraperai à Pas Sage en Seine), qui jusqu'ici me paraissait très très flou, c'est bien qu'il y ait une dépêche pour éclaircir :).
À première vu il y a beaucoup d'idées communes, d'ailleurs ça partage beaucoup de points avec des projets actuels comme Movim, Friendica, ou Salut à Toi (installation simple je pense qu'on le souhaite tous, unification des outils de communication c'est très à la mode, vues personnalisées ça en découle logiquement, confidentialité ça tout le monde y pense clairement).
Je ne suis pas fan du tout de jouer sur le côté « ludique » et la compétition, pour différentes raisons:
je n'aime pas ce tout divertissement permanent ni l'infantilisation qui l'accompagne
j'aime encore moins (pour ne pas dire déteste) la mise en compétition qui devient de plus en plus courante aussi (et qui s'ancre dans les esprits comme la meilleure façon d'avancer, y compris chez les libristes, pfffff)
je pense que les gens sont capables de comprendre les choses quand elles sont présentées correctement. On leur demande pas de comprendre les algos ou l'implémentation, mais ce qu'est le chiffrement et pourquoi c'est important tout le monde est capable de le comprendre.
Ceci dit, je trouve les idées d'afficher une « barre de confidentialité » et une dégradation en fonction de l'environnement très bonnes.
Maintenant question technique: y'a quoi en dessous ? C'est une sur-couche à SMTP et consort ? Ça utilise un protocole maison ? Un protocole connu (XMPP ?) ? C'est un outil de centralisation des communication un peu comme un super Pidgin, ou un truc décentralisé capable de communiquer avec d'autre Caliopen ?
Bon bref, c'est encore flou pour moi, et pour le moment je suis un peu mi figue mi raisin sur ce projet.
edit: j'ai oublié de dire un autre bon point: l'interface a l'air claire et accessible sur la capture
[^] # Re: Un peu flou tout ça
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
Pour avoir suivi les discussions sur la ML Caliop depuis le lancement j'ai vu beaucoup de projets sur la comète (genre nouveau protocole chiffré, décentralisé, aussi simple et universel que l'email, mais pas l'email), mais rien de très concret techniquement. Puis un silence radio pendant des mois. Et maintenant CaliOpen débarque, alors que les derniers mots de Laurent Chemla en janvier étaient
Quel prototype ? En tout cas pas quelque chose de public, car le précédent message de Laurent Chemla sur la liste de Caliop (en novembre 2013) était un appel à recruter des développeurs, rempli de buzz-words 2.0 (pour spoiler : plein de frameworks javascript à la mode et qui pourrissent notre expérience web, un service centralisé de VCS très populaire et pas libre que je ne nommerais pas, etc.).
Niveau technique : oui c'est une surcouche à SMTP, rien de bien passionnant, malgré que Laurent Chemla disait ne pas vouloir faire simplement un nouveau webmail j'ai pas l'impression que ce soit autre chose.
Du coup je pense qu'il aurait été plus productif de mettre l'argent et l'énergie de Caliop dans un projet un peu plus intéressant et avancé comme Movim ou autre. Là j'ai un peu l'impression d'un effet d'annonce façon pétard mouillé.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# BitMessage
Posté par Ely . Évalué à 6.
Qu'apporterait Caliopen par rapport à une solution déjà existante, BitMessage ?
[^] # Re: BitMessage
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
BitMessage est un protocole spécifique. On ne peut parler qu'aux utilisateurs de BitMessage. CaliOpen utilise les normes de l'Internet (IMF, SMTP, etc) et on peut donc parler aux gens qui n'utilisent pas CaliOpen.
[^] # Re: BitMessage
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai testé il y a quelques temps BitMessage même si je ne communiquais avec personne. C'était plus pour mettre un noeud sur le réseau et voir un peu l'engin. Au final, j'ai trouvé que cela prenait pas mal de ressource CPU et disque. Bref, le concept est intéressant mais il ne faudrait pas que la sécurité se fasse au détriment de l'écologie.
Malgré l'abondance relative dans nos sociétés occidentales, le défi écologique est capital et l'informatique ne doit pas passer à coté.
# Et caliop, ça continue ?
Posté par Wawet76 (site web personnel) . Évalué à 3.
Il y a quelques mois, il y avait eu un gros effet d'annonce sur un projet "Caliop" : http://www.caliop.net/
Le projet était encore très flou, et il n'y avait qu'une ML où Laurent Chemla invitait ceux qui voulait à décrire leurs attentes. Très rapidement il est apparu que Laurent ne voulait pas faire table rase de l'existant (SMTP) et ça m'a un peu déçu car je m'attendais plutôt a un nouveau système de messagerie pensé par défaut avec du chiffrement, des signatures crypto et de quoi lutter efficacement contre le spam.
Vu le nom de Caliopen, ça semble être la suite de ce projet…
[^] # Re: Et caliop, ça continue ?
Posté par ack . Évalué à 2.
Du coup supprimer le SMTP serait une véritable rupture, et il serait par conséquent difficile de faire évoluer les mentalités si les utilisateurs non avertis ne peuvent plus communiquer avec les utilisateurs avertis.
[^] # Re: Et caliop, ça continue ?
Posté par Adrien . Évalué à 2.
… ou alors on s'arrange pour qu'il y ait une passerelle entre les deux systèmes… il me semble que des passerelles SMTP/XMPP existent déjà non ?
[^] # Re: Et caliop, ça continue ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
Oui, avec SàT c'est ce que nous prévoyons, cf Recevez et envoyez vos messages XMPP/Jabber avec votre lecteur de courriel grâce à Salut à Toi !.
Il y a encore du boulot pour remplacer SMTP, mais c'est envisageable à pas si long terme.
[^] # Re: Et caliop, ça continue ?
Posté par barmic . Évalué à 5.
Par essence, le chiffrement est une cassure. Que tu utilise SMTP ou autre chose si tu te met à chiffre tes messages ça ne sera pas transparents pour tes contacts.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et caliop, ça continue ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
pas nécessairement: si tu mets de côté les problème d'autorité de vérification, SSL est relativement facile. OTR V3+ est capable de vérifier l'identité du contact sans intervention manuelle. Après oui ça nécessite un changement d'outil, c'est peut-être ça que tu entendais, mais ça n'est pas forcément beaucoup complexe…
[^] # Re: Et caliop, ça continue ?
Posté par barmic . Évalué à 3.
Alors il y a différentes choses :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et caliop, ça continue ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
je ne vois pas la relation de cause à effet, ou alors on ne parle pas du même transparent. Est-ce que tu entends transparent = sans que ça se voit avec les outils actuels, ou sans que ça se voit tout court (c.-à-d. même une fois l'outil changé). Si c'est dans le deuxième cas, j'ai donné l'exemple d'OTR v3+ qui ne demande plus de vérification manuelle.
Oui bien sûr que c'est un plus. Même si mon serveur et celui de mon correspondant (qu'on peut tout à fait administrer nous même) voient le message en clair, c'est déjà bien de le protéger des autres yeux indiscrets.
[^] # Re: Et caliop, ça continue ?
Posté par barmic . Évalué à 3.
Qu'est ce que doivent faire mes contacts pour pouvoir lire mes messages ? S'ils doivent changer leurs habitudes, paramétrer quelque chose en plus, changer ou ajouter des logiciels c'est qu'il y a une cassure. Pas grande peut être mais elle existe et il y a plus de différence entre pas de cassure et une cassure légère qu'entre une cassure légère et un changement complet.
Ça veut dire qu'ils doivent se mettre à quelque chose de nouveau (est-ce que ça existe sur tous les terminaux qu'ils utilisent ? est-ce que c'est aussi pratique ?), ça veut dire que toi tu dois gérer 2 listes de contacts ceux avec qui tu chiffre et ceux avec qui tu ne chiffre pas, etc
D'expérience il ne faut pas vendre la sécurité comme quelque chose de transparent alors que ça ne l'est pas. Ce qui peut nous paraître trivial peut être déroutant pour d'autres.
Tu as parlé d'OTR pour faire de l'authentification ce qui n'a pas grand chose à voir. Je ne connais pas OTR.
Imaginons que je veuille aujourd'hui utiliser OTR et que mes contacts ont des logiciels qui gèrent OTR. Si je me mets à l'utiliser, je présume que je dois créer une paire de clefs ou un mot de passe ou quelque chose comme ça. Qu'est ce que doivent faire mes contacts pour pouvoir lire mes messages ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et caliop, ça continue ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
oui donc on ne parle pas de la même chose, moi j'entendais avec des outils nouveaux, et dans le meilleur des mondes avec tout le monde qui les utilise. Avec les outils d'aujourd'hui ça ne peut pas se passer simplement ça on est d'accord.
la création de clef peut être automatisée, la négociation est faite par les logiciels (en gros ça chiffre tout seul, mais si tu veux t'assurer de l'identité de ton contact, avec la V2 il y a une clef à vérifier par un canal séparé, ou une question secrète à répondre, en V3 tu n'as rien à faire). Bon OTR n'est pas adapté, c'est pour de la messagerie instantanée en texte uniquement, c'était juste un exemple pour montrer que ça peut être simple.
[^] # Re: Et caliop, ça continue ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Bien sûr que si, qu'OTR v3 demande toujours une authentification. Autrement, on serait trivialement vulnérable aux attaques de l'homme du milieu. La nouveauté d'OTR v3 est simplement d'ajouter une nouvelle possibilité d'authentification, fondée sur un secret partagé (les deux premières étant question/réponse et vérification du condensat de la clé publique). Il faut donc se mettre d'accord sur un secret commun (en utilisant un canal de communication sûr !), ne pas le perdre, etc. Pas vraiment Michu-compliant. https://securityinabox.org/en/pidgin_securechat#3.3
[^] # Re: Et caliop, ça continue ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui j'ai effectivement dit une connerie sur OTR v3, j'avais mal compris ce qu'il apportait.
[^] # Re: Et caliop, ça continue ?
Posté par ack . Évalué à 1.
Il est vrais que le chiffrement est une cassure, mais le projet ne semble pas uniquement axé sur le chiffrement, mais également sur la décentralisation du service ( dans un premier temps j'imagine, éventuellement suivit par le chiffrement ).
# Fausse facilité
Posté par deasy . Évalué à 2.
Un script wordpress ou dotclear installé correctement ce n'est pas si simple que ça, surtout pour le commun des mortels. Il y a toutes la configuration des logiciels autour(sgbd,serveur web…)
[^] # Re: Fausse facilité
Posté par Adrien . Évalué à 1.
C'est le boulot des distributions de faire en sorte que tout se passe bien :
« apt-get install wordpress » devrait poser les bonnes questions pour que ça marche directement.
[^] # Re: Fausse facilité
Posté par T3hty . Évalué à 5.
Pour faire l'avocat du diable, le commun des mortels utilise windows, avec de jolie installeurs qui ne se manipule qu'à la souris.
[^] # Re: Fausse facilité
Posté par Adrien . Évalué à 4.
Le commentaire parlait d'installer un SGBD et serveur web. Je ne suis pas sûr que le commun des mortels ait les compétences pour gérer un serveur, que ce soit sous Windows ou Linux. On s'adresse donc à un public un minimum averti, au moins à l'aise avec l'administration de son poste.
Perso j'utilise et contribue à Debian. Mais d'autres personnes peuvent tout à fait faire des installeurs simple pour windows. Quelque soit le système, il me semble que le rôle du « packageur » est important dans ce cadre, c'est un peu l'huile entre le développeur et les utilisateurs. Pour les utilisateurs novices, c'est très important.
[^] # Re: Fausse facilité
Posté par T3hty . Évalué à 0.
Un installeur simple pour Windows. La majeure partie du code est en python. Si c'est bien pour la majorité des distributions linux qui incorpore directement l'interpréteur, ça n'est pas le cas pour Windows, donc rien que ça sera plus complexe qu'un simple copy.
Et je ne parles que de la techno principale, il y a tout les COTS derrières.
[^] # Re: Fausse facilité
Posté par ariasuni . Évalué à 3.
Qu’est-ce que c’est? Bon j’ai trouvé ça, mais j’ai toujours pas compris ce que ça venait faire là-dedans.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Fausse facilité
Posté par deasy . Évalué à 1.
Dont ils ne lisent pas les instructions et installent 36 malwares par la même occasion.
NEXT NEXT NEXT
[^] # Re: Fausse facilité
Posté par ariasuni . Évalué à 5.
En même temps les installateurs sont spécialement prévu pour ça. Trucs pas clairs + coché par défaut + processus chiant et monotone = suivant suivant suivant + plein de merdes. Et encore, des fois c’est encore plus fourbe que ça (genre le truc qu’il faut décocher avant de télécharger l’exécutable comme Flash alors que la case à cocher est clairement dans une colonne différente du bouton télécharger).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Fausse facilité
Posté par nerbrume . Évalué à 1.
Je suis assez d'accord, a partir du moment ou il faut configurer une distrib', c'est trop compliqué pour le commun des mortels. Au delà de ca, je ne vois pas de différences entre apt-get install wordpress et apt-get install caliopen.
En revanche, je pense que l’intérêt de partir sur du python + server Apache/SQL "standard", c'est effectivement de proposer un package windows facilement. Il existe sans doute deja des installeur WAMP, et les problématiques associées (ouvertures de port, etc…) ont probablement été résolues par d'autres.
[^] # Re: Fausse facilité
Posté par Christophe Morvan (site web personnel) . Évalué à 4.
C'est simple par rapport à un serveur de mail. :)
# retroshare le fait déjà ou j'ai loupé quelque chose ?
Posté par bobo38 . Évalué à 3.
Il me semble que Retroshare fait déjà tout ça, avec un client multiplateforme. Après j'ai peut-être mal compris, quels seraient les plus de Caliopen par rapport à Retroshare ?
[^] # Re: retroshare le fait déjà ou j'ai loupé quelque chose ?
Posté par Egide Dey . Évalué à 4.
Fan de RS depuis… 6 ans.
Le problème de RS, c'est que tu ne peux échanger qu'avec des personnes avec qui tu as déjà échangé ta clé… Cela va bien pour une bande de copains, ce n'est par contre pas top pour des relations commerciales, académiques ou autres que de familles / copinages.
RS est vraiment sympa… mais :
- il est encore bourré de bogues…
- il est totalement illusoire de faire passer un message entre deux machines qui ne sont pas connectées au net en même temps;
- RS a besoin d'une grosse configuration pour tourner (ça marche sur RPi… si tu as moins de 15 contacts et que rien d'autre ne tourne dessus)
- la partie messagerie de RS est tellement minimaliste, qu'elle ressemble plus à un "proof of concep" qu'a quelque chose de réellement utilisable…
- RS fait du très mauvais café
- et le pire, RS est à peine utilisable en ligne de commande…
En fait, RS veut connecter quelques amis enssemble, ce qui est une bonne chose. Ici on parle de relier le monde…
Cela dit, je suis vraiment un fan de RS…
[^] # Re: retroshare le fait déjà ou j'ai loupé quelque chose ?
Posté par bobo38 . Évalué à 1.
Merci pour le comparatif ;)
Je retiens pour Retroshare l'aspect synchro de la connection à Internet, et aussi un peu le côté monolithique.
[^] # Re: retroshare le fait déjà ou j'ai loupé quelque chose ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Ce genre de témoignage serait super intéressant pour la série « se passer de… », la partie idoine n'est pas pour tout de suite (plusieurs semaines voire mois), mais ça serait intéressant de commencer à mettre ce genre de choses: https://linuxfr.org/redaction/news/se-passer-de-google-facebook-et-autres-big-brothers-2-0
# Terminologie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ce terme de supporter est ambigu, parce qu'il peut avoir plein de sens différents, certains étant d'ailleurs des abus de langage :
Vu le contexte, il s'agit probablement de cette dernière possibilité, mais tant qu'à faire, autant utiliser dès le départ un terme univoque : soutenir. Et éventuellement, passer la phrase à la voix active, aussi, qui est plus naturelle dans l'absolu mais pas forcément dans le contexte de ce paragraphe.
[^] # Re: Terminologie
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Vu que Laurent Chemla est l'auteur du projet, cofondateur de Gandi et qu'il est au comité stratégique de la quadrature du net, je penche carrément pour la dernière option (et de toute façon je ne vois aucune ambiguïté quand on dit « supporter », la contexte est souvent clair).
[^] # Re: Terminologie
Posté par chimrod (site web personnel) . Évalué à 4.
Il n'y a pas d'ambiguïté, c'est un anglicisme.
[^] # Re: Terminologie
Posté par ariasuni . Évalué à 2.
C’est de ma faute. Effectivement, j’aurais dû employer le terme «soutenir».
Écrit en Bépo selon l’orthographe de 1990
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.