Ré-expliquer Caliopen. Encore.

uiUn des principaux commentaires, suite à mon billet « Trop tard » sur Caliopen, a été, encore une fois, que son objectif n’était pas assez clair.

J’en assume la totale responsabilité, évidemment, puisque malgré l’aide et le soutien sans arrêt renouvelé de Gandi je suis seul à porter ce projet. Je suis un vieux développeur, pas un communicant, et il n’est pas toujours simple d’expliquer un projet complexe dans le peu d’espace alloué, de nos jours, par nos cerveaux sans cesse sollicités par une actualité débordante.

Je vous propose donc ici, encore, une explication: c’est le texte d’une mini-conférence que j’ai faite cet été, et qui sera sans doute la base des diverses rencontres autour du projet prévues cette fin d’année.

En espérant, cette fois-ci, être mieux compris et, qui sait, attirer quelques bonnes volontés sinon pour participer au développement, au moins peut-être pour dialoguer, améliorer le site-vitrine, m’aider à créer l’association qui dans le futur assurera le suivi du projet… Bref, pour m’accompagner dans cette aventure un peu trop solitaire.

Pourquoi Caliopen

Après les révélations de Snowden, prise de conscience du risque que la centralisation d’Internet fait peser sur la vie privée: le prix de la surveillance de masse est trop bon marché (il suffit d’avoir accès à une poignée de grandes entreprises, qu’elles soient ou non complices), il faut « degoogliser ». Caliopen est envisagé comme une alternative aux grands silos de gestion d’email (gmail, yahoo, hotmail…).

Pour être utile et efficace, cette alternative doit être adoptée par le plus grand nombre. Les solutions de type Lavabit (ou ProtonMail depuis) sont trop élitistes, ce qui pose un problème d’échelle: sans même parler de chiffrement, quand le nombre d’utilisateur du plus grand service alternatif se compte en centaines de milliers alors que le nombre de comptes actifs Gmail approche le milliard, la proportion est beaucoup trop faible pour parler de décentralisation. L’immense majorité des échanges se fait avec les silos centralisés, la modélisation des graphes sociaux de la population (qui parle avec qui) reste triviale, la surveillance généralisée ne coûte pas assez cher.

Notre conclusion est alors qu’il ne sert à rien de proposer « la même chose mais ». Une alternative Gmail-like, même libre, même décentralisée, même sécurisée, n’attirera jamais assez de public pour changer la donne. Le grand public n’a pas envie de changer ses usages pour « la même chose mais ». On ne change pas d’adresse email comme de chemise, c’est coûteux (et d’autant plus que le service ne pourra pas être basé sur le même modèle économique échangeant gratuité contre vie privée puisque l’objectif est la protection de la vie privée), il faut prévenir tous ses contacts, changer d’appli sur son téléphone, transférer des données… En dehors d’une portion très faible et très motivée de la population, personne ne fera un tel effort.

Notre choix fut donc d’inventer autre chose. Un service qui attirera le public non pas « contre » des pratiques existantes, mais « pour » de nouveaux usages, un outil attirant, plus moderne. Et tant qu’à faire de partir d’une page blanche, nous pouvions imaginer d’intégrer au delà du mail tout ce qui relève de la correspondance privée en ligne.

L’email est vieux. En dehors de FTP, c’est sans doute le plus vieux protocole utilisateur dont l’usage soit encore aussi large. Et il a peu évolué: depuis les premiers webmails, en dehors de l’UI, peu de choses ont changé. Pourtant les usages, eux, ont évolué: des échanges privés se font toujours via l’email, mais le plus souvent il s’agit d’échanges de travail, ou pour le commerce électronique. Notre correspondance privée est sortie de ce seul cadre. Nous dialoguons via jabber, irc, messages privés twitter ou facebook, Skype, textos… Tout ceci relève de la correspondance privée, et souvent avec les mêmes contacts. Même ceux qui utilisent le plus sécurisé des services de mail continuent à échanger par ces moyens là, et peuvent donc être surveillés, d’autant plus facilement que leurs contacts ne sont joignables que par ces outils.

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. On ne se pose plus la question de savoir si untel nous a envoyé une photo par mail, Twitter ou Facebook pour pouvoir la retrouver: elle sera dans la conversation que nous avons eue avec lui via l’interface de Caliopen.

