Sortie de Dino 0.1

Posté par  (site web personnel) . Édité par ZeroHeure, Davy Defaud et palm123. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
46
2
fév.
2020
XMPP

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.

Fenêtre principale de Dino

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 « + ».

Conversation avec une image embarquée et un fichier attaché dans Dino

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.

La recherche de messages de Dino, avec les résultats surlignés

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 fenêtre de gestion des clés OMEMO de Dino

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 !


  1. N. D. M. : sans parler des graves problèmes de sécurité

  2. 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

  • # XEP 375 de 2016

    Posté par  . Évalué à 8.

    Extrait de la page https://dino.im/#features :

    Dino supports the most important standard extensions (XEP) for a modern chat client*

    * It is compliant with the official XMPP Compliance Suites 2016.

    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  (site web personnel) . Évalué à 4.

      Bien vu, je l'ai rapporté, merci.

      • [^] # Re: XEP 375 de 2016

        Posté par  . É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  (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  (site web personnel) . É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  . É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  . Évalué à 5.

      Je me faisais la même réflexion…

    • [^] # Re: Dino pour windows, android, iOS ?

      Posté par  (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  (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  (site web personnel) . Évalué à 5.

      Bien vu ! J'en ai parlé au lead dev…

      • [^] # Re: Au boulot

        Posté par  (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? :-)

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # chiffrement de bout en bout par défaut, OUI / NON ?

    Posté par  (site web personnel) . Évalué à 3.

    Bonjour,

    Sur le site on peut lire

    Dino is secure by default: Your chats never leave your computer unencrypted. Once you enabled end-to-end encryption via OMEMO or OpenPGP, only you and your chat partners can read your messages, but not your server administrator or anyone else.

    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  (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  (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  (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  (site web personnel, Mastodon) . Évalué à 5.

          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.

          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  . É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  (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  (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  . É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  . É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  (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  . É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-otr par quelques chose de plus moderne (et de maintenu aussi).

    • [^] # Re: OMEMO

      Posté par  (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  . É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  (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 :

      • Ce n'est pas parce que "Most users use only Riot + Matrix.org" que Matrix est un "Monopoly network". Après, je ne sais pas si un serveur Matrix est plus embêtant à installer qu'un serveur XMPP, mais Matrix se connecte au Fediverse, c'est déjà davantage que ses concurrents (Slack, Mattermost et Rocket.Chat)
      • "Support one client for different OS" : "No. Lack of funding" ?? Ils parlent d'un client web ? Ce genre de client web ?
      • "Use in big network?" : il dit qu'il a plus de genou.
    • [^] # Re: OMEMO interdit en France?!

      Posté par  . É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

      Pour apparaître sur l'App Store français, les applications de chiffrement doivent être déclarées à l'ANSSI. Une démarche en apparence simple, devenue une barrière pour les petites équipes, comme celle de ChatSecure. […]
      ChatSecure pour iOS, un client de messagerie XMPP chiffrée, qui n'a pas encore mis les pieds sur l'App Store français d'Apple. La raison ? Apple réclame une attestation de déclaration à l'ANSSI, l'Agence nationale de sécurité des systèmes d'information. Depuis plus de trois ans, cette formalité bloque son concepteur américain, Chris Ballinger, qui nous explique ne pas être capable d'accomplir seul cette démarche. […]
      Apple semble être l'unique acteur à vérifier cette déclaration, depuis 2013. Les développeurs ne proposant pas leurs outils sur iOS et macOS nous affirment se dispenser sans problème de cette formalité…

      Et effectivement, sur le site de l'ANSSI :

      La fourniture, l’importation, le transfert intracommunautaire et l’exportation d’un moyen de cryptologie sont soumis, sauf exception, à déclaration ou à demande d’autorisation.
      (cf. https://linuxfr.org/users/rakoo/journaux/le-chiffrement-en-france )

      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.

Suivre le flux des commentaires

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