Salut,
Court journal, mais j'en avais marre de faire un lien + un commentaire. Bref, je suis tombé sur https://www.lemonde.fr/pixels/article/2023/11/29/les-ministeres-sommes-de-remplacer-leurs-messageries-instantanees-par-l-application-francaise-olvid_6203031_4408996.html
En gros, on demande aux ministères d'utiliser Olvid en lieu et place des messageries grand public.
Ça dit des trucs plutôt sensés comme :
« L’intégration de cette solution constitue non seulement une prise de conscience en matière de cybersécurité, mais aussi une avancée vers une plus grande souveraineté française » — Elisabeth Borne
OK, moi je valide. Mais ensuite ça parle de choses qui me questionnent :
Le Point, note que « les principales applications de messagerie instantanée grand public » (WhatsApp, Telegram, Signal) « occupent une place grandissante dans nos communications », mais « ne sont pas dénuées de failles de sécurité »
On peut ne pas aimer ces trois messageries pour leur côté « étranger à l'UE », mais de là à dire qu'elles ont des failles de sécurité… Vous en connaissez vraiment ? Et allez, challenge supplémentaire : quelles failles sont connues et relativement importantes dans Signal ?
Et enfin, il y a ce qui n'est pas dit, comme l'existence de Tchap qui est une instance de Matrix/Element réservée aux agents de l'État Français. Il y a également des failles de sécurité, mais au moins son code source est libre. Les clients Olvid sont effectivement libres, mais pas le serveur.
Bref, j'ai l'impression, sans preuve aucune, que ça sent le lobbying forcé sans raison technique valable. Et c'est la recette de l'échec selon moi, quand une solution n'est choisie que pour son côté politique. D'autant plus, enfonçons le clou, que :
Elisabeth Borne préconise ainsi le déploiement « pour le 8 décembre 2023 au plus tard » de l’application Olvid
Ça nous laisse encore 8 jours, même si la circulaire date du 22 novembre, ce qui faisait un total de 16 jours. Pour remplacer intégralement une solution de messagerie instantanée. Le cauchemar de tout DSI et support informatique.
# Qui développe ?
Posté par Cyprien (site web personnel) . Évalué à 8.
Ce que j'aurais aimé savoir : qui travaille sur Olvid ?
[^] # Re: Qui développe ?
Posté par woffer 🐧 . Évalué à 10.
Je ne sais pas mais il a sans doute attrapé le Colvid.
[^] # Re: Qui développe ?
Posté par aiolos . Évalué à 8. Dernière modification le 30 novembre 2023 à 11:46.
Olvid a été fondé par Matthieu Finiasz et Thomas Baignères, tous deux cryptographes de formations (diplomés de l'EPFL, dans l'équipe de Vaudenay). Leur solution a été auditée et validée par l'ANSSI ; pour celà, ils ont pris le parti de ne pas intégrer de lib externe mais de tout gardé développé en interne.
Edit : lien vers leur site : https://www.olvid.io/team/fr/
[^] # Re: Qui développe ?
Posté par Glandos . Évalué à 10.
En général, c'est une très mauvaise idée, mais oui, ça peut être un élément différenciant.
[^] # Re: Qui développe ?
Posté par aiolos . Évalué à 8. Dernière modification le 30 novembre 2023 à 15:33.
Dans le cas des audits de sécurité de ce type, ça simplifie beaucoup le travail et évite beaucoup des risques liés aux supply-chain attacks. D'autant plus qu'on est sur des protocoles crypto, donc ils sont spécialistes et largement au fait de l'état de l'art1.
Et j'ajouterais que, de ce que j'en ai vu, Matthieu en particulier est vraiment un excellent développeur, très exigeant, mais ça n'engage que moi et c'est une conviction difficilement transmissible…
1 : étant également cryptologue de formation, j'ai aussi toujours beaucoup de mal à faire confiance aux implémentations crypto. Quand je le fais, je prends le temps de tout relire, ce qui est parfois très chronophage…
[^] # Re: Qui développe ?
Posté par Moonz . Évalué à 10.
Je suis désolé, mais Matthieu peut être le meilleur dev du monde, j’aurai toujours plus confiance en l’implémentation de Ed25519/Salsa/… de libsodium que la sienne. Je sais laquelle des deux implémentations a eu plus d’yeux fixés dessus.
[^] # Re: Qui développe ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Tant que tu passes pas par l’atelier B par exemple, j’ai du mal à croire que ton implémentation est meilleure que d’autres.
Bien d’accord.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Qui développe ?
Posté par abriotde . Évalué à 7.
Ça c'est la meilleure chance d'avoir de grosses failles de sécurité : peu de gens maîtrisant le côté technique et encore beaucoup moins capable de remettre en cause les solutions.
Typiquement on est tellement sûre que c'est sécurisé qu'on en oublie une faille en bout de chaîne ou plus simple une faille de social engineering (NSA ou KGB)…
[^] # Re: Qui développe ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 8. Dernière modification le 01 décembre 2023 à 09:22.
La sécurité doit aller avec la confiance.
Un produit peut avoir un haut niveau de sécurité sur le papier (dev diplômés, certifs, soutiens de grosses structures…), mais un niveau zéro confiance en pratique (car privateur et nouvel arrivant sur le marché encombré des messageries).
Autrement dit : j'ai plus confiance dans la sécurité alimentaire du petit resto du coin chez qui je déjeune depuis 20 ans que dans une nouvelle chaîne de fast food agréée Nourriture Saine & Éthique (label créé hier matin).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qui développe ?
Posté par mahikeulbody . Évalué à 3.
Avec ton raisonnement, comment se fait-il que tu aies mis les pieds dans ton petit restaurant il y a 20 ans ?
Dans le cas d'Olvid, tu n'es pas obligé de faire confiance à l'ANSSI puisque le code est open source (warning : seulement les clients Android et iOS mais ça suffit pour communiquer, pas besoin du serveur).
[^] # Re: Qui développe ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Je n'avais pas confiance dans le petit restaurant. C'était de la veille
technologiquegastronomique !Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 10.
En effet alors que Tchap existe, le seul intérêt pour le gouvernement est de remplir sa fonction de porte-flingue pour les intérêts d'une entreprise française.
Du privateur oui, mais français monsieur.
Les propos sur la souveraineté numérique ne sont que du bullshit de startupeurs pour avoir des solutions privatrices nationales, pas pour la promotion du logiciel libre.
Ils veulent un Google français : la Poste y aspire, ouvertement, de même que Criteo, le fleuron français de la pollution publicitaire d'internet.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Astaoth . Évalué à 6.
Seul le serveur est proprio, mais le client et les specs clients/serveurs sont ouvertes.
Que le serveur soit open source ou non ne change pas grand chose pour les solutions non self-hostables (ou dans les solutions fédérées aussi, dans une moindre mesure), tout simplement parce qu'on ne peut pas vérifier ce qui tourne côté serveur. Les specs des protocoles utilisés ainsi que les implémentations le sont bien plus pour valider la confidentialité des échanges. Et pour le coup, ca a l'air d'être un peu audité quand même.
Très franchement, au vu du timing du calendrier, la question se pose, surtout au vu de nos habitudes législatives. Néanmoins il semblerait que certaines administrations utilisent déjà Olvid depuis quelques temps (donc c'est pas si soudain que ca comme annonce), et il se pourrait que cette annonce soit lié à un autre calendrier.
Emacs le fait depuis 30 ans.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 6.
C'est faire de nécessité vertu. La question de la confiance se pose dans les deux cas, de toute façon. Mais le propriétaire ne pourra apporter cette confiance tandis que le libre potentiellement. Ce dernier est une condition nécessaire mais pas forcément suffisante. Le privateur est rédhibitoire.
Je vois pas trop le rapport avec mon commentaire. Mais Tchap est en place depuis plus longtemps qu'Olvid pour la fonction publique. Il n'y a pas eu d'annonce, publique, à un aussi haut niveau du gouvernement et aussi impérative pour l'utilisation de Tchap.
Le contexte de plus en plus tendu, extérieurement pour le moment, fait que cet Etat prend des mesures, mais sert aussi la soupe à une boîte privée française. Après on parle d'un Etat qui a signé un contrat open bar Microsoft pour… son armée.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Astaoth . Évalué à 5.
Dans le cas d'un serveur sous licence libre, tu n'as strictement aucune garantie que le code tournant sur le serveur est celui qui a été publié. Je préfère largement avoir un client et des specs ouvertes et auditables, validant l'absence de besoin de faire confiance aux serveurs.
Néanmoins, dans le cas de Olvid, j'ai la sensation qu'il utilise autant ses serveurs qu'un réseau torrent. Le besoin de confiance dans le serveur serait du coup assez secondaire.
Je faisais référence à nos dernières évolutions législatives sur les backdoors dans les messageries chiffrées, au niveau européen courant 2023. C'est plus facile à imposer à des structures privées européennes.
Emacs le fait depuis 30 ans.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 5.
Une cuillère de goudron gâche un tonneau de miel. Client et serveur, l'un n'empêchant pas l'autre, d'ailleurs cela existe : Matrix, Jami, etc. Je préfère largement avoir un client libre ET un serveur libre.
«sensation», «assez», des impressions, donc.
Je te rejoins.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Astaoth . Évalué à 6.
Des impressions basées sur une lecture rapide de la doc et les feedbacks de chercheurs en infosec. C'est toujours mieux que de supposer au hasard en se basant sur rien.
Oui bien sûr. Tu as la preuve que le serveur Matrix auquel ton client se connecte soit synapse déjà ? Ou dans le cas d'un setup autohébergé, les serveurs auxquels ton synapse communique.
Pour Matrix en particulier, toutes les specs sont dispos pour que n'importe qui puisse écrire son propre serveur, et que ca soit transparent pour le client (ce qui est le cas ici par exemple ) : ca c'est idéal.
Par contre il n'y a aucune obligation que les serveurs déployés soient une de ces implémentations, du coup n'as strictement aucune garantie que le code qui tourne côté serveur soit libre. Ca peut tout à faire être une implémentation bien proprio, sans que tu le saches. Ou alors ca peut être un synapse, dont les gestionnaires ont été contactés par la DGSI pour une obligation d'y déployer un petit module bien opaque.
On retombe donc dans la même situation qu'avec n'importe quel client de messagerie instantanée : la sécurité et la vie privée ne peuvent être garanties que par les protocoles applicatifs et les clients, car tu n'as strictement aucune garantie que les serveurs avec lesquels tu communiques soient ce qu'ils prétendent être.
Emacs le fait depuis 30 ans.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 6.
Cela ne rend pas Olvid meilleur. Surtout que Matrix est le «cas idéal».
Voir ci-dessous.
Le «100% français», si cela a un sens, est sur… AWS…(voir le lien sebsauvage).
Tchap est lui opéré par des agents de l'Etat. Ce qui, de point de vue de sa propre sécurité, est meilleur.
La communication gouvernementale est un ridicule bullshit (on a l'habitude) et Olvid fait de l'open-source washing de startupeurs.
Pendant des années l'Etat n'a pas mis de moyens pour avoir une messagerie sécurisée et a permis, hallucinant, à dirigeants d'utiliser Whatsapp et autres saloperies.
A part Theorem, le téléphone Thompson, pour le cercle le plus restreint et que Macron n'est même pas foutu d'utiliser car ce ne serait pas pratique.
Cela fait quelques années que Tchap existe et d'un coup il faut 15 jours pour basculer sur Olvid ? Les gros sabots sont en prime.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Astaoth . Évalué à 2.
Tu parles de Olvid ? Une recherche ddg de "olvid sebsauvage" ne donne rien, aurais-tu ce fameux lien ?
Olvid est aussi utilisé par la police nationale depuis 1 ou 2 ans, ca débarque pas d'un coup, au hasard (cf wikipedia).
Mais si Thompson est un échec et que Tchap n'est pas privilégié, il y a peut-être une raison non ? Au hasard de l'expérience utilisateur ou des finalités complètement différentes je dirais.
Par exemple, est-ce que Tchap est ouvert aux personnes externes ? Avec un compte Tchap, peut-on parler à n'importe qui sur Matrix ? J'en doute un peu.
Egalement, est-ce que tu trouves que se balader au quotidien avec 2 smartphones et une brique c'est quelque chose de pratique ? Et est-ce la finalité de Theorem d'ailleurs ?
Bof bof, tu développes pas plus que ca en quoi "Matrix est le «cas idéal»".
Emacs le fait depuis 30 ans.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par mahikeulbody . Évalué à 9.
Sur le site d'Olvid :
Le serveur de distribution de messages d’Olvid est aujourd’hui hébergé par AWS.
https://www.olvid.io/faq/serveur-et-open-source/
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par flan (site web personnel) . Évalué à 4.
Il y a plusieurs messageries sécurisées, en fonction du niveau de sensibilité et du besoin. Il y a du fixe sécurisé (Osiris), du portable sécurisé mais avec des limitations (Teorem de Thalès, et non Thompson Theorem, pour l'instant), du portable moins sécurisé et assez cher (CryptoSmart)… mais en pratique, tu auras toujours des conversations pros/semi-pro sur des téléphones personnels ou pro de base, qui vont se faire sur du Telegram/WhatsApp/Signal/…
C'est clairement sur ce dernier créneau qu'Olvid a de la place, au même titre que Tchap. Simplement, tu peux communiquer sur Olvid avec n'importe qui et de manière plus sécurisée que Tchap, alors que Tchap va te limiter aux agents de l'État (en sachant que si tu changes de ministère et donc de courriel, ton compte Tchap est supprimé, ce qui est vite pénible).
Et qu'est-ce qui te fait dire que Tchap est d'un point de vue logiciel plus sécurisé qu'Olvid ?
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 2. Dernière modification le 04 décembre 2023 à 10:32.
Merci pour la correction pour Thalès à propos de Theroem. Merci également de donner les différents niveaux.
Je notais juste le peu de cohérence, d'un gouvernement qui demande en quinze jours de basculer sur cette messagerie pendant que le chef de l'Etat n'utilise pas Teorem. Je ne parlais pas de l'ancienneté, qui a déjà été évoquée.
Je disais que Tchap était plus sûr parce qu'opéré par les propres agents de l'Etat.
Après, inutile de rappeler ici qu'un projet libre est potentiellement plus sûr, pour peu qu'on y mette un tant soit peu de moyens.
Concernant le «cas idéal», je reprenais justement une expression d'Astaoth.
Un peu d'imagination, car si Tchap n'a pas été conçu pour discuter avec l'extérieur, Matrix le fait. Donc encore une fois, réinventer la roue.
Edit : j'oubliais le lien sebsauvage qui était ci-dessous et que je remets ici.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Psychofox (Mastodon) . Évalué à 3.
Je ne vois ce qu'ont à voir un délai court (mais raisonnable [1][2]) avec la pertinence ou pas d'utiliser Teorem[3].
[1] Quel est le problème d'installer et s'habituer à utiliser en 15 jours une appli, qui ressemble comme deux gouttes d'eau et fonctionne de manière similare aux applis mobiles de messagerie instantanée les plus populaires? On parle en plus d'un cercle très restreint. Les ministres et les membres de cabinet ministériels. Dès qu'il faut communiquer avec d'autres membres de l'administration publique, Tchap est toujours utilisable.
[2] Dans toute entreprise, le même genre de délais (15 jours à un mois) est généralement appliqué pour de nouvelles directives de sécurité ou changement d'applications.
[3] De ce que je comprends Teorem est un terminal complet, pas une appli, avec une fonctionnalité de répertoiee notoirement absente qui pose des problèmes d'usabilité pour la vie de tous les jours. C'est le genre de truc que t'es content d'avoir en période de guerre pour communiquer avec les membres du gouvernement et l'état major d'une armée mais qui n'est pas forcément assez userfriendly pour être utilisé 24h/7j en temps de paix.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 2.
C'était juste pour noter le «faites ce que je dis pas ce que je fais».
[1] Olvid ne fonctionne ni avec les adresses mail ni avec les n° de tél. Il faut soit une rencontre physique soit à distance avec la transmission par un biais téléphonique traditioonnel. Ces hauts représentants doivent avoir un carnet fourni, même en restreignant à leurs pairs guère compatible avec cet empressement.
[3] d'aucuns diront que la sécurité des communications de l'Etat, ce devrait être tout le temps. Mais bon.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par mahikeulbody . Évalué à 3.
L'offre pour les organisations comporte différentes options (LDAP, configuration of an External Identity Provider, etc…). Nul besoin de rencontre physique ou d'échange téléphonique.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Psychofox (Mastodon) . Évalué à 3.
En général ce n'est pas binaire. Et Olvid prétend assurer cette sécurité.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par flan (site web personnel) . Évalué à 3.
Le Teorem est en effet un terminal pas franchement ergonomique, mais il a quand même un carnet de contacts. Par contre, il est fait pour appeler d'autres Teorem (qui sont rares et chers dans l'administration), et n'a pas vocation à être utilisé au quotidien.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par flan (site web personnel) . Évalué à 2.
Mais Olvid et Teorem n'ont pas le même usage… Ça n'a juste rien à voir.
Et dire que Tchap est plus sûr car opéré par l'État n'a aucun sens. Tu peux uniquement dire que c'est mieux pour ce seul critère, c'est tout. Et si Tchap était troué de partout ?
Oui, potentiellement plus sûr. Potentiellement moins sûr également. Le Teorem n'a rien d'ouvert, très loin de là, et pourtant est bien plus sûr que Tchap… En fait, pour ce genre de considérations, le gouvernement se base sur des garanties un peu plus fortes, comme l'avis de l'ANSSI.
Mais Tchap fait partie des solutions retenues, ça tombe bien.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 2.
Et si Olvid (serveur) était troué de partout ?
Une partie. Matrix aurait pu servir pour le cas d'usage d'Olvid. Justement on parle de pourquoi un logiciel libre n'a pas été préféré. On peut boucler.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Psychofox (Mastodon) . Évalué à 4.
L'idée du protocole de Olvid, c'est que depuis le serveur tu n'ais pas moyen de déchiffrer le message.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 3.
Je répondai à propos de Tchap. Tiré d'un logiciel libre, on pourra en effet le savoir s'il était troué. Ce n'est pas la cas de la partie serveur d'Olvid.
Ce n'est pas le cas de Matrix ?
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par flan (site web personnel) . Évalué à 1.
Mais en fait, tu n'en sais rien, et moi non plus. Par contre, l'ANSSI a l'information, et a fait la recommandation en toute connaissance de cause.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 2.
L'ANSSI a-t-elle eu accès au code ou à des specs fonctionnelles ? Peut-elle certifier que c'est bien ce code qui tourne côté serveur ? A-t-elle un accès aux serveurs d'Olvid ?
Avec Tchap, l'Etat sait ce qu'il exécute.
Et en l'absence de certitude, et il y en a toujours, cela dépend du niveau, je préfère un logiciel libre.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par flan (site web personnel) . Évalué à 2.
En fait, l’ANSSI a émis un avis, et je pense qu’ils sont assez compétents pour savoir s’ils avaient les éléments nécessaires pour se prononcer.
Si tu penses mieux savoir qu’eux, pas de souci.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 2.
Merci de ne pas surinterpréter.
L'Anssi est certainement très compétente.
Les reviewers et contributeurs de libre, pas moins.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Glandos . Évalué à 6.
Alors j'ai trouvé le code des clients mobiles sur https://github.com/olvid-io mais pas le code macOS et Windows. Il est disponible ?
Et bien sûr, il manque la version la plus importante, vous l'aurez remarqué ;)
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Psychofox (Mastodon) . Évalué à 9.
Les versions desktop sont proprios.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par mahikeulbody . Évalué à 4.
Pas étonnant puisqu'elles ne sont pas incluses dans l'offre gratuite.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par aiolos . Évalué à 4.
Seule la partie serveur n'est pas open-source et celle-ci est entièrement optionnelle, Olvid est tout à fait utilisable sans le serveur qui n'a qu'un rôle d'annuaire. C'est cette partie qu'ils vendent aux administrations et entreprises.
Ce sont, pour moi, deux problématique orthogonales. La souveraineté numérique, c'est avant tout avoir la main sur les législations qui s'appliquent.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 3.
Dont acte. Mais je vois mal une telle organisation que l'Etat français se passer d'un annuaire à moins que c'est couplable avec un service d'annuaire tiers.
Le libre auto-hébergeable offre cela, bullshit national en moins. Cette souveraineté est en fait aussi, et surtout, un espionnage commercial et étatique bien de chez nous.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par aiolos . Évalué à 4.
On est d'accord. Mais il n'en reste pas moins que la partie libre est tout à fait utilisable sans, contrairement à Signal, par exemple. Et le protocole d'interrogation du serveur est ouvert et documenté, il est donc tout à fait possible d'en (faire) redévelopper un (et éventuellement le libérer) si on le veux.
Non, le libre auto-hébergeable ne l'offre pas. Seulement le libre auto-hébergé ou hébergé par un prestataire national (ou européen dans notre cas).
Cette affirmation relève, pour moi, d'une forme de complotisme.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Quinane . Évalué à 7.
Cette affirmation relève, pour moi, d'une forme de naïveté.
Le problème des Etats européens est le business de la donnée personnelle se fait essentiellement à l'extérieur, USA et, accessoirement Chine.
Ils aimeraient rapatrier cela chez eux pour éviter de se faire pomper les données utilisateurs sans en profiter.
Et cela pose un problème politique et de sécurité.
ePrivacy, les interdictions de Huawei, de TikTok et cie sur des moyens de l'état relève du protectionnisme, du matériel et de la donnée, mais aussi de leur sécurité. La souveraineté numérique n'est que le cache-sexe de ce protectionnisme. Ils aimeraient juste pouvoir espionner comme les grands et avoir des Gafam comme les grands.
La Suisse a adopté Threema, suisse, qu'utilise l'armée de la Confédération. C'est libre (AGPL 3) mais payant à l'installation si j'ai bien compris.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Psychofox (Mastodon) . Évalué à 9. Dernière modification le 30 novembre 2023 à 16:33.
Pour l'utilisateur final, threema a l'avantage de ne coûter que 5chf une seule fois contre Olvid 5€ par mois indéfiniment pour avoir toutes les fonctionnalités, une version libre téléchargeable sur f-droid, une application desktop pour linux libre (olvid desktop est proprio et uniquement macos/windows), et une appli web libre et que l'on peut auto-héberger.
Aussi pour certains ce sera important, les serveurs sont hébergés en Suisse. Threema disent que server-side ils ne peuvent pas savoir qui discute avec qui. Chez Olvid c'est du Amazon Web Services donc soumis au patriot act mais ils nous garantissent que Olvid est conçu pour ne pas avoir besoin de confiance en les serveurs.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Faya . Évalué à 10.
On peut avoir des idées relevant d'une forme de complotisme sans avoir tort pour autant.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Astaoth . Évalué à 6.
A noter que le code source du serveur de Signal est dispo sur Github pour qui veut jouer avec. Mais Signal a été très clair sur sa volonté de ne pas être fédéré. Est-ce que du coup le fait que la partie serveur soit publiée sur Github aide vraiment à savoir ce qui tourne sur leurs serveurs ? Mais d'un autre côté, vu les protocoles applicatifs utilisés et le fonctionnement des clients, est-ce nécessaire ?
Emacs le fait depuis 30 ans.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Et les clients desktop ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Glandos . Évalué à 5.
Apparemment, l'article du Point a raté le fait que Tchap est également recommandé : https://nitter.net/SebGarnault/status/1730297187928522957#m
Donc, OK, on rentre dans un peu plus de cohérence.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 02 décembre 2023 à 07:58.
J'ai évolué depuis ma 1re réaction hier en lisant ce journal ("c'est dégueulasse pour celleux qui s'emploient à déployer/améliorer Tchap dans l'administration depuis un moment") à "si c'est pour donner une visibilité commerciale à Olvid tout en continuant de soutenir Tchap alors ok"
PS : extrait du dernier message de Tchap - Dinum que j'ai reçu en tant qu'utilisateur éducation nationale de Tchap :
"Tchap continuera à être hébergé par le ministère de l'Intérieur, sur un Cloud souverain maîtrisé et opéré par des agents de l’État."
Et aussi, du 05/10/23 :
FAQ Tchap https://aide.tchap.beta.gouv.fr/fr/
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par antistress (site web personnel) . Évalué à 6. Dernière modification le 02 décembre 2023 à 09:39.
Par contre quelques infos sur Olvid données par sebsauvage qui font relativiser la pertinence pour le-la citoyen-ne de cette solution : https://sebsauvage.net/links/?V8JkHg
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par mahikeulbody . Évalué à 5.
Outre qu'on sait depuis longtemps que ça marche moins bien que de l'open source que plein de personnes peuvent auditer, c'est un peu contradictoire avec la communication d'Olvid :
Du coup, soit ils ne sont pas si sûr que ça de leur techno, soit ils veulent cacher une backdoor (jusqu'à hier je ne croyais pas en cette possibilité vu que je pensais que c'était du P2P), soit c'est du bullshit pour ne pas laisser aux organisations la possibilité d'héberger leur propre serveur (=> perte de revenus pour Olvid).
Ou plusieurs de ces choses à la fois.
PS. Bon, il y a certes le cas où un attaquant pourrait bloquer la circulation des messages, ou bien en envoyer une copie à des tiers complices qui pourront éventuellement les déchiffrer quand la techno le permettra. Mais du coup, la "sécurité assurée même en cas de serveur compromis" est du gros bullshit marketing.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Psychofox (Mastodon) . Évalué à 8.
C'est d'autant plus stupide que les fqdn des serveurs sont hardcodés dans le code source du client.
# Réponse d'aigri
Posté par gagbo (site web personnel) . Évalué à 9.
Ça me donne l’impression qu’ils (le renseignement Français) s’est fait sortir de la conversation avec les 5 eyes sur « Comment avoir des bonnes backdoors dans les messageries E2E ? » et qu’ils se « rattrapent » en faisant un « puisque c’est comme ça, on va forcer l’utilisation de notre truc, où on sait comment on pourrait espionner les gens. »
C’est (j’espère) faux, mais le timing et la solution franco-française qui sort un peu de nulle part donne un peu cette impression, surtout après avoir vu le Gouvernement pousser pour avoir des backdoors dans les messageries chiffrées E2E « pour la Sécurité Nationale »
[^] # Re: Réponse d'aigri
Posté par Astaoth . Évalué à 4.
Ca fait 3-4 ans au moins que Olvid existe. Depuis quelques années, on a pleins d'applis qui sortent, pour faire comme Signal (même protocole, mêmes buts affichés) mais avec un vague truc différent.
C'est exactement pour ca que je ne regarde plus les outils faits par des boites francaises depuis 2015 : trop de potentiel d’ingérence politique dedans.
Emacs le fait depuis 30 ans.
[^] # Re: Réponse d'aigri
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 30 novembre 2023 à 16:35.
J'imagine qu'ils ne se risqueraient pas à mettre des backdoors dans le code publié sur github, ce serait une balle tirée dans le pied, et seulement dans les clients disponibles sur le playstore.
[^] # Re: Réponse d'aigri
Posté par abriotde . Évalué à 1.
Et je préciserai, "C’est j’espère faux mais probablement pas.", Autrement dis, j'espère que je me trompe mais ma raison me dis que non.
[^] # Re: Réponse d'aigri
Posté par flan (site web personnel) . Évalué à 3.
Là, ils l'imposent au gouvernement. C'est donc qu'ils ont au contraire davantage confiance dans la résistance d'Olvid aux attaques d'autres pays (qu'ils aient ou non de bonnes raisons).
# Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Je ne comprends pas pourquoi le gouvernement ne respecte pas son propre référentiel de logiciels libres : le SILL qui recommande par exemple Element qui a le bon goût d'utiliser un protocole interopérable (matrix).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par Benjamin Henrion (site web personnel) . Évalué à 3.
"un protocole interopérable (matrix)"
Je reste sur IRC, implémentable avec un simple client telnet:
http://www.ordinateur.cc/r%C3%A9seaux/FTP-et-Telnet/66467.html
[^] # Re: Pas libre et pas interopérable
Posté par Psychofox (Mastodon) . Évalué à 8.
Ouais par contre IRC c'est hors sujet car niveau 0 question sécurité/chiffrement il me semble.
Sans compter le fait que pour avoir accès à des messages lorsque tu n'es pas en ligne, tu dois mettre en place un IRC bouncer.
[^] # Re: Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
IRCv3 propose du chiffrement, un historique et même une forme de norloges.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par Psychofox (Mastodon) . Évalué à 7.
Ce n'est pas du chiffrement pair à pair mais uniquement au niveau du transport client/serveur il me semble. Ça reste donc ras les pâquerettes niveau sécu/confidentialité.
[^] # Re: Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est dans la boite à idées : https://github.com/ircv3/ircv3-ideas/issues/29
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 8.
Depuis bientôt quatre ans.
J'aime bien IRC dans un esprit low-tech, mais comme pour XMPP, je comprends aisément qu'une administration préfère adopter une techno plus moderne qu'attendre que la commu bricole des features au sparadrap sur des dinosaures. Dénoncer les défauts de Matrix ou d'Olvid, il le faut bien entendu, mais comparons ce qui est comparable.
[^] # Re: Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Je ne conseille pas IRC non plus, mais je constate que le protocole n'est pas figé.
Le problème est plus l'explosion du nombre de protocoles que les soucis d'un protocole en particulier :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par abriotde . Évalué à 1.
Oui enfin, ça vaut une super-sécurité avec une backdoor… Dans tous les cas, seul un accès sur le serveur donne accès aux conversations.
[^] # Re: Pas libre et pas interopérable
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 01 décembre 2023 à 09:16.
C'est une affirmation très péremptoire. En réalité tout dépend de la surface d'attaque, de qui veut obtenir l'information.
[^] # Re: Pas libre et pas interopérable
Posté par Astaoth . Évalué à 2. Dernière modification le 02 décembre 2023 à 18:18.
Sauf si ton serveur ne traite pas les flux de données des utilisateurs, mais est plutôt comparable à un tracker de torrent, et que les connexions avec lui restent minimales.
Emacs le fait depuis 30 ans.
[^] # Re: Pas libre et pas interopérable
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 30 novembre 2023 à 11:47.
Je crois que le problème principal de Matrix comparé à du whatsapp/signal, c'est que les messages restent stockés sur le serveur plus ou moins ad vitam eternam. Ça fait longtemps que je n'ai pas testé signal, mais pour whatsapp l'historique ne semble pas rester sur le serveur car tu dois mettre en place un backup, pour les récupérer.
Bien qu'ils soient chiffrés s'il y a pwnage du serveur et dump des messages, il n'y a aucune garantie que les messages ne pourront être déchiffrés dans 5, 10, 15 ans. Et j'imagine que ça pourrait poser problèmes pour des discussions confidentielles entre membres du gouvernement.
J'ai testé Olvid en début d'année mais je ne me rappelle pas ce qu'il en est pour celui-ci.
J'aime bien Matrix comme substitut à IRC et Discord [2], mais pour de la messagerie pair à pair ou en petits groupes privés, mon favori actuel est SimpleX (mais je ne l'utilises qu'avec mes filles pour l'instant faute de convaincre un utilisateur de whatsapp à l'utiliser).
[1] sur un google drive, pas forcément mieux
[2] d'ailleurs il y a des gens qui utilisent Matrix pour des discussions en 1:1? En plusieurs années ça ne m'ait jamais arrivé.
[^] # Re: Pas libre et pas interopérable
Posté par GG (site web personnel) . Évalué à 6.
j'apprécie Matrix, parce que :
- Je peux choisir de m'inscrire sur un serveur avec au choix un numéro de téléphone, une adresse email, un nom, ou via des tiers. J'ai le choix.
- Je peux partager un identifiant pour être contacté
- Je peux installer mon propre client web
- Je peux installer mon propre serveur Matrix
Et comme je peux avoir les clients sur ordinateur, via un navigateur ou en dur, et sur smartphone, et que les messages seront synchronisés, ça me va.
J'en rêvais depuis longtemps.
Avec Yunohost il est même facile d'avoir son propre serveur Matrix et/ou son propre client web.
https://apps.yunohost.org/catalog?category=communication&search=matrix
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pas libre et pas interopérable
Posté par abriotde . Évalué à 1.
Tout a fait d'accord, j'ajouterai que Matrix c'est ce qui se fait de mieux au niveau sécurité mais aussi résilience (Attaques DDOS, pannes… ), entre autre car c'est décentralisé (Contrairement aux autres Watsapp, Olvid et Signal).
Pour moi, une messagerie doit aussi pouvoir être utilisé sur PC, sans aucun lien avec le téléphone ce qui n'est pas le cas de Watsapp, Olvid et Signal (J'aime bien Signal sinon).
Cependant le défaut de Matrix, c'est d'être plus complexe a gérer, un numéro de téléphone ne suffit pas à s'authentifier.
[^] # Re: Pas libre et pas interopérable
Posté par mahikeulbody . Évalué à 3.
Olvid est décentralisé, c'est du P2P (comme Syncthing, par exemple). Le serveur est optionnel pour les organisations qui souhaitent un annuaire centralisé des contacts.
Ça ne me paraît pas plus complexe à gérer pour le logiciel, c'est juste moins commode et transparent pour l'utilisateur (d'où le besoin d'un annuaire centralisé dans le cadre d'une organisation). Quoiqu'il en soit, pas besoin de n° de téléphone pour Olvid (idem Jami).
NB. En parlant de ça, si j'ai bien compris, le business model de Jami, c'est l'annuaire (et que l'annuaire : toutes les autres fonctionnalités sont gratuites et open source). Et le serveur est open source.
[^] # Re: Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Soit 99.9999% des organisations?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par mahikeulbody . Évalué à 2. Dernière modification le 01 décembre 2023 à 09:37.
Certes, mais les clients étant open source (Android et iOS, pas les autres) tu peux vérifier qu'ils n'échangent avec le serveur QUE les clés d'identification des contacts avec qui tu veux communiquer. Cela permet bien sûr au serveur de savoir avec qui tu veux potentiellement communiquer mais il ne verra aucun message passer par lui : ensuite c'est du P2P.
[^] # Re: Pas libre et pas interopérable
Posté par Matthieu Moy (site web personnel) . Évalué à 5. Dernière modification le 01 décembre 2023 à 10:37.
Une référence pour ça ?
La FAQ de Olvid dit explicitement le contraire :
https://www.olvid.io/faq/serveur-et-open-source/
=> Les messages transitent bien par le serveur.
Quoi qu'il en soit, serveur ou pas, les messages passent par tous les équipements réseaux (switch, routeurs, etc). Si j'ai bien compris ce que j'ai lu, le serveur Olvid n'a pas tellement plus d'information ou de vecteur d'attaque à disposition que le reste du réseau donc du point de vue sécurité on n'a pas besoin d'avoir confiance dans le serveur, mais on a besoin du serveur pour s'envoyer des messages.
[^] # Re: Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
C'est pratique pour le gouvernement : s'il veut couper les communications, il lui suffit d'éteindre le serveur.
Confiance totale !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par Psychofox (Mastodon) . Évalué à 4.
Le point essentiel, c'est que quand tu fais du p2p pur sans serveur (ce qui ne veut pas dire centralisé), les messages ne peuvent être reçus que quand l'émetteur et le destinataire sont connectés en même temps. Et pour beaucoup de monde, ce n'est pas acceptable.
[^] # Re: Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
D'accord, mais on a résolu ce problème au siècle dernier avec SMTP et de multiples serveurs hébergés par plusieurs fournisseurs.
Sur le fond, je ne comprends pas pourquoi on continue à produire des messageries (surtout privatrices, non interopérables) au lieu d'améliorer l'existant.
La sécurité n'est pas un argument pour tout casser.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 01 décembre 2023 à 14:23.
p2p != décentralisé != fédéré != centralisé
Ça ce n'est pas une architecture pair à pair ni sans serveur. L'email n'a pas été conçu pour de l'instantané et est pourri par le spam et les gafams. En pratique deltachat marche bien avec des serveurs coopérant bien et sans limite de messages, mais une personne m'a fait bien vite remarqué que "c'est de la merde tu ne reçois pas mes notifs aussi vite qu'avec whatsapp"
[^] # Re: Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 8. Dernière modification le 01 décembre 2023 à 14:42.
Je ne sais pas ce que veut dire "aussi vite que whatsapp", mais quand j'envoie une photo par mail à quelqu'un à côté de moi, ça arrive "tout de suite" :-)
Si tu n'aimes pas SMTP, il y a aussi XMPP et matrix.org.
Pourquoi continuer à inventer des protocoles à la noix qui font toujours la même chose?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par Psychofox (Mastodon) . Évalué à 2.
T'as un peu de mal à comprendre les comportements humains hein?
[^] # Re: Pas libre et pas interopérable
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Les humains… Je déteste ces types !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas libre et pas interopérable
Posté par GG (site web personnel) . Évalué à 3.
C'est nul!
Y a pas Mastodon ni XMPP. Apparemment rien de ce qui est basé sur ActivityPub.
Bon, en réalité, c'est pas mal comme schéma. Il faudrait "juste" le mettre à jour.
Merci
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pas libre et pas interopérable
Posté par mahikeulbody . Évalué à 2. Dernière modification le 01 décembre 2023 à 14:10.
message supprimé
[^] # Re: Pas libre et pas interopérable
Posté par mahikeulbody . Évalué à 2.
Si un des destinataires n'est pas connecté, le serveur ne pourra pas non plus lui envoyer le message. Le serveur ne présente un avantage que si l'émetteur s'est déconnecté entre-temps lorsque le destinataire se reconnecte. Cette séquence est bien sûr possible mais de plus en plus rare dans le monde ultra-connecté d'aujourd'hui. Et elle n'est préjudiciable que dans les cas où le délai de transmission est important et/ou si la connexion permanente des contacts n'est pas la norme. Je pense que ça laisse beaucoup de cas où une messagerie P2P est acceptable (avec l'avantage de ne pas dépendre d'un serveur qui peut "écouter" le trafic).
[^] # Re: Pas libre et pas interopérable
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 01 décembre 2023 à 15:20.
Le problème n'est pas la fréquence et/ou rareté de l'occurence, mais la perception côté utilisateur quand ça arrive.
Soit dit-en passant ce n'est pas le cas d'un gouvernement mais je connais des gens qui n'ont pas de forfait et utilise des cartes prépayées qu'ils ne rechargent qu'une fois toutes les n lunes et dépendent toujours des accès wifi.
[^] # Re: Pas libre et pas interopérable
Posté par mahikeulbody . Évalué à 2.
Au temps pour moi. Vu leur communication sur la "rupture technologique" je me suis convaincu que c'était du P2P.
Du coup, la performance technique de Jami est d'autant plus remarquable puisqu'il qu'il gère la problématique des devices déconnectés sans recours à un serveur mettant en attente les messages. Du vrai P2P, quoi.
[^] # Re: Pas libre et pas interopérable
Posté par Xanatos . Évalué à 2.
Cela m'avait échappé.
Jami est donc P2P, chiffré et libre ?
Toujours pas testé Element ou autre Matrix, mais les messages sont-ils récupérés à la connexion du client ?
[^] # Re: Pas libre et pas interopérable
Posté par mahikeulbody . Évalué à 4. Dernière modification le 02 décembre 2023 à 15:56.
Oui, ainsi que multi-devices et multi-profils (dans sa version gratuite, Olvid n'est pas multi-devices).
Avec Jami, oui, sous réserve bien sûr que l'émetteur soit connecté à ce moment-là (c'est du P2P : pas de serveur pour garder les messages en transit).
Et la chronologie est respectée lors de la récupération des messages grâce à un algorithme basé sur git.
[^] # Re: Pas libre et pas interopérable
Posté par abriotde . Évalué à 2.
Alors non, pas du tout. Olvid est closed source à 90% et même les appels crypté sont payant (5 euros par mois pour les particuliers le double pour les entreprises).
[^] # Re: Pas libre et pas interopérable
Posté par GG (site web personnel) . Évalué à 6.
J'apprécie au contraire d'avoir le choix, et de ne pas à avoir l'obligation de donner mon numéro de téléphone.
L'autre jour, j'ai été obligé de réinitialiser mon smartphone, celui avec Whatsapp. J'avais l'interface web ouverte et fonctionnelle. Dès que je me suis authentifié depuis le smartphone sur Whatsapp, la page web s'est rechargée, et pouf j'ai "tout" perdu : historiques et contacts avec lesquels j'avais causés.
Concernant les contacts, j'avais prévu le coup et j'ai un petit carnet d'adresse spécifique pour Whatsapp, parce que si on ne lui donne pas à manger un carnet d'adresse, on ne peut pas personnaliser les noms des contacts (ou voir leur nom).
Voilà pourquoi je préfère Matrix. Surtout qu'un numéro de téléphone mobile pour s'identifier, ça n'a rien de fiable. Et, c'est vraiment dommage que Whatsapp ne permette pas "facilement" comme sur Matrix d'avoir une synchronisation des contacts et des messages sans qu'on ait à faire quelque chose.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pas libre et pas interopérable
Posté par Astaoth . Évalué à 4.
Permets moi de douter, mais je peux me tromper :
- Si le serveur Matrix auprès duquel tu es enregistré se mange un DDOS, est-ce que tu peux toujours te connecter avec ton compte ?
- Qui te dit que Whatsapp/ Signal & co n'ont pas une archi distribuée au niveau mondial, limitant la possibilité de les DDOS ? Pareil pour les pannes, je serais surpris qu'ils aient une dépendance à une ressource non redondé.
- Est-ce que ton serveur Matrix stocke les messages de son côté de facon permanente ?
- Lorsque tu te connectes depuis un nouveau client sur Matrix, est-ce que tu as accès à l'ensemble des messages échangés avec ce compte par le passé ?
- As-tu un moyen de contrôler les différents clients connecté à ton compte avec Matrix ?
- As-tu une garantie que l'ensemble des serveurs Matrix avec lesquels tu peux être amené à communiquer fonctionnent de facon similaire, soit Synapse ou une autre implémentation de confiance, et non une implémentation proprio ou alors faisant tourner un module violant la vie privée des utilisateurs ?
- As-tu une garantie que le gestionnaire de ton serveur Matrix ne subit pas une pression quelconque extérieure, le contraignant à violer la vie privée de ses utilisateurs, sans possibilité de les en informer ? Si oui, est-ce le cas de toutes les structures ayant les inscriptions ouvertes à tous ?
- Est-ce que les gestionnaires de serveurs Matrix respectent le RGPD ? En a-t-on la garantie ?
- Petits bonus ayant un peu moins de rapport, est-ce que lorsqu'un utilisateur d'un serveur A joint un salon d'un serveur B, celui-ci est-il toujours entièrement répliqué du serveur B au serveur A ? Et est-ce Synapse est toujours un pachyderme trop lourd pour un raspi ?
Emacs le fait depuis 30 ans.
[^] # Re: Pas libre et pas interopérable
Posté par antistress (site web personnel) . Évalué à 4.
Comme dit plus haut, element et tchap c cousins voire frères
# Cible de l'outil ?
Posté par Vlobulle . Évalué à 4.
Je ne suis pas certain de comprendre : c'est un substitut à des messageries grand public (Whatapp, Messenger) ou à des messageries d'entreprise (Teams, Slack) ?
Je veux dire, c'est pas du tout les mêmes features, passé le cœur "chat textuel".
Entre les droits synchronisés par catégories de canaux avec l'AD de la boîte et GIPHY accessible en un clic, y'a tout de même un monde.
[^] # Re: Cible de l'outil ?
Posté par BAud (site web personnel) . Évalué à 8.
des idées de gény ?
[^] # Re: Cible de l'outil ?
Posté par Pol' uX (site web personnel) . Évalué à 2.
Comme ici ? (6m56)
Adhérer à l'April, ça vous tente ?
[^] # Re: Cible de l'outil ?
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 30 novembre 2023 à 11:25.
En l'occurence giphy est accessible en un clic sur MS Teams. Il y a pas mal de fonctionnalités redondantes dans les messageries privées et pros.
[^] # Re: Cible de l'outil ?
Posté par aiolos . Évalué à 4.
Et dans Slack aussi. Ça a même été un point majeur de frottement dans ma boite quand j'ai suggéré qu'on passe sur Mattermost à une époque :/
[^] # Re: Cible de l'outil ?
Posté par eingousef . Évalué à 3.
Si ça avait été l'inverse, si ça avait été mattermost qui intégrait giphy et pas slack, on t'aurait dit qu'une messagerie d'entreprise c'est fait pour bosser et pas pour s'échanger du kikoolol.
*splash!*
[^] # Re: Cible de l'outil ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4.
J'ajoute que dans pas mal de boîtes dont la mienne, on utilise aussi Discord, le truc kikoolol par excellence.
Des gens comme les devs de Fractal revendiquent une séparation entre l'UX de messagerie individuelle et celle des salons (la distinction barbecue/banquet). Mais de fait, aucune appli populaire de messagerie instantanée ne le fait. Pire, elles cherchent activement à confondre messagerie entre contacts et salons publics (qui eux-même ressemblent de plus en plus à un mur d'actu Twitter ou Facebook). Les choses pourraient être beaucoup plus simples que Tobias Bernard ne se l'imaginait.
[^] # Re: Cible de l'outil ?
Posté par Vlobulle . Évalué à 2.
Je ne connais pas l'outil, mais j'ai tout de même l'impression que cette stratégie oublie un critère important dans la ségrégation des conversations - le contexte.
Une conversation 1-1 avec un collègue, je veux qu'elle soit dans le même outil que la conversation d'équipe. Par "même outil", j'entends quelque chose dans la même interface, qui se lance en même temps, où je me logge avec le même compte. Compte qui m'est de toute façon fourni par la structure et sur lequel je n'ai pas ou peu de contrôle.
Et réciproquement, les conversations de groupes avec des amis, je veux qu'elles soient dans le même outil que celui où j'ai mes conversations 1-1 avec mes amis. Avec mon compte à moi, dont j'ai le contrôle.
Et pire, j'aime bien quand mes collègues et mes amis se mélangent que les conversations "pro" restent sur les canaux pro, et que les conversations "perso" tombent sur les canaux persos.
La métrique importante ne me semble pas le nombre d'interlocuteurs, mais le contexte. Le contexte implique des choses sur les nombres d'interlocuteurs (on aura plus de chats plus larges dans un contexte pro que dans un contexte perso), mais partir du dimensionnement pour en déduire la catégorie, c'est à mon sens une inversion des priorités.
# réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
https://nitter.net/reesmarc/status/1730230506615091265 et https://nitter.net/mer__edith/status/1730207726180204885 (réaction de la présidente de Signal Foundation, adressée à la Première ministre française Élisabeth Borne)
Notamment If you want to use a French product go for it! But don’t spread misinfo in the process. (si vous voulez utiliser un produit français, faites le. Mais ne désinformez pas au passage)
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par pamputt . Évalué à 5.
En tout cas, cette histoire de faiblesse supposée nous montre à quels point la majeure partie des journalistes travaillent. Ils reprennent quasiment tous sans recul la déclaration du gouvernement comme quoi Whats'app, Signal et consort souffrent de failles de sécurité. Dans les médias grand public, je n'ai trouvé que France Info qui modère un peu cette affirmation et citant notamment la réaction de Meredith Whittaker…
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par Donk . Évalué à 3.
Après, dans l'article du Point, nulle part il n'est écrit que Signal a des failles. Il est uniquement écrit que Signal n'est pas certifié par l'Anssi.
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
"Selon Elisabeth Borne, ces applications de messageries instantanées "ne sont pas dénuées de failles de sécurité et ne permettent donc pas d'assurer la sécurité des informations" échangées. "
( https://www.francetvinfo.fr/internet/securite-sur-internet/cyberattaques/cybersecurite-les-ministres-francais-invites-a-desinstaller-les-applications-de-messagerie-comme-whatsapp-signal-ou-telegram_6213804.html )
"Deux raisons sont invoquées par Matignon : d’une, les autres apps « ne sont pas dénuées de failles de sécurité », et de deux c’est « aussi une avancée vers une plus grande souveraineté technologique française »." ( https://www.01net.com/actualites/une-messagerie-securisee-pour-le-gouvernement-des-portes-derobees-pour-les-francais.html )
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par Donk . Évalué à 0.
Merci de confirmer mes dires
:D
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par abriotde . Évalué à 2. Dernière modification le 04 décembre 2023 à 04:17.
Désolé mais cela infirme tes dire. Puisqu'il est dis que les messagerie dont Signal "ne sont pas dénuées de failles". Tu dis juste le contraire.
PS: "pas dénués" = contiennent
C'est la double négation.
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par Donk . Évalué à 3.
Comme les journalistes, tu surinterprètes le texte de la circulaire en ajoutant des marques de messagerie là où il n'y en a pas.
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par Glandos . Évalué à 4.
La circulaire ne contient pas de marques, parce que c'est la coutume (voire la loi, je ne sais pas), de ne pas citer des marques en France.
Mais bon, euh, si la circulaire disait « Les grands constructeurs automobiles français ne vendent que des automobiles à trois roues », je pense que ET Renault ET Peugot ET Citroën pourraient dire qu'ils sont visés.
Les applications de messageries grands publics : WhatsApp, Telegram, Signal, et dans une moindre mesure en France, iMessage.
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par Donk . Évalué à 2.
Encore des supputations.
:/
Car peut-être qu'elle parlait d'ICQ, MSN, AIM, Tinder ou de TikTok
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par pamputt . Évalué à 3.
Toujours d'après le l'article de France Info donné par Benoit, il est question des « principales applications de messageries instantanées grand public ». Donc a priori, plutôt Signal, Whatsapp, etc. qu'ICQ ou AIM.
[^] # Re: réactions de Signal Foundation aux prétendues failles/faiblesses sur Signal
Posté par Psychofox (Mastodon) . Évalué à 3.
Je ne classerai Signal ni comme principale, ni comme grand publique.
# autre citation
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
https://nitter.net/emile_marzolf/status/1731961042354225471
(Fin 2021) "Le directeur de l'Anssi leur demandait de déployer l'appli Tchap à la place. Ou Signal, la moins mauvaise solution grand public."
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.