Journal La longue route de protonmail vers le libre

Posté par . Licence CC by-sa
Tags :
7
12
déc.
2014

Pour situer le contexte, ProtonMail se veut être un service de messagerie web sécurisé.

Lors d'une précédente dépêche appelant au financement participatif de ProtonMail, plusieurs lecteurs avaient soulevés dans les commentaires la question légitime de savoir où était le code source ce qui permettrait d'avoir plus confiance dans les propos des développeurs.

Pour rappel, les développeurs avaient d'abord fait savoir, le 20 mai 2014, qu'ils comptaient publier le code source dès que la bêta serait sortie. Ensuite, le 22 juin, il n'était plus question que de publier le code source de la partie chiffrement du client de messagerie Côté licence, il a été annoncé 3 jours plus tard que la licence choisit serait la licence MIT. Et depuis plus rien à propos de l'ouverture du code bien que le logiciel ait bien évolué.

Et depuis juin, je n'ai pas vu passer d'informations liées à une ouverture prochaine de tout ou partie du code source. Le sujet a été relancé le 2 décembre dernier dans ce billet de blogue où l'on peut lire la phrase suivante

We hope to do more than customer service in San Francisco however. The US is home to some of the world’s most talented designers and developers (not to mention the birthplace of Edward Snowden) so we are also actively looking for SF based designers and developers to help us improve the open source components of ProtonMail (which includes the front end and mobile apps currently under development).

Ce que l'on pourrai traduire grossièrement par

