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 pamputt . É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.
[^] # Re: typo
Posté par patrick_g (site web personnel) . Évalué à 3.
Fait.
# Code source et configuration...
Posté par aurel (site web personnel, Mastodon) . Évalué à 5.
Un code source qui contiendrait des informations de configuration ?
…
-> []
# Idée de qualité
Posté par Zenitram (site web personnel) . Évalué à 10.
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 Maclag . É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 Professeur Méphisto . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 4. Dernière modification le 12 décembre 2014 à 14:10.
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 BAud (site web personnel) . Évalué à 6. Dernière modification le 12 décembre 2014 à 22:37.
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" :
[^] # Re: Idée de qualité
Posté par barmic . Évalué à -3.
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.
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 rakoo (site web personnel) . É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 barmic . Évalué à 3.
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 rakoo (site web personnel) . Évalué à 6.
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 Cyril Brulebois (site web personnel) . É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 NumOpen . É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…
[^] # Re: MErci et au revoir
Posté par Sak . Évalué à 3.
Sont-ce des projets, ou c'est utilisable là tout de suite ?
[^] # Re: MErci et au revoir
Posté par NumOpen . Évalué à 2.
C'est utilisable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.