URL: https://linuxfr.org/news/caliopen-une-messagerie-web-multi-protocole-securisante Title: Caliopen, une messagerie web multi-protocole sécurisante Authors: Nicolas Boulay Benoît Sibaud, BAud, Bruno Michel, M5oul, palm123, Julien.D et Nils Ratusznik Date: 2015年09月30日T14:15:10+02:00 License: CC By-SA Tags: caliopen, messagerie, sécurité, webmail, laurent_chemla et edward_snowden Score: 23 Caliopen est une solution logicielle en ligne, dédiée à la création d'une messagerie multi protocole avec une indication sur la sureté de chacun des systèmes utilisés. Le but est de proposer les messageries les plus sécurisées possible, selon le contact, et de faire abandonner progressivement les protocoles à problèmes. Cela permet de ne pas casser les habitudes des utilisateurs, en leur proposant l'accès à toutes leurs messageries. C'est l'inverse de la création d'un nouveau protocole qui n'est supporté par personne. Ce n'est pas l'auto-hébergement qui est visé, mais des structures plus grosses, qui pourraient gérer de quelques centaines à quelques dizaines de milliers d'utilisateurs. Cela permet de centraliser des fonctions comme la gestion du spam. ---- [Site de Caliopen](https://www.caliopen.org/) [Article de Laurent Chemla sur les principes de Caliopen](https://reflets.info/re-expliquer-caliopen-encore/) [Un autre article sur les difficultés de Laurent Chemla sur le développement ](https://reflets.info/trop-tard/) ["Sécurité, facilité d'usage, et les utilisateurs non-informaticiens"](http://www.bortzmeyer.org/securite-facilite.html) ["L'auto-hébergement à l'heure de la surveillance de masse", n'est pas une bonne solution](https://blog.jbfavre.org/2015/09/29/Auto-hebergement-surveillance-de-masse/) ["Caliopen, encourager le chiffrement" précédente dépêche](https://linuxfr.org/news/caliopen-encourager-le-chiffrement) ---- ![image de l'interface](https://caliopen.org/assets/images/features_carrousel_1.png) _« Les grandes aventures commencent toujours par un premier pas..._ _Un jour, Jérémie Zimmermann est passé chez moi, pendant ses vacances, en pleine affaire PRISM._ _Nous avons parlé, ce jour là, d'un ancien projet de service de courrier électronique, respectueux de la vie privée des utilisateurs, mais qui - face à l'ogre Google - n'a jamais vu le jour. Jérémie m'a alors poussé à relancer ce projet, expliquant que désormais, grâce à Edward Snowden, une partie du public était sans doute prête à quitter GMail et les autres pour quelque chose de moins centralisé, de moins propriétaire, et qui ne soit pas basé sur l'exploitation du contenu de nos échanges privés._ _Depuis ce jour, avec une équipe réunie grâce au soutien sans faille de Gandi et de la Quadrature du Net, nous avons travaillé dur._ » - Laurent Chemla _« L’idée de Caliopen, c’est donc de ne plus considérer le protocole sous-jacent comme discriminant de la fonction. Dans Caliopen, une conversation se fait avec des contacts, quel que soit le protocole utilisé. Dès qu’un contact peut être joint en privé, par n’importe lequel de ces moyens, Caliopen le permet. Il regroupe dans une unique conversation tout ce qui est échangé avec un contact, quel que soit le protocole »_ ![Une autre image de l'interface](https://caliopen.org/assets/images/features_carrousel_3.png) Quelques question à Laurent Chemla : Dans quel état est le projet pour l'instant ? Est-il utilisable ? Est-ce qu'il est déjà déployé ? _Houla non. Le prototype est encore loin d'une alpha. Si tout va bien et qu'on arrive à mettre en phase le front, le back et le module CQL pour Postfix (en cours de dev aussi), on devrait avoir, d'ici la fin de l'année, une alpha capable de recevoir des mails (SMTP), de les afficher, et *peut-être* d'y répondre._ Sinon quand est-ce que vous pensez sortir une première version utilisable ? _Une fois qu'on aura une alpha, et si celle-ci permet de lever des fonds pour payer une équipe, j'estime qu'il faudra encore 6 mois de travail intensif avant de pouvoir présenter un produit qui commencera à être assez utilisable pour qu'on puisse mettre en place une infrastructure de test à même de nous permettre d'affiner les réglages (calcul du PI, évaluation de la charge, amélioration d' l'UI en fonction des retours, etc)._ _Je sais que ça semble lent, mais il faut comprendre qu'on part de rien, que le projet est très ambitieux, et qu'on est très peu à bosser dessus._ Qu'est-ce que le PI ? _"Privacy Index", c'est un indice associé à chaque élément de l'UI, ainsi que plus globalement au compte utilisateur, et qui affiche le niveau de confidentialité de chacun de ces éléments._ _C'est l'aspect central du projet._ Il y a combien de développeurs sur le sujet actuellement ? _Selon la disponibilité des uns et des autres: 2 devs front, 2 back, un designer, un graphiste, et moi qui ne sert à rien._ Avez vous des prestataires techniques prêt à vous suivre, pour le déployer ? A quel prix ? _Gandi nous soutient, et bien entendu pense à l'utiliser le jour où il le pourra. Je ne doute pas qu'on trouvera rapidement d'autres soutiens quand on commencera à montrer un début de commencement de produit._ Vous cherchez des développeurs de logiciels libres, mais avec quel genre de compétence ? _Python/Pyramid/Ember, surtout._ Comment faites vous pour gérer les clefs privées, pour les protocoles chiffrés dans votre système ? _Je donnerai une conférence sur ce sujet en décembre aux JRES à Montpellier. Selon le choix de l'utilisateur (qui influencera le PI de son compte, ce qui devrait selon nous le pousser à faire l'effort de choisir la sécurité plutôt que la facilité), les clés privées seront stockées clientside (sans doute via l'extension End-To-End de Chrome mais nous verrons quel sera l'état de l'art au moment où nous en aurons besoin), ou serverside dans le cas où l'utilisateur considère qu'il est trop compliqué pour lui de perdre les fonctionnalités de recherche serverside (entre autres), mais dans ce cas au détriment de son PI. Il pourra changer d'avis plus tard, dans tous les cas._ _Les clés publiques, au moins pour les clés PGP, seront diffusées via le DNS._

AltStyle によって変換されたページ (->オリジナル) /