Cependant, nous espérons faire plus que du service clientèle à San Francisco. Les États-Unis est la maison de certains des plus talentueux designers et développeurs du monde (pour ne pas mentionner le lieu de naissance d'Edward Snowden) donc nous recherchons aussi activement des designers et développeurs de San Francisco pour nous aider à aider les composants open source de PotonMail (ce qui inclut le « front end » et les applications mobiles actuellement en développement)

On y apprend donc que la volonté de publier sous licence libre est toujours d'actualité au moins pour une partie. Mais toujours rien pour la partie « back-end ».

J'ai donc profité de ce billet pour leur poser la question et voici leur réponse.

We are also considering releasing the backend code as open source. We will have to weigh the advantages and disadvantages. Opening up the backend code gives insight into how our server infrastructure is set up and we would prefer to keep this information secret to make it more difficult for attackers to disrupt our infrastructure.

ce que l'on peut traduire par

Nous considérons également la possibilité de publier le code du « backend » sous licence libre. Nous devrons peser le pour et le contre. Ouvrir le code du « backend » donne des informations sur comment l'infrastructure de nos serveurs est conçue et nous préférions garder cette information secrète pour rendre plus compliqué les attaques qui conduiraient à perturber notre infrastructure.

Donc en bref, les développeurs semblent considérer toutes les possibilités mais l'ouverture complète du code n'est pas encore pour tout de suite (le code de la partie « front-end » n'a pas encore été publié à ma connaissance).

Vous en pensez quoi de votre côté, l'argument est-il recevable ?

  • # typo

    Posté par . Évalué à 2.

    Est ce qu'il serait possible de remplacer « i, » par « un » ? Par ailleurs, il faudrait également ajouter un « underscore » à la fin de la dernière traduction afin de la mettre en italique. Merci d'avance.

  • # Code source et configuration...

    Posté par . Évalué à 5.

    Un code source qui contiendrait des informations de configuration ?

    -> []

  • # Idée de qualité

    Posté par (page perso) . Évalué à 10.

    Vous en pensez quoi de votre côté, l'argument est-il recevable ?

    Ca veut dire qu'ils préfèrent la sécurité par l'obfuscation que la sécurité par la lecture par leurs pairs.

    Ca peut te donner une idée sur la confiance que tu peux leur accorder, suivant comment tu considères la sécurité par l'obfuscation face à la lecture par ses pairs.

    • [^] # Re: Idée de qualité

      Posté par . Évalué à 8.

      Je leur accorderais presque un doute raisonnable, et je m'étonne que tu ne mentionnes pas une condition qu'ils doivent remplir:
      Il faut qu'ils captent suffisamment d'attention de leurs pairs pour que la libération du code soit bénéfique au projet.
      Un code libéré non revu n'est pas plus sûr qu'un code pas libéré.

      Cela dit, c'est la même chose pour les attaquants: si personne ne s'y intéresse, ils ne risquent pas de se faire attaquer…

      • [^] # Re: Idée de qualité

        Posté par . Évalué à 2.

        je m'étonne que tu ne mentionnes pas une condition qu'ils doivent remplir

        tu remarqueras aussi qu'eux-même ne la mentionnent pas. Pourtant, l’argument est tout à fait valable.

        • [^] # Re: Idée de qualité

          Posté par (page perso) . Évalué à 4. Dernière modification le 12/12/14 à 14:10.

          l’argument est tout à fait valable.

          C'est un point de vue.
          Un autre peut-être la conclusion qu'ils n'ont pas confiance en leurs compétences en sécurité, et ça la fout quand même mal pour des gens qui mettent en avant la sécurité (je mets de côté l'idée que la sécurité n'est qu'une excuse pour garder le code pour eux et se faire un max de thune avec, évitons de trop penser aux potentielles vraies raisons et restons sur l'idée qu'ils mettent en avant : la sécurité)

          Ici, la validité d'argument dépend fortement de point de vue…

      • [^] # Re: Idée de qualité

        Posté par (page perso) . Évalué à 6. Dernière modification le 12/12/14 à 22:37.

        Je leur accorderais presque un doute raisonnable

        o_O

        dans la réponse qu'il t'a faite, il parle de "Ouvrir le code du « backend » donne des informations sur comment l'infrastructure de nos serveurs est conçue et nous préférions garder cette information secrète" :

        • concernant http://vhffs.org par exemple, qui est un socle en libre d'hébergement de masse mutualisé, au moins utilisé par 3 associations du libre ou sympathisant
        • quelles informations en déduis-tu de l'infrastructure de http://tuxfamily.org et http://toile-libre.org ? (hormis que leurs admins sont bons)
    • [^] # Re: Idée de qualité

      Posté par . Évalué à -3.

      Ca veut dire qu'ils préfèrent la sécurité par l'obfuscation que la sécurité par la lecture par leurs pairs.

      Ils parlent de faire du chiffrement de bout en bout donc le code serveur (que l'on ne voit pas) devrait être en mesure de casser le chiffrement mis en place par le frontend (dont le code devrait disponible un jour).

      Ça réduit tout de même pas mal ton "argument-valise"1.


      1. argument contenu dans une phrase toute faite, qui peut être sortie sans se fatiguer le cerveau et qui est de facto simpliste 

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Idée de qualité

        Posté par (page perso) . Évalué à 3.

        Ben justement, si c'est du chiffrement de bout en bout ça veut dire qu'on s'en balance complet du code du serveur, puisque le chiffrement et la sécurité ne reposent pas dessus. Tout ce qu'on veut c'est un audit du code client + une manière d’être sur que c'est bien ce code-la et pas un autre qui tourne (et ça, ça va être difficile avec du code dans le navigateur)

        • [^] # Re: Idée de qualité

          Posté par . Évalué à 3.

          une manière d’être sur que c'est bien ce code-la et pas un autre qui tourne

          Impossible pour du code serveur. C'est pas une question de code ouvert ou pas, c'est juste impossible.

          Le fait d'avoir le code client (à défaut d'avoir de spec) peut potentiellement permettre de créer un client alternatif (natif, signé numériquement si tu le souhaite).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Idée de qualité

            Posté par (page perso) . Évalué à 6.

            Impossible pour du code serveur.

            Et c'est pas grave: que le code soit ouvert ou ferme il n'entre pas dans la chaine de confiance, de la même manière que les routeurs entre le client et le serveur n'entrent pas dans la chaine de confiance. Si le code est ferme c'est pas grave.

            En allant plus loin, c'est même un avantage que l'ouverture du code ne soit pas nécessaire: si le protocole est suffisamment compréhensible au point que les détails d'implémentation du serveur importent peu, ça veut dire que n'importe qui, particulier comme entreprise, peut fournir un service équivalent.

            Par contre, on est d'accord sur le fait qu'avoir le code client soit nécessaire pour pouvoir garantir un minimum de sécurité.

  • # Euh, lol ?

    Posté par (page perso) . Évalué à 10.

    Cela s'appelle la sécurité par l'obscurité, génial.

    Et/ou c'est une piètre excuse pour ne pas publier tout le code, youpi.

    J'ai du mal à savoir laquelle des deux hypothèses est la pire.

    Dans tous les cas cela confirme la détestable première impression que j'avais eue.

    Debian Consultant @ DEBAMAX

  • # MErci et au revoir

    Posté par (page perso) . Évalué à 3.

    Maintenant qu'ils ont eu les sous, ils peuvent garder le code pour eux.
    Sinon, il y a aussi AutodefenseCourriel, CaliOpen, Unseen, Tutanota, Lavaboom, StartMail, Dark Mail…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.