Apichat a écrit 85 commentaires

Ensuite, cela pose le problème des identités évoqués dans un article dont j'ai perdu l'URL : c'est bien beau d'avoir sa propre instance ou s'abonner sur une instance particulière, mais le jour où l'instance ferme ou que l'on veuille "déménager" vers une autre instance, actuellement on perd tous ses followers/following et autres infos de compte. On repart de zéro, parce que le "login" est lié au nom de l'instance. Probablement que ça pourrait être résolu avec des fonctions d'export/import, ou en changeant la manière dont est forgé le login, mais pas sûr…

Il est probable que tu fasses référence à mon article :

salut@toto — salutation, règle éditoriale et nom sur Internet

une version plus courte, qui met l'accent sur d'autres points :

Mon Retour de PSESHSF : DNS & Minitel

Il y a aussi la vidéo de la présentation (20min) de mon article à Pas Sage en Seine :

https://www.youtube.com/watch?v=RIAv48OTYIA

Oui je trouve que Mastodon reste aveugle aux problèmes posés par l'utilisation d'une adresse username@hébergeur. En gros cette forme d'adresse correspond à la situation où la portabilité du numéro de téléphone n'existait pas. Quand on changeait d'opérateur on perdait notre numéro. Si la portabilité du numéro de téléphone n'existait pas, Free Mobile n'aurait jamais pu exister. Je propose d'utiliser une adresse de la forme salutation@nom (indépendante de l'hébergeur).

Mais ce problème ne se résout pas en développant un énième réseau social (XMPP, Ostatut, Diaspora, etc.) mais en automatisant et simplifiant la gestion des enregistrement DNS (ou du Gnu Name System) : il faudrait que je puisse autoriser facilement un hébergeur à écrire dans mes zones DNS (avec validation etc.). Bref que ça devienne accessible aux Michu-Morizeau.

Super ! Bon courage pour l'intégration :-) Pour Mailman, mon commentaire ne se voulait pas être un reproche.

Yunohost est "acteur de l'évènemnet" est-ce que ça veut dire qu'une intégration à Yunohost va voir le jour ? Ça serait vraiment, vraiment très bien !

Sachant qu'une intégration de Mailman patine depuis 1 an : https://yunohost.org/#/apps_in_progress_fr

Arff les adresses d'exemple sont encore de la forme "nom@hébergeur" alors que salut@louise ou coucou@goffi serait tellement plus swag et plus "internet décentralisé" ;-)

Pour rappelle : salut@toto — salutation, règle éditoriale et nom sur Internet

Bon c'est vendredi, mais pour de vrai : merci pour ce logiciel qui s'annonce vraiment pratique !

Merci à toute l'équipe de LinuxFR ! Ce site est super et l'ambiance est sympa :-) Merci aussi aux éditions Eyrolles.

En allant voir sur le site de Conversations et celui d'OMEMO il semble bien que le transfère de fichiers soit pris en charge, y compris en conférences (après j'ai pas testé dans tous les sens) :

voir aussi : https://github.com/siacs/HttpUploadComponent

Merci, est-ce possible de modifier aussi ce titre :

Avantages d'OMEMO et XMPP par rapport autres logiciels

Avantages d'OMEMO et XMPP par rapport aux autres logiciels

Merci pour l'article ! Ses tests sont très intéressants. Cependant ils ne portent que sur l'ergonomie, pas sur la sécurité effective. Par ailleurs il est dommage que Conversations n'ait pas été testé.

Le code client de signal est complétement libre. Ce qui permet de vérifier qu'aucune porte dérobé n'est caché.

@Régis tu n'as pas lu l'article de la FSFE, ni les extraits que j'ai publié dans ce journal. Lit-le et dis nous ce que tu en penses après.

https://blogs.fsfe.org/larma/2017/signal-backdoors/

On est bien d'accord que c'est Signal, Moxie Marlinspike et Open Whisper Systems qui choisissent d'utiliser Google Cloud Messaging et MapView ? Donc ils sont bien responsables des failles de sécurités de leur application qu'ils présentent comme sécurisée ?

@Régis tu n'as pas lu l'article de la FSFE. Lit-le et dis nous ce que tu en penses après.

Par exemple :

Signal est opensource :
Signal propose qu'on puisse compiler le code est vérifier que c'est le même distribué sur le Play Store

Précisément ce n'est pas le problème. Ça ne sert (presque) à rien d'auditer le code source de Signal ou de le recompiler pour vérifier sa conformité puisque le problème n'est pas dans SON code mais dans celui des services Google qu'elle utilise et sur lesquels elle repose.

Ou encore :