Et il n’y a même pas forcément besoin de changer d’adresse pour permettre ça: Caliopen permet d’ajouter un compte existant, y compris un compte Gmail, pourquoi pas. Chaque protocole s’intègre sous forme de plugin, et tout nouveau bidule à la mode pourra y être ajouté sans difficulté insurmontable, dès lors qu’il permet des échanges privés.

Voilà, nous l’espérons, de quoi attirer le plus grand nombre.

Et ce n’est qu’une fois le produit adopté, pour cet usage, que Caliopen prend tout son sens: en assignant à chacun des éléments de son interface un « niveau de confidentialité », et en l’affichant de façon systématique, Caliopen va permettre à ses utilisateurs de prendre conscience du degré d’exposition de leur vie privée en ligne. Quand un message venant de Gmail arrive en ayant un niveau quasi nul de confidentialité, on y répondra pas forcément de façon aussi libérée que s’il existe un meilleur canal. Et Caliopen utilisera par défaut ce canal là pour y répondre, en fonction des données du contact. En affichant un niveau global de confidentialité du compte utilisateur, Caliopen va motiver celui-ci pour l’améliorer, en lui proposant des options pour ce faire. Et ainsi, petit à petit, chaque utilisateur de Caliopen sera poussé à se créer des clés de chiffrement, à utiliser les protocoles les plus sûrs, à demander à ses contact de faire de même (et pourquoi pas à se créer un compte Caliopen).

Quand nous en serons là, nous aurons créé un outil à même d’être non seulement une alternative aux grands silos, mais aussi une alternative à l’email: parce que tous les services basés sur Caliopen auront le choix de rejoindre un réseau privé sécurisé pour échanger entre eux les niveaux de confidentialités de leurs utilisateurs, ce réseau là pourra supporter un protocole plus sûr y compris pour les échanges entre utilisateurs, tout en étant largement décentralisé.

Pour aller plus loin

Si malgré tout vous n’avez toujours pas compris l’objectif de Caliopen, n’hésitez pas à poser des questions, à venir discuter, ou même encore mieux à contribuer à mieux expliquer: ceci n’est pas une startup: c’est un projet libre, qui ne vit que grâce à la bonne volonté des uns et des autres.

Je vous demanderai toutefois de faire l’effort de nous rejoindre sur le canal irc #caliopen (sur le réseau FreeNode), même si j’essaierai dans la mesure du possible de répondre à vos commentaires ici-même. Vous pouvez aussi m’écrire directement, ou poser des questions sur contact@caliopen.org.

 

Twitter Facebook Google Plus email

