Nous sommes heureux d’annoncer la parution de la première version stable de Dino : la version 0.1. Ceci marque une étape importante du processus de développement commencé il y a trois ans, composé du travail combiné de trente contributeurs, dont quatre étudiants du Google Summer of Code et de multiples sprints de développement.
Dino est une application sécurisée et libre de messagerie instantanée décentralisée. Elle utilise le protocole XMPP (« Jabber ») et est interopérable avec les autres clients et serveurs XMPP. Nous nous efforçons de fournir une interface utilisateur intuitive, simple et moderne.
Cette dépêche est une traduction en français de l’article de lancement de Dino 0.1.
Motivation : pourquoi Dino ?
Les applications de discussion en ligne comme WhatsApp et Facebook Messenger sont faciles à utiliser, et ont donc été adoptées par des milliards de gens. Cependant, elles sont propriétaires et les entreprises derrière elles sont fréquemment critiquées pour malmener les données personnelles de leurs utilisateurs1. Un certain nombre d’applications de messagerie instantanée ont été créées avec comme but de fournir une alternative plus respectueuse de la vie privée, comme par exemple Signal et Wire, mais même si elles chiffrent les messages et ont libéré leur code source, leurs utilisateurs doivent toujours accepter un service centralisé, et faire confiance à une entreprise privée.
XMPP est un protocole ouvert pour des communications fédérées. Il existe beaucoup de serveurs publics qui communiquent les uns avec les autres, et n’importe qui peut héberger son propre serveur. Cela fournit une excellente base pour fabriquer un client de messagerie instantanée décentralisé et respectueux de la vie privée. Nombre de clients existent déjà pour le protocole XMPP, cependant Dino vise un public différent. Alors que les clients existants ciblent les utilisateurs avancés maîtrisant la technologie, l’écosystème XMPP manque d’un client qui soit agréable à utiliser tout en fournissant les fonctionnalités que les gens attendent d’une application de messagerie instantanée moderne. Dino remplit ce manque en tentant d’être sécurisé et respectueux de la vie privée, tout en offrant une excellente expérience utilisateur.
Fonctionnalités
Au premier abord, l’interface utilisateur de Dino ressemble à celle d’autres messageries instantanées populaires qui pourraient vous être familières. Sur le côté gauche, vos conversations ouvertes sont listées, ordonnées de façon à ce que les derniers messages reçus soient toujours en haut. Vous pouvez ouvrir de nouvelles conversations ou rejoindre des salons de discussion avec le menu « + ».
Messagerie instantanée et plus
Vous pouvez envoyer des messages à vos contacts ainsi qu’à des groupes privés ou à des salons publics. Dino peut être utilisé en même temps que d’autres clients, ce qui fait que vous pouvez continuer une même conversation sur votre téléphone comme sur votre ordinateur. Les messages que vous envoyez et recevez lorsque Dino était éteint sont synchronisés au lancement.
Dino gère le partage d’images et d’autres fichiers, il peut les transférer via votre serveur ou directement à votre contact, en pair à pair et sans limite de taille de fichier.
Une recherche de messages avancée vous permet de rechercher et de filtrer votre historique de messages, globalement ou dans une conversation donnée. Après avoir examiné les résultats, vous pouvez sauter à un message pour lire davantage de contexte.
Vous pouvez utiliser plusieurs comptes dans la même interface pour, par exemple, séparer facilement votre identité au travail et à la maison.
Securité et vie privée
La sécurité a été un point central dans le développement de Dino depuis le tout début. C’est pourquoi nous prenons en charge deux méthodes de chiffrement de bout en bout directement : le standard de chiffrement bien connu OpenPGP vous permet d’étendre la toile de confiance des courriels à XMPP. Le protocole à double ratchet OMEMO fournit un système de chiffrement moderne2 où chaque client a une confiance spécifique, et est utilisé à grande échelle sur le réseau XMPP.
Nous prenons votre vie privée au sérieux dans chaque détail. Par exemple, vous pouvez empêcher Dino d’informer l’émetteur d’un message que vous l’avez lu, pour qu’il ne voit pas le double‑check sur ses messages. Dino vous permet de configurer ses fonctionnalités de vie privée par contact : vous pouvez garder vos meilleurs amis au courant de vos activités, tout en ne partageant rien avec les étrangers.
Rapide et bien intégré
Dino n’inclut pas un navigateur Web complet avec sa consommation de ressources faramineuse et ses nombreuses potentielles failles de sécurité. À la place, il est une application de bureau native, ce qui lui permet d’être léger et de consommer vraiment peu. Dino s’intègre très bien avec le reste de vos applications et services de bureau.
Prêt ?
Après avoir créé un compte XMPP, vous pouvez contacter d’autres personnes à travers du réseau XMPP globalement connecté. Les adresses XMPP sont de la forme utilisateur@example.com. Vous pouvez vous connecter avec un compte existant ou en créer un nouveau !
-
N. D. M. : sans parler des graves problèmes de sécurité. ↩
-
N. D. M. : voir cet article de Florian Maury paru dans Misc : « Chiffrement de messagerie quasi instantanée : à quel protocole se vouer ? ». ↩
Aller plus loin
- Version originale de cet article sur JabberFR (62 clics)
- Version originale sur le blog de Dino (28 clics)
- Site officiel du projet (217 clics)
# XEP 375 de 2016
Posté par DjeFr . Évalué à 8.
Extrait de la page https://dino.im/#features :
Ce Lien pointe sur la XEP-0375 qui date du 2016-07-20 et a été successivement remplacée par les XEP-0387, XEP-0412 puis XEP-0423.
Est-ce un choix délibéré ? Une contrainte pour être compatible avec les serveurs xmpp actuels ?
[^] # Re: XEP 375 de 2016
Posté par Nÿco (site web personnel) . Évalué à 4.
Bien vu, je l'ai rapporté, merci.
[^] # Re: XEP 375 de 2016
Posté par Olivier Jeannet . Évalué à 2.
Ça fait longtemps que je ne les utilise plus, mais pourquoi refaire un client XMPP alors que j'ai connu et utilisé entre autres : Gajim, Pidgin, Psi (qui faisaient plus que XMPP certes) ?
[^] # Re: XEP 375 de 2016
Posté par Zatalyz (site web personnel) . Évalué à 6.
Chaque client a son orientation dans le développement. En pratique ça se traduit par une ergonomie vraiment différente, et donc des publics différents.
[^] # Re: XEP 375 de 2016
Posté par jyes . Évalué à 3. Dernière modification le 05 février 2020 à 10:38.
Oui, par exemple tous les exemples cités (Gajim, Pidgin, Psi) n’utilisent pas les « client side decorations » et s’intègrent beaucoup trop bien dans un environnement hors Gnome. Il fallait absolument y remédier.
# Dino pour windows, android, iOS ?
Posté par DjeFr . Évalué à 10.
Le grand public étant la cible de Dino, est-il prévu de proposer des clients sur les plateformes utilisées par le grand public comme windows, android, iOS ?
[^] # Re: Dino pour windows, android, iOS ?
Posté par bepolymathe . Évalué à 5.
Je me faisais la même réflexion…
[^] # Re: Dino pour windows, android, iOS ?
Posté par Nÿco (site web personnel) . Évalué à 7.
Ayant discuté avec les développeurs ce week-end, les portages Windows et macOS sont en cours, ils ont besoin d'aide.
Pour iOS et Android, je ne sais pas.
[^] # Re: Dino pour windows, android, iOS ?
Posté par Link Mauve (site web personnel) . Évalué à 7.
Pour la partie mobile, je ne suis pas au courant d’un port de GTK+ sur Android ou iOS, ce qui rend à peu près impossible le port de Dino vers ces systèmes d’exploitation. Cependant il tourne déjà bien sur Phosh ainsi que sur d’autres systèmes Linux mobiles.
Il existe aussi déjà Conversations sur Android qui fournit une interface similaire à celle de Dino, ainsi que divers clients pour iOS (Siskin IM ou Monal par exemple).
Je trouve que c’est une bonne chose d’avoir des clients dédiés à une plateforme unique, ça permet de bien mieux prendre en charge les spécificités de chacune de ces plateformes et de ne pas se disperser en support. Les services proprio font de même, en ayant des équipes et des codebases dédiées à chaque OS, mais en partageant le même nom et le même style d’interface.
# Au boulot
Posté par gnumdk (site web personnel) . Évalué à 9.
Salut,
je l'utilise au travail (qui nous fournis un serveur XMPP) depuis deux ans et c'est vraiment un outil sympa très bien intégré à GNOME.
Reste encore des trucs à corriger (et il faut que je trouve le temps de faire des rapports de bug) comme par exemple ce menu hamburger à droite:
- qui est en doublon
- qui ne respecte pas les HIG GNOME
- qui n'est même pas un menu
[^] # Re: Au boulot
Posté par Nÿco (site web personnel) . Évalué à 5.
Bien vu ! J'en ai parlé au lead dev…
[^] # Re: Au boulot
Posté par gnumdk (site web personnel) . Évalué à 4.
Merci, j'en profite parce que tu connais bien le projet :-)
Y'a un truc qui me manque dans Dino, c'est la possibilité d'envoyer des fichiers, ça me sert pas souvent mais du coup, je peux en recevoir mais pas en envoyer.
Sur la capture d'écran de la dépêche, je vois un bouton pour le faire, mais pourquoi donc je n'ai pas ce bouton sur mon Dino? :-)
[^] # Re: Au boulot
Posté par Link Mauve (site web personnel) . Évalué à 6.
Ton serveur doit exposer HTTP File Upload (XEP-0363) pour que Dino affiche ce bouton.
Tu peux utiliser le Compliance Tester de Conversations pour vérifier que ton serveur le gère bien, il te donnera même des conseils sur comment l’activer selon le logiciel serveur que tu utilises.
[^] # Re: Au boulot
Posté par gnumdk (site web personnel) . Évalué à 4.
C'est bizarre, je viens de remarquer qu'il s'affiche en fonction du client en face, pas du serveur.
[^] # Re: Au boulot
Posté par seveso . Évalué à 3.
Probablement qu'il s'agit là de clients qui supportent également les transferts de fichiers en peer-to-peer avec Jingle (xep-0234).
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: re: Sortie de Dino 0.1
Posté par Nÿco (site web personnel) . Évalué à 5.
Effectivement, ces listes s'affrontent entre :
* messagerie interpersonnelles : WhatsApp, Telegram, FB Messenger…
* Messageries de groupes/équipes : Slack, Discord, MS Teams…
Tu vas pousser ton changement vers upstream, afin que l'équipe puisse le considérer ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: re: Sortie de Dino 0.1
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Une option pour une appli gnome ? Non mais tu n'y penses pas sérieusement ?
# chiffrement de bout en bout par défaut, OUI / NON ?
Posté par J'informatique (site web personnel) . Évalué à 3.
Bonjour,
Sur le site on peut lire
Je trouve cela paradoxale. S'il faut manuellement activer le chiffrement de bout en bout par OMEMO ou OpenPGP, que se passe-t-il tant qu'il n'est pas activé ? Est-ce que les messages circulent en clair sur le réseau ?
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 03 février 2020 à 13:00.
Il y a un chiffrement obligatoire entre clients et serveurs (C2S) et entre serveurs (S2S) avec XMPP. Le chiffrement de bout en bout ajoute une couche pour que tout ne soit pas en clair au niveau du ou des serveur(s), mais sur le réseau c'est toujours chiffré.
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par J'informatique (site web personnel) . Évalué à 5.
D'accord merci pour la précision. Alors lors d'un clic sur le cadenas apparaît :
- Unencrypted : cela laisse trompeur
- OMEMO
- OpenPGP
Merci à l'équipe de développement de proposer Dino qui ajoute de la simplicité dans l'interface. Par contre dans des futurs versions, serait-il possible d'activer le chiffrement bout en bout par défaut ?
Je trouve que c'est ce qui fait la grande force de Wire, Signal et Whatsapp. Cela ne demande aucune action de la part de l'utilisateur.
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
J'ai un épisode de parlons XMPP sur le chiffrement à moitié rédigé depuis très longtemps, mais je ne trouve pas le temps de le finir, je suis débordé. Il explique justement ça ainsi que les différences entre les méthodes de chiffrements utilisées sur XMPP.
En gros les 2 méthodes modernes (y'a de grosses discussions en cours pour que ça évolue, mais j'ai pas le temps maintenant d'expliquer en détails) sont OMEMO et OX (OpenPGP), qui permettent tous 2 (et contrairement à OTR) de fonctionner avec plusieurs appareils et quand le ou les correspondant⋅e⋅s sont hors ligne.
OMEMO a une confidentialité persistante, ce qui n'est pas le cas d'OX. En pratique, ça veut dire qu'un appareil ne peut pas avoir des messages antérieurs au moment où il est entré dans une conversation avec OMEMO, tandis qu'avec OX c'est possible. C'est une propriété qui est désirable ou non selon les cas.
Quant au chiffrement de bout en bout par défaut, le problème principal est que la spécification OMEMO a été mal faite et ne chiffre que le corps du message (et pas toutes les données autour, ce qui est très utilisé en XMPP avec les extensions). Du coup si on chiffre avec OMEMO, on fait une croix sur beaucoup de fonctionnalités, et on en arrive à des choses très moches et qui font grincer des dents dans la communauté XMPP, comme des données de mise en forme dans le corps du message (une partie qui ne devrait contenir que du texte pour les humains). C'est une des raisons pour lesquelles il y a de grosses discussions en cours, et que la version actuelle d'OMEMO va être retirée tôt ou tard pour une version faite correctement.
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Oui justement j'ai vu un Whatsapp tourner récemment (je n'ai jamais utilisé moi même), et j'ai l'impression que ça ne demande jamais de valider la ou les empruntes du correspondant, est-ce vraiment le cas ? Si oui ça me laisse perplexe, parce qu'un chiffrement de bout en bout sans vérification de l'authenticité ça ne sert pas à grand chose (à part à avoir un argument marketing peut-être).
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par Dring . Évalué à 1.
s/emprunte/empreinte
Je sais que c’est inutile mais ça piquait trop les yeux :-).
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
ouch oui, fatigue toussa :). Bon enfin avec le contexte, ça n'a pas empêché de comprendre.
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par ted (site web personnel) . Évalué à 5.
WhatsApp est une messagerie centralisée, donc le serveur pourrait te confirmer l'identité de ton interlocuteur. Dans ce cas il faut faire confiance à l'entreprise, mais vu que c'est un logiciel propriétaire l'utilisateur doit déjà lui faire confiance pour l'utiliser.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
le principe du chiffrement de bout en bout, c'est justement de ne pas faire confiance au serveur. Si c'est ton serveur qui valide les identités, ça ne sert à rien (à la limite à chiffrer les données pour le serveur, comme ça s'il y a un problème il peut indiquer – ou prétendre – qu'il ne pouvait rien savoir).
Et proprio ou libre ça ne change pas grand chose ici, l'important c'est qui a accès au serveur.
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par barmic 🦦 . Évalué à 5.
Par défaut tu fais confiance à l'identité du serveur, mais tu peux la valider avec ton contact si tu le souhaite. Soit via un code de 60 chiffres soit un qr code.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par Nucleos . Évalué à 4.
Dans une conversation WhatsApp, est indiqué très lisiblement si quelqu'un change de signature. Donc on ne te demande pas de valider un changement, mais on t'informe clairement. Concrètement, ça permet de savoir quand quelqu'un vient de perdre son portable et n'a pas accès à ses sauvegardes…
[^] # Re: chiffrement de bout en bout par défaut, OUI / NON ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 04 février 2020 à 11:55.
Oui donc ça fait confiance à la première utilisation (TOFU), si le serveur t'envoies n'importe quoi au début ça passe.
Que se passe-t-il si quelqu'un a un nouvel appareil (quelqu'un qui était sur un téléphone et ajoute une tablette par exemple) ? Il y a une notification, quelque chose ? Rien à valider je suppose ?
# OMEMO
Posté par Anonyme . Évalué à 5. Dernière modification le 03 février 2020 à 22:32.
Hors Sujet : est-ce qu’il existe des implémentations d’OMEMO en dehors d’XMPP ?
J’aurai bien voulu remplacer
weechat-otrpar quelques chose de plus moderne (et de maintenu aussi).[^] # Re: OMEMO
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
OMEMO est l'adaptation de double ratchet pour XMPP, ça n'a pas de sens en dehors de XMPP. OTR par contre n'est volontairement lié à aucun protocole, ce qui fait qu'on peut l'utiliser avec pratiquement n'importe quoi. C'est d'ailleurs un des rares avantages qu'il a sur OMEMO : il peut fonctionner avec des passerelles vers d'autre protocoles.
# OMEMO interdit en France?!
Posté par Maxzor . Évalué à 4. Dernière modification le 08 février 2020 à 16:32.
Pour mon inculte moi Matrix (Riot.im) est cool et XMPP est une niche de nerds décadente.
Je change rapidement de point de vue.
Je viens de lire ça : https://wiki.404.city/en/XMPP_vs_Matrix
wtf?!
[^] # Re: OMEMO interdit en France?!
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 10 février 2020 à 10:07.
Pour OMEMO je ne sais pas, mais pour le reste du tableau, ça m'a pas l'air très rigoureux :
[^] # Re: OMEMO interdit en France?!
Posté par Faya . Évalué à 7.
En suivant les différents liens, j'ai trouvé ça : https://www.nextinpact.com/news/103575-les-outils-chiffrement-face-a-declaration-a-anssi-exception-francaise.htm
Et effectivement, sur le site de l'ANSSI :
Donc si je comprends bien, la France impose une déclaration (longue et compliquée) et seul Apple respecte cette obligation pour pouvoir publier son App dans son Store.
[^] # Re: OMEMO interdit en France?!
Posté par SlowBrain (site web personnel) . Évalué à 1.
Pour le coup la démarche de la pomme me semble plutôt positive envers les utilisateurs (même si elle casse les pieds aux développeurs)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.