Le bémol c'est que nous devons leurs faire confiance pour les métas informations qui transitent par chez eux.

Oui le problème n'est pas les méta-informations qui transitent par chez eux mais les informations & les méta-informations qui transitent par Google lorsque l'on UTILISE l'application Signal.

Mais aussi :

Avec Signal ou Whatsapp il est excessivement facile de vérifier la clef soit via les numéros de sécurité soit en scannant le code QR Code.

Pour WhatsApp le code de l'application n'est pas public, donc on ne peut pas vérifier ce que fait concrètement l'application. L'application peut très bien te présenter un code tout en utilisant un autre puisque de bout en bout du transit du message tout passe par elle, sans que l'on puisse y déroger. Par ailleur elle a la possibilité d'ajouter silencieusement un appareil virtuel donc même si ta clef est bonne etc. etc. il y a une tierce personne qui a la clef et écoute la conversation. Cela renvoi au commentaire publié sur Reflets et à celui de Tanguy Ortolo publié ci-dessous.

Ah le lien vers Reflets était bon, je voulais bien pointer ce commentaire que je trouve intéressant. Si vous pouvez remettre l'ancre je préfère

https://reflets.info/whatsapp-backdoor-ou-petard-mouille/#comment-618434

En parlant de pot de miel, voilà des anar français qui suggèrent l'utilisation de Signal pour des conversations sécurisées : https://speakerdeck.com/dunglas/petite-introduction-a-lauto-defense-numerique

C'est inquiétant.

juste un comportement par défaut choisi pour ne pas faire fuir les utilisateurs.

Non ce n'est pas "juste" un comportement par défaut, c'est bien un comportement qui pose des problèmes de sécurité.

Imaginons que What's app notifie à chaque fois qu'une clef publique change.

Ce n'est pas quelque chose qui arrive tous les 4 matins. Et en plus ce n'est pas hyper-intrusif. Notifier ne veut pas dire "valider" comme c'est le cas pour SSH. Cette notification n'est pas intrusive, or elle n'est pas activée par défault :

Pour que chaque utilisateur fasse le choix d'accepter ou de refuser le changement de clefs, il faudrait leur expliquer de quoi il s'agit.

Oui face à ça Daniel Gultsch propose un comportement alternatif "Blind Trust Before Verification". Ce comportement est en place dans Conversations

A moins que chaque utilisateurs de la chaîne, veuillent réellement une communication confidentielle … bon courage.

Ah quoi bon clamer que c'est sûr si ce n'est pas "vraiment" sûr ? Notamment quand la menace principale, c'est à dire la NSA et le gouvernement américain, a les mains libres pour que ça ne soit pas sûr ?

Et surtout : pourquoi rejeter toute critique ?

Récemment, des représentants de gouvernements, dont le notre, reprochaient à Signal son système de chiffrement trop sûr; et ce, bruyamment.

Il faut bien vendre le pot de miel.

Je ne peut m’empêcher de croire qu'il y a anguille sous

Et bien là justement des gens te permettent d'avoir des éléments crédibles pour dépasser la simple croyance. Et les révélations Snowden dont le programme PRISM devraient être suffisant pour qu'on ne fasse pas confiance à ce type de logiciel aux sources fermées proposées par des entreprises étasuniennes dont les serveurs sont sur le sol américain.

Et vu les bonnes relations entre le gouvernement français et le gouvernement américain on peut sérieusement considérer qu'ils échangent des informations. D'ailleurs Reflets avait bien annalysée comment l'échange d'information entre agence de surveillances de différents permettait à chacune d'outre passer les interdictions de surveiller les habitants de leur propre pays.

Oula ! Oui merci ! Si un admin peut corriger ça, c'est cool…

Et aussi http://conversations.im

Peut-être n'ai-je pas compris ta réponse.

Mais justement avec la fonction de renvendeur de Gandi le client n'a pas à te "donner" (ou plutôt indiquer) son compte Gandi. C'est même l'inverse, c'est toi, en tant que fournisseur de service, qui lui "donne" (vend, en fait) un compte chez Gandi et enregistrement dans le DNS.

Du coup le client n'a jamais eu à faire la démarche pour savoir qui est "OVH", comment ouvrir un compte chez OVH, etc. etc. Ce qui simplifie énormément la démarche d'un utilisateur pour obtenir un nom de domaine, une adresse email, une adresse jabber, un hébergement web etc.

Le client n'a qu'a ouvrir 1 seul compte chez 1 seul prestataire pour avoir tout ça. Il délègue à son fournisseur de service la gestion de toute la complexité. Mais s'il souhaite quitter ce prestataire, il reste possesseur de son nom de domaine (et de ses données si les choses son bien faites) et donc il maintient toutes ses relations sociales. Aucune nouvelle adresse à donner (de conversation ou de médiatisation) à ses contact etc.

C'est le seul moyen d'aller chatouiller les GAFAM : que chaque internaute ai son nom dans le DNS.

De ce que j'ai compris (je n'ai pas essayé), la fonction revendeur permet de créer le compte client à la place du client. Ainsi il n'a pas à faire un allé retour entre OVH et ton service : il ne voit que ton service.

Est-ce pareil chez OVH ?

Chouette !

Par ailleurs, pour éviter de payer en plus à Gandi et rendre plus chère ton offre, je pense que devenir un bureau d'enregistrement auprès de l'Afnic n'est peut-être pas si compliqué (jamais essayé) :

https://www.afnic.fr/fr/produits-et-services/le-fr/devenir-bureau-d-enregistrement/

Pour Movim c'est une bonne idée mais peut-être compliqué. Je pensais surtout que tu pouvais indiquer à tes clients qu'ils peuvent utiliser http://conversations.im (Android) ou http://chatsecure.org (iOS) comme ça tu n'a "que" le serveur XMPP à gérer.

Salut,

Ton offre a l'air bien intéressante ! Cependant, pour des raisons que j'ai déjà expliqué ici il me semble que la base pour un service Internet est de permettre au client-usager d'utiliser son propre nom de domaine, d'avoir son nom dans le DNS.

Or sur ton site je lis :

[…] En plus d'une adresse au format @whiskers.top nous fournissons […]

Je pense qu'en tant qu'hébergeur libre, ne souhaitant pas enfermer tes utilisateurs chez toi, il est important de ne surtout PAS proposer ce format d'adresse (cf les liens ci-dessus).

À mon avis c'est aussi un énorme service rendu à tes clients que de leur éviter la configuration de leur propre DNS. Je sais que chez Gandi on peut être "revendeur" et ainsi ouvrir des comptes pour ses propres clients chez Gandi, en se mettant automatiquement en gestionnaire technique. En gros tes clients sont bien propriétaires de leurs DNS, mais tu les gères pour eux.

Gandi : Devenir un revendeur nom de domaine

Qu'en penses-tu ?

D'autres bureau d'enregistrement de noms de domaine proposent peut-être des services similaires ou mieux.

Par ailleurs, ce qui existe peu aujourd'hui c'est des hébergeurs pro qui proposent un hébergement XMPP à jour avec un nom de domaine personnalisé pour chaque client. Est-ce envisageable ?

Merci !

Pour compléter l'information le client android Conversation.im est libre ainsi que ejabberd - le logiciel qui fait tourner le service d'hébergement. Cependant je ne crois pas que l'interface graphique d'administration soit libre.

Sinon, un admin pourrait-il modifier un peu mon texte ? j'ai commis des erreurs d'orthographe :

• le titre pour ajouter un s à nom : Hébergeurs XMPP avec noms DNS personnalisés : Conversations.im & Mailbox.org
• remplacer le "et" par "est de" dans : simplifier la gestion d'un nom de domaine est de proposer en premier un service
• replacer "ne propose" par "proposent" dans J'en profite pour remarquer que peu de Chatons proposent une
• ajouter un point et une majuscule pour avoir : une prise en charge du DNS. Peut-être que ça viendra ?

Ça occulte quand même encore une fois un manque énorme sur mobile: l'absence de voix et vidéo!

Oui ce n'est pas encore disponible…

De plus, il mentionne comme beaucoup d'acteurs dans le monde XMPP: des choses qui vont arriver "bientôt".

Non, tout ce qui est présenté dans l'article est fonctionnel avec des exemples de logiciels implémentant ces fonctionnalités.

Par exemple Conversations sur Android :

https://conversations.im/

https://play.google.com/store/apps/details?id=eu.siacs.conversations&referrer=utm_source%3Dwebsite

ChatSecure sur iOS et Android :

https://chatsecure.org/

Qui propose aussi un service d'hébergement avec toutes ces fonctionnalités disponibles :

https://account.conversations.im/

Un outil de comparaison des services d'hébergement (aussi intégrer au logiciel Conversations) :

https://gultsch.de/compliance.html

Coter serveurs les plus avancés sont eJabberd et Prosody :

https://www.ejabberd.im

https://prosody.im https://modules.prosody.im

À propos des dernières évolutions de XMPP :

The State of Mobile XMPP in 2016 par Daniel Gultsch, développeur de l'application Android https://conversations.im

Et un dépôt Debian ? Est-ce en prévision ?