25 thoughts on “Ré-expliquer Caliopen. Encore.”

  1. Malgré le fait d’avoir lu les articles précédents, je n’avais toujours pas bien compris comment Caliopen allait pouvoir changer quelque chose.

    => « 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 » <=

    Cette phrase devrait être en gras et soulignée. ;-)
    Caliopen est donc une application pour communiquer capable d'utiliser différents protocoles et en utilisant le plus sécurisé. C'est juste énorme quand on comprend bien l'intérêt de la chose.

    1. Exactement. J’ai lu en entier parce que je voulais savoir ce que c’était, et ce simple paragraphe permet d’expliquer très simplement « le projet tellement complexe qu’il est difficile à expliquer ». Encore une fois, l’auteur nous montre sa proportion à prendre les gens pour des cons (si vous ne comprenez rien, c’est parce que vous êtes cons, pas parce que j’explique mal).

      Mais sinon, il est tout seul parce que la communauté libre, c’est de la merde…pas parce que c’est un con.

      C’est dommage, le projet est vraiment sympa (pas révolutionnaire pour un sous, mais bon). Je ne vous souhaite pas bon courage.

      1. Je ne sais pas à quoi tu fais références…

        Il dit : « Je suis un vieux développeur, pas un communicant (…) » donc il avoue lui-même que son métier n’est pas de communiquer efficacement mais de programmer.

        Qu’est-ce qui te donne l’impression qu’il te prend pour un con ? Je trouve que justement, il indique que c’est sa faute si le projet est mal compris…

      2. Malgré ses efforts, l’auteur n’aurait donc pas mis suffisamment de déférence dans son post pour que le fond soit recevable par le cerveau de certains.
        J’en retiens qu’on a visiblement tous une certaine propension à être le con de quelqu’un, mais, à l’évidence, pas dans la même proportion.

  2. Cette explication est très claire (sans comparer, pas lu avant ^^). C’est super intéressant & une judicieuse stratégie. Séduisant.
    Un tel outil, même façon basique, serait un apport significatif.

    C’est le genre de projets qu’on aimerait voir exister.
    Et ça existera quoi qu’il en soit, Caliopen ou pas.

    Ça soulève quand même des questions fondamentales même si on se doute tacitement des réponses :

    Caliopen centralisera grandement ces données privées (ou leur accès) → Peut-être est-t-il bon en amont de souligner (avec insistance) que Caliopen offrira une protection importante de ces données / cet accès. C’est certes pas l’argument principal pour ses utilisateurs, dans l’immédiat, ni le nœud de l’idée toutefois chacun songera bien au risque de cette centralisation.
    C’est aussi la principale objection qu’on peut avoir pour ce genre d’idée ^^

    À moins qu’il s’agisse d’un mode en “utilisation” (autrement dit que Caliopen se contente juste d’utiliser les services existants tels qu’ils sont conçus et configurés ? — vs duplication), ça implique également que toutes ces données soient stockées (concernant Caliopen) à distance (cloud).
    Et dans le cas d’un mode juste en utilisation sans duplication des données se pose la question de la pérennité d’accès en outre.

    L’autre gros souci c’est la couche technique, même si Caliopen fait son cas de ces contingences résiduelles, il n’en reste que l’interopérabilité n’est pas forcément jouable. Voire peu souvent. Certains protocoles ne seront pas gérés par Caliopen. Même en bricolant c’est pas viable sur le moyen-long terme.

    Pourtant c’est le cœur pour séduire puis orienter au fil du temps.

    Si d’aventure il y avait plus ou moins possibilité de s’en arranger c’est alors que chaque gros acteur serait en capacité de faire de même et proposer un service équivalent. Il le feront donc ! (On a vu passer des idées similaires de la part de gros acteurs). La question est :
    Le vrai plus de C. aux yeux du grand publique tjs) dans l’hypothèse où ce genre de services se généralise c’est quoi ?

    Par-ce que si la réponse est : L’intégration de services plus cool et plus clean (Tox…) en plus des merdes (Skype…) : On aura pas bougé d’un poil. Un très chouette jouet, beaucoup de travail mais fondamentalement retour case départ. C’est pas la (non)centralisation des services plus cool et plus clean qui pose souci, au même titre que ça ne dérange personne d’aller chat tantôt sur skype, FB, mail, sms… selon les appétits.

    La compatibilité, entre eux, des divers projets disons alternatifs, couplé au fait qu’aucune passerelle ne soit pensée avant la promotion de ces services est le fond du problème. C’est rien d’autre que ce que font les gros acteurs : chacun son truc et c’est à celui qui captera le plus d’utilisateurs pour imposer sa solution, fusse-t-elle d’exister avec un peu de ses concurrents. Chacun pensant sa solution plus valable que l’autre.

    À mon avis c’est là (là et encore là) que Caliopen, dans ses divers objectifs, peut parvenir à s’imposer et séduire autrement que comme un jouet éphémère à tester.
    L’idée est belle mais fondamentalement demande un effort considérable et je crois peu réaliste ne serait-ce qu’au regard des us et mœurs dans l’univers des LL… (Sauf par ex. certains projets de réseaux sociaux alternatifs qui font en sorte de s’accorder et rester compatibles)

    :)

    1. Bon: là on voit clairement que, pour répondre, il faudrait plus qu’un commentaire, plus qu’un article mais carrément une table ronde :)

      L’IRC est pratique pour ça, ou les rencontres AFK, mais sans rentrer dans les détails je peux au moins dire que tous ces aspects ont été, sinon résolus, au moins abordés et réfléchis depuis un bon moment déjà. On a sans doute pas toutes les réponses, mais on en a pas mal.

  3. wesh et Thera, pas vraiment non, en revanche si c’est ce que vous ressentez, c’est pas par hasard visiblement.
    C’est que vous l’etes. (complètement con, oui)

    Bisous, de rien.

    Mourrez.

    En attendant, fermez donc un peu votre gueule, ca ira bien aussi.

    1. La même question, plus ou moins, vient d’être posée sur IRC et la réponse qui a été donnée est: Jitsi est un client, et non web, Caliopen est un ensemble (serveurs y compris au moins pour leurs configurations mais pas seulement), et web.

      Ce sont deux philosophies résolument différentes, et la raison principale pour ça est que, pour calculer et afficher les différents niveaux de confidentialité, aspect primordial de Caliopen, le frontend doit disposer de données qui, dans la grande majorité des cas, ne sont pas disponibles pour un simple client (le cas typique étant le type de sécurisation utilisée par un transport SMTP, le type de certificat utilisé, de quel CA, avec quel chiffrement…).

      1. Bonjour, et merci pour ton article,

        Pour l’orientation web, tu nous dis que la raison principale de ce choix est le calcul du niveau de confidentialité.

        Mais comment justement Caliopen, au bout du compte, va-t-il pouvoir se faire un avis sur tel ou tel protocole ?

        S’agit-il de lancer régulièrement des sondes afin de tenter de récupérer des informations sur le niveau de chiffrement, la chaîne de certification, etc., de chaque fournisseur et/ou de chaque protocole ?
        Si c’est le cas, effectivement, il n’y aura pas trop d’un serveur qui y passe ses journées, avec un frontend web derrière, je suis d’accord.

        Mais vu d’une part le nombre de possibilités à évaluer (tous les protocoles chez tous les fournisseurs…), et d’autre part les difficultés techniques que cela pourrait poser (blacklisting, falsification et/ou risque de résultats différents sur deux serveurs différents), je ne suis pas sûr qu’il s’agisse de votre choix technique.

        L’autre possibilité, c’est la base de données alimentée par la communauté. Et dans ce cas, pour peu qu’elle soit d’une taille raisonnable, j’ai du mal à saisir la nécessité du choix du web, qui représente d’une certaine façon l’externalisation des données personnelles, et pour rappel c’est bien ce que l’on reproche à Google et ses petits copains.

        Je serais ravi d’un éclaircissement à ce sujet !

        1. Non, il n’y a pas forcément besoin de sondages ou autres pour évaluer, par exemple le PI (Privacy index) d’un email.

          Le serveur de réception sait un certain nombre de choses: quel protocole a été utilisé (SMTP oui, mais TLS ou pas, avec quel type de chiffrement, quel certificat, issu par quelle autorité, s’il y a eu ou non un relai…). Certaines de ces informations restent dans le header, mais pas toutes.

          Si le serveur se « contente » de délivrer le message, ces informations là sont perdues, et le frontend ne peut pas calculer le PI. Et c’est pareil pour XMPP, et sans doute pour d’autres protocoles.

          C’est pour ça qu’on ne peut pas envisager de faire ce que fera Caliopen sans imaginer un ensemble complet qui va des serveurs au frontend, en passant par le stockage. Tout doit être lié (et de préférence sans possibilité de MITM) pour que l’utilisateur puisse avoir – sous une forme assez simple pour être comprise par tout le monde – une indication réaliste de la confidentialité de ses échanges.

          Pour une toute première approximation des métriques qu’on veut utiliser, voir le pad dédié: https://pad.caliopen.org/p/confidentialit%C3%A9

  4. J’avais effectivement mal compris la première fois.
    C’est sympa de savoir qu’on peut être seul à utiliser caliopen parmi nos contacts et que même comme ça c’est pratique…
    Je suis totalement convaincu du coup, mais je peux pas faire grand chose de plus :/

  5. Je suis allé voir les sources de Caliopen et je suis triste.

    J’ai bien suivi l’annonce post Snowden de ce projet, la mise à plat du problème et le chemin choisi pour y répondre, puis les annonces sur Reflets.

    Je suis triste.

    Je suis convaincu de l’importance de garder sa correspondance privée, de la puissance du chiffrage et de l’inétavibilité du code ouvert.

    Ca fait longtemps que j’ai lâché les techniques liées aux interfaces, faute de temps, mais je pense être légitime pour tout ce qui touche aux backends, aux buzzwords et aux workflows (du dev à la prod).

    J’ai donc regardé l’arrière-cuisine de Caliopen.

    Je suis triste.

    Le projet est récent, dans sa première itération, mais il ressemble déjà à une application Web de Mozilla (https://github.com/mozilla/?utf8=%E2%9C%93&query=marketplace). En une itération, c’est un exploit.

    Le projet est en python (yes!), mais ressemble à une application d’entreprise Java période Spring (ohhhh).

    Première déception, il faut un projet pour gérer le projet, et le workflow est bétonné. C’est un projet open source, avec la vocation d’accueillir des contributions, pas une application corparate avec un type à cravate qui fait marner des stagiaires.
    En dehors de l’entreprise, il existe ce que l’on appelle des normes, des bonnes pratiques. Des machins un peu reloud inventés pour contrer le NIH, la plaie de l’informatique depuis 40 ans.
    Pour gérer des sous projets dans git, il existe les submodules, le gros bash qui fait une ribambelle de git clone, c’est juste du bricolage. Et pour gérer les taches, il existe les tickets, la pull request préventive est, comment dire, comme jouer du tambour sur un piano.

    Le projet est surdécoupé en une ribambelle de sous projets. La seule raison est de limiter les dépendances entre les différentes couches. Paf, les lasagnes de Spring, avec sa couche contrôleur qui cause à sa couche service qui cause à sa couche persistance.
    Le couplage fort est un drame, mais le surdécoupage l’est tout autant.
    Du coup, pour bosser, il va falloir batailler avec le gros bash pour choisir son propre fork du repo concerné, puis proposer sa pull request, et vérifier que l’on a pas cassé le gros tas. Clairement, ce workflow est conçu pas des gens qui bossent directement sur le repo, avec des branches vraisemblablement, mais surtout pas avec des repos différents.
    De toute façon, j’ai de gros doutes sur l’autonomie de chacun des projets, sur la possibilité de bosser sur un seul projet à la fois. Genre, corriger ou arranger une feature, lancer des tests, puis regarder comment ça s’intègre. Des tests, unitaires ou fonctionnels, hum, je n’en ai pas vu beaucoup, de tests.

    Dans l’autre sens, les tickets, ça va être sympa pour savoir où les coller. Dans le projet central pour un bug constaté depuis l’application, puis un expert le déplacera dans le sous-projet adéquat?

    La partie que je préfère reste quand même le choix des services. RabbitMQ, le proxy SSL de HAproxy, Postfix, et, le top du top, Cassandra.
    Voilà, c’est comme ça et pas autrement. Nous avons ici le pattern de la Ford T : vous pouvez choisir n’importe quelle couleur, tant que c’est noir.
    Donc, une telle infra, personne ne pourra l’héberger sur son inévitable Raspberry Pi, et aucune association n’aura les compétences (même s’ils ont le matos) pour déployer et maintenir un tel bazar. Donc voilà, c’est un service web que vous pouvez installer n’importe où tant que c’est Gandi. Merci Henry Ford.

    Donc, dans l’ordre, les services.

    RabbitMQ. Le standard de fait des brokers, en AMQP, écrit dans un dialecte Erlang (https://github.com/rabbitmq/erlando), par ce que Erlang c’est beaucoup trop mainstream. Redis est capable d’agir comme broker, aussi, et si on utilise aussi Redis pour gérer du cache, beinh hop, on peut radiner sur l’infra. Pour rappel, Celery est aussi un standard de fait, et il permet de « broker » de manière abstraite, en python.

    Le protocole proxy v2 de Haproxy. Ok, c’est un standard de fait (Hitch l’implémente, par exemple https://hitch-tls.org/), mais dans l’absolue, on s’en fout un détail de déploiement. Le vrai besoin est d’avoir une implémentation fiable (basée sur openssl, bon courage), et qui ne masque pas les informations (IP source, protocoles négociés…) pour n’avoir que des services en TLS.

    Le LMTP de Postfix. Ça veut dire avoir la main sur le domaine, et pas juste un compte sur un serveur mail. Du coup, il va aussi falloir choisir entre les règles de spams SMTP ou du sur mesure.

    Cassandra. Une base orientée colonne, mais surtout orienté gros cul, libérée par Facebook. Conçu initialement pour gérer les flots niagaresque de logs, elle est reconnue pour avoir un excellent débit en écriture, la faiblesse des bases orientées colonnes. Son architecture « sans maitre », est conçue pour avaler des centaines de To sans broncher. J’ai de gros doutes sur la capacité de Cassandra à scaler petit, pour moi, le minimum étant 3 serveurs. Je n’ai par contre aucun doute sur l’incapacité de 99% des gens intéressés pour héberger cette application, a maintenir (et même backuper) un cluster Cassandra.
    Ce choix m’inquiète clairement. Même Bill Gates, une des personnes les plus spammées au monde ne doit pas avoir suffisamment de messages pour saturer un Postgresql, par exemple. Cassandra serait justififiée par une mutualisation massive d’un service Caliopen, genre la dimension d’un Gmail des gens discrets?
    Google a indiqué que l’astuce de Gmail est d’utiliser un index par utilisateur, parce que les requêtes sur plusieurs comptes ne sont pas légitimes. Bon, l’explication a été donnée avant les révélations de Snowden, mais je n’ai pas envie que la recherche sur plusieurs comptes soit possible dans Caliopen. À la rigueur des statistiques anonymisée, ou des informations pour isoler les vagues de spams, sont envisageables, mais la possibilité d’avoir la fonctionnalité « La vie des autres », non.

    Je ne comprends pas.

    Au moins, ça ne me rend pas triste de ne pas comprendre.

    Donc, Caliopen, pour pouvoir signer et indexer mes messages va avoir besoin de ma clef privée GPG, voir même du S/MIME, quelle partie sera faite côté client (en javascript), quelle partie sera faite côté serveur? Le serveur va avoir besoin de lire le contenu pour l’enrichir pour l’indexer et le trier. Je n’ai pas envie que ma clef privée traine sur un serveur, par principe. Quelle que soit la confiance morale dont je peux avoir dans mon hébergeur. Ma clef privée c’est mon slip, et mon slip ne traine pas sur Internet.

    Donc, là, en l’état, je n’ai aucune envie de contribuer à Caliopen.

    Ce qui est ballot, j’ai les compétences techniques, et diverses affinités avec les domaines touchées par ce projet.

    Ce que j’aime avec les projets open sources bien fichus, c’est l’approche tout ou parties. Le projet est construit pour constituer un tout, mais chaque partie est utilisable. Lamson, par exemple, un projet martyrisé dans un domaine proche de Caliopen, qui propose de créer simplement un serveur SMTP dynamique. Un peu comme passer d’Apache à PHP, imaginez la révolution technique! Bref, ce projet est un échec comme application, mais il fournit la meilleure lib python pour lire des mails et gérer le bazar des encoding et la hiérarchie des contenus MIME. Voilà, tout ou parties.

    Je suis extrêmement pessimiste sur les possibilités de Caliopen de fournir ce genre d’outils, tout ou parties.

    Je suis triste par ce que je vais me faire engueuler pour avoir écrit ça.

    Je suis triste par ce que le travail produit jusqu’à présent pour Caliopen est loin d’être négligeable, et qu’avoir un partenariat industriel pour un projet open source est un luxe rare.

    Je suis triste, mais j’espère de tout coeur avoir tort. Par contre je n’installerai jamais de Cassandra sur ma machine, même dans un docker, pour gérer une boite mail.

    1. Je ne fais pas partie du projet et n’en ai donc qu’une connaissance limitée, mais je pense qu’une bonne partie de ton commentaire repose sur un malentendu : CaliOpen *n’est pas* destiné à être auto-hébergé. Le but du projet est de rendre plus difficile la surveillance de masse en sensibilisant, démocratisant et rendant plus accessibles les outils de protection de la vie privée dans les correspondances électroniques. Comme mentionné au début de l’article, pour que cela fonctionne, il faut que le nombre d’utilisateurs soit le plus élevé possible, et au minimum très élevé.

      Des outils de messagerie sécurisés accessibles aux plus compétents techniquement et éventuellement auto-hébergeables, il en existe déjà. Le but de CaliOpen n’est pas de leur faire concurrence mais de proposer un service accessible et attirant pour l’utilisateur lambda, notamment par son interface et ses fonctionnalités. Et ce service pourra être rendu par des organisations de différents types, s’engageant sur le respect de la vie privée et la sécurité des échanges, en général (si j’ai bien compris) sur une base payante.

      CaliOpen est donc prévu dès le départ pour ce type d’installations, qui peuvent potentiellement, si le projet se rapproche de son objectif, regrouper plusieurs milliers, dizaines de milliers, centaines de milliers d’utilisateurs. D’où les choix technologiques.

      Alors certes, ça ne tournera pas sur un Raspberry pi, ça tournera peut-être sur un dédié un peu costaud moyennant quelques pas mal de mains dans le cambouis, mais dans tous les cas, encore une fois, ça n’est pas l’objectif.

    2. Je suis triste de te voir triste,

      Par contre je suis content qu’il y ait tout de même des gens qui agissent.
      Même si ce n’est pas parfait, que les choix technos peuvent être discutables, que l’archi microservice versus monolithique ça pue (ou pas, ça dépend, là on ne sait pas encore).

      Il y a une chose à ne pas oublier, Caliopen ce n’est pas seulement pour les névrosés de la sécurité/vie privée mais aussi pour une voir plusieurs générations de gens qui ne savent pas utiliser une souris (merci les tablettes).

      Imagine tata Simone qui envoie un message chiffré et signé avec sa clé GPG, la clé privée est sur le serveur, ok osef, elle gagnera des points en créant une nouvelle stockée sur sa machine).

      Imagine la source d’un journaliste est protégée car la communication chiffrée. Tu me dira que ça n’empêche pas d’avoir les metadata, mais il faut bien commencer quelque part.

      Caliopen c’est comme hadopi, c’est pédagogique (trololol).
      Caliopen et tous les autres projets (SMSsecure, iMessage, & co) sont pour moi garants de la liberté de communiquer de manière privée.
      Si on ne peut pas communiquer librement les prochaines générations perdront peut être même tout sens critique, si c’est pas déjà le cas… m’enfin je vais pas réécrire 1984 (et puis je suis pas doué pour ça).

      En tout cas le problème là tout de suite, c’est que Caliopen n’existe pas encore.
      Et comme dit souvent Laurent, terminons la v0 avant de parler de la v3.

      PS: Il y a d’autres canaux de com. pour causer technique
      PPS: il n’y a pas de submodules git, juste un pauvre script bash qui fait des clones si je me souviens bien, sinon j’aurai été triste aussi.
      PPPS: J’ai pas vu de gars en chemise ni de stagiaire, mais en fait j’ai vu personne. Et ça fait pas de mal de voir un projet un tant soit peu organisé/industrialisé.
      Et la gestion de version en dossier sur un serveur FTP c’est surfait.

  6. Je comprends mieux l’intérêt de CaliOpen en effet, une bonne idée dans le fond.

    Cependant j’ai une question, si j’ai bien compris, une même conversation pourra se poursuivre entre deux interlocuteurs au travers différents protocoles/services.

    Si mon collaborateur m’envoie un mail, je puis lui répondre via IRC si cela est plus sécurisé, le tout dans une « même fenêtre » quand j’utiliserais CaliOpen.

    Cependant, pour mon collaborateur qui ne l’utilise pas, il aura son message dans sa boite d’envoi mail et ma réponse dans un chat IRC, n’est-ce pas un freins à l’utilisation de CaliOpen ? Le fait de ne pas avoir, pour une personne qui ne l’utilise pas face à un collaborateur qui l’utilise, une conversation morcelée entre différents services ?

    En espérant que le projet trouve de nombreux contributeurs !

  7. Une question sans doute stupide mais je la pose quand-même.
    La NSA et consorts sont moins intéressés par ce que se racontent Alice et Bob que par le fait de savoir simplement qu’Alice et Bob se parlent, avec telle fréquence, tel volume de correspondance, etc. Je n’ai pas compris en quoi Caliopen permettrait de masquer leurs identités et les caractéristiques de leurs échanges ?

    1. La réponse, s’il y en a une, réside d’avantage dans la multiplication des services que dans la sécurité ou le chiffrement eux-même: il ne coûte que X milliards pour surveiller la quasi-totalité de la population, quand elle utilise 5 ou 6 grands silos (Gmail, Yahoo, Hotmail etc).

      Si on multiplie le nombre de services qui traitent la correspondance privée ne serait-ce que par 1000 (imaginons 6000 instances de Caliopen dans le monde, gérant chacune quelques centaines de milliers d’utilisateurs face aux centaines de millions que gère Google, par exemple), alors construire les graphes sociaux dont tu parles coutera X*1000 milliards. Trop cher pour n’importe quel état.

      Si, en parallèle, ces services proposent une UI qui pousse ses utilisateurs à modifier leurs usages en respectant mieux la vie privée de leurs contacts et la leur, à mieux prendre conscience de la valeur de leur vie privée, ce chiffre sera encore multiplié au delà de tout.

      Ce sont les deux équations économiques sur lesquelles Caliopen entend jouer pour changer les choses. C’est moins technique et sexy que d’inventer un nouveau protocole hypersécurisé (mais qui ne sera utilisé par personne), mais c’est plus réaliste, à mon avis.

      1. Je ne comprends toujours pas. Même s’il y a multiplication des services de type Caliopen, mais qu’au final ça finit par transiter par les 5 ou 6 mêmes silos, en quoi ne saura-t-on pas qu’Alive te Bob se causent ?

  8. Bonjour,

    Merci pour ces explications. Je comprend enfin de quoi il s’agit! J’avoue que j’avais plusieurs fois entendu parler du projet. J’avais bien compris la finalité. Par contre, les explications étaient tellement axées sur l’objectif « philosophique », qu’il en ressortait qu’on ne savait pas de quoi on parlait. Donc merci pour cette nième explication, maintenant je comprend ce que doit être Caliopen, et pas seulement ce que ce n’est pas.
    Bon, ça reste abstrait pour moi, étant donné mes compétences proches de zéro, mais à minima, j’en parlerai autour de moi, et je suivrai un peu plus l’actualité du projet.
    Je me permet un petit conseil « communication » : avant d’entrer dans le détail des objectifs et de la manière d’y arriver, une description simple et rapide de l’objet lui-même. Ça permet à l’auditeur de faire reposer la suite sur un truc qu’il peut visualiser (un peu comme mettre un visage sur un nom)…
    En tout cas l’idée semble très intéressante, et j’espère sincèrement qu’il en sortira quelque chose.

  9. Mais à quoi sert un outil pour communiquer de manière chiffrée si on a un gouvernement qui est l’ennemi de la population ?
    Si cela devient trop cher pour un gouvernement de surveiller les communications via internet, il passera à autre chose. Et les communications elles-mêmes ne servent à rien: les changements sont toujours faits à un moment ou un autre en communiquant ouvertement avec le reste du public.
    Alors, soit cela va encourager les gouvernements à mieux contrôler ces moyens d’accès (journaux, publication sur internet via les hébergeurs, …), soit on prétend ici qu’on peut communiquer avec le grand public sans être connu du gouvernement. Mais cette dernière possibilité est très dangereuse, car cela implique que la justice ne peut pas non plus s’y appliquer (si elle le peut, alors, c’est qu’il y a un moyen d’accès, et que donc le gouvernement le peut aussi).

    Le gouvernement tend naturellement à profiter de son pouvoir, c’est pour cela qu’on lui oppose un contre-pouvoir citoyen. Mais dans le cas de cet outil, c’est au final la démission du pouvoir citoyen, qui accepte que le gouvernement soit mauvais et se contente de se protéger dans sa bulle plutôt que de jouer son rôle en faisant de la vraie politique.

    Les politiciens qui parlent d’informatique disent souvent n’importe quoi. Du coup, un informaticien intelligent saura qu’il est fort possible que lorsqu’il fait lui-même de la politique, il risque de dire tout aussi n’importe quoi. Quels sont les « vrais » politiciens qui participent à ce projet ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *