Je suis sensible (parfois anxieux) depuis de nombreuses années aux sujets de protection des données, de domination des GAFAM etc. Je savais que des solutions existaient, et j’en utilise déjà certaines, mais pas forcément les plus poussées ou les plus propres : utilisation de Mozilla et Qwant, QGIS plutôt qu’ARCGIS, Android plutôt qu’IOS, F-Android etc. Je suis notamment prêt à payer (par le don ou un achat classique) des services qui sont aujourd’hui anormalement gratuits.
Je cherche notamment depuis longtemps un service de messagerie instantanée pour discuter, partager des photos etc., avec dans l’ordre : ma famille, mes amis, mes collègues. Mais j’ai toujours pensé qu’il me faudrait convaincre tout mon entourage à me rejoindre et/ou qu’il fallait payer ou détenir un serveur privé.
Aujourd’hui j’ai découvert, à la suite, Framasoft puis les Chatons puis Matrix puis Element (belle journée ^^).
J’ai à peu près compris comment fonctionne Matrix (le protocole), et je crois que leur modèle et leur gestion des données est propre. Je suis intéressé par l’utilisation de Matrix (le serveur) dans Element (corrigez-moi si les termes sont faux), mais j’ai encore quelques doutes :
Element est un logiciel libre mais détenu par New Vector, une entreprise commerciale (contrairement à Matrix, une non-profit foundation), donc ils doivent gagner de l’argent.
Element semble lui-même gérer proprement les données, mais il en stocke sur des serveurs d’Amazon Web Services (https://element.io/privacy, §2.10). Cela concerne l’« admin server » et le « deployment server » (je ne sais pas exactement à quoi cela correspond). Or, bien sûr, Amazon a ses propres règles (https://aws.amazon.com/fr/privacy/). J’ai parcouru ces règles, mais, sans surprises, elles ne sont pas très digestes, et il me semble qu’ils font à peu près ce qu’ils veulent.
Plusieurs questions donc (désolé pour la longue intro) :
Quel est le modèle économique de New Vector ? Il repose sur les offres pour les pro (>50 utilisateurs de mémoire et si j’ai bien compris) ?
Est-ce que quand j’utilise mon compte Element :matrix.org, mes infos finissent bien sur un serveur d’Amazon ? Si oui, quelqu’un ici a-t-il la patience mais surtout les compétences pour lire les conditions d’Amazon Web Service ?
Si mes données sont bien stockées chez Amazon qui en font ce qu’ils veulent, alors quelle alternative voyez-vous ? Le paiement d’un serveur privé qui respecte les données (je n’ai pour l’instant pas cherché de serveur comme celui-ci sur Element) ? Un autre logiciel ? Element avec Matrix ont le gros avantage d’être gratuits et « jolis » donc plus facile de convaincre autour de moi
Déjà félicitations pour ça, et je trouve que le terme « anormalement gratuit » est superbement adapté !
C’est absolument vrai ! Element est à la fois le nom du logiciel et de l’entreprise derrière ce logiciel. Element s’appelait auparavant New Vector (et il me semble encore auparavant simplement Vector). Je crois qu’on a fini de changer de noms et qu’on va rester Element un moment
Avant de rentrer dans les privacy policies, je pense qu’il est important de lever certaines ambiguités.
Matrix et Element
Matrix est un protocole ouvert jusque dans toutes ses ramifications, maintenu par la Fondation Matrix. C’est un protocole au même sens que SMTP pour le mail, ou HTTP pour le web. Dans la page dédiée à sa mission (lien en Anglais), la Fondation dit explicitement:
Patent encumbered IP is strictly prohibited from being added to the standard.
Making the specification rely on non-standard/unspecified behaviour of other systems or actors (such as SaaS services, even open-sourced, not governed by a standard protocol) shall not be accepted, either.
La Fondation Matrix a seulement deux « produits » (entre guillemets puisqu’elle ne vend rien) :
le protocole lui même, qui grandit de manière organique à mesure que différents acteurs viennent l’enrichir avec l’approbation de l’équipe en charge de sa maintenance
et le serveur matrix.org qui sert principalement à permettre aux gens d’essayer Matrix facilement.
S’il fallait déployer son propre serveur avant de pouvoir essayer la moindre appli, le succès serait bien moindre ! Mais on n’est pas intéressés par devenir un gros point de centralisation du réseau, on ne veut pas être le « gmail de matrix » et on travaille sur des manières d’améliorer la décentralisation (plus de détails plus bas)
Element est une société commerciale qui a été lancée par les créateurs du protocole Matrix: Matthew Hodgson et Amandine Le Pape. Le but est bien sûr de dégager du profit pour permettre à plusieurs personnes de travailler à temps plein sur des produits open source autour de Matrix. Elle dispose d’une offre commerciale de services autour de Matrix appelée Element Matrix Services (EMS).
Le lien entre la Fondation Matrix et Element a historiquement été assez fort, puisqu’Element était (et est encore aujourd’hui) le poumon économique de Matrix: l’essentiel des activités de la Fondation est financé par Element. C’est un modèle qui a émergé un peu par nécessité et dont Element et la Fondation Matrix cherchent à s’éloigner: on veut décentraliser les décentralisateurs! Pour ce faire, on a lancé le programme d’adhésion à la Fondation Matrix (lien en Anglais).
Une des facettes de ce lien fort est un contrat de service. La Fondation Matrix n’ayant pas d’employés, elle s’est historiquement appuyée sur Element (le seul fournisseur de services Matrix lors de l’émergence de la fondation) via un contrat de services pour faire tourner le serveur matrix.org. Element s’occupe du déploiement et de l’administration du serveur Matrix.org, mais elle ne le fait pas sur son infrastructure commerciale ! En ce sens, il est plus pertinent de lire la Privacy Notice de Matrix.org (lien en Anglais) que celle d’Element quand il s’agit du serveur de Matrix.org
Je ne suis pas impliqué dans l’administration du serveur matrix.org lui-même, mais de mémoire le serveur Matrix (Synapse) et sa base de données (Postgres) sont hébergées chez Mythic Beasts. Il me semble que la seule partie hébergée chez AWS pour le serveur Matrix.org est le sliding-sync proxy, une extension du serveur par laquelle tu ne passes que si tu utilises le client expérimental Element X à ce jour (idem ici, je peux m’étendre sur le sujet si ça intéresse !)
La sécurité absolue n’existe pas
Je suis moi même très sensible aux questions d’intersection entre vie privée et outils numériques. Je suis parti de Gmail pour aller héberger mes mails chez Gandi puis chez Fastmail. J’héberge une instance Nextcloud que je partage avec ma famille. J’héberge bien sûr ma propre instance Matrix. J’ai poussé un peu dans la direction des applications hors-ligne (lien en Anglais) (hélas sans susciter les passions) pour les environnements de bureau Linux.
Un aspect que je vois trop souvent négligé dans l’activisme pour la vie privée est le modèle de menace. Il existe autant de modèles de menaces et de méthodologies pour les établir qu’il existe d’auditeurs, mais le principe reste toujours le même. Il s’agit d’établir:
Quelles sont les choses que je veux protéger (mes relevés de compte ? mes photos ?)
Comment est-il possible d’accéder à ces choses (en bruteforçant mon mot de passe ? en s’inflitrant dans le data-center pour extraire le disque du serveur ?)
Quels sont les moyens à mettre en œuvre pour accéder à ces choses (regarder par dessus mon épaule quand je tape mon code ? monter un commando pour passer la sécurité du data-center et extraire le disque ? soudoyer l’administrateur de mon CHATONS ?)
Qui a les moyens de les mettre en œuvre (n’importe qui de mal intentionné ? une entreprise concurrente ? un ennemi politique ? un état ?)
La base d’un modèle de menace, c’est de se rappeler une chose essentielle : rien n’est impénétrable pour toujours, avec assez de moyens il est toujours possible de casser la sécurité. Le modèle de menace sert à identifier les menaces réelles auxquelles on est soumis, à les prioriser, et à prendre les mesures adéquates pour y répondre. La sécurité est souvent une histoire de « meilleur compromis ».
Amazon
Je pense que ce n’est pas sur la plateforme de Framasoft qu’on a besoin de faire de la sensibilisation au danger qu’Amazon peut représenter ! Il y a plein de bonnes raisons d’avoir peur d’Amazon, et il y a aussi quelques mauvaises raisons.
Confidentialité
Si je reprends tes inquiétudes, tu demandes si tes infos finissent bien sur un serveur d’Amazon, et tu t’inquiètes de savoir ce qu’il en advient. C’est une inquiétude légitime, et je trouve ta démarche interrogatrice plutôt qu’accusatrice très louable.
La réponse concrète à cette question c’est : oui, des données peuvent atterrir chez Amazon (en l’occurrence seulement si tu utilises sliding-sync, mais pour l’exercice de pensée considérons que tout atterrit chez Amazon). De quelles données parle-t-ton, et que peut-il en advenir ?
Les conversations qui sont dans des salons publics sont rarement chiffrées, parce que ça n’a pas de sens en premier lieu : pourquoi chiffrer quelque chose qui est public de toutes façons ? Ces données sont donc stockées en clair chez Amazon quand un utilisateur du serveur matrix.org a rejoint une conversation publique non-chiffrée.
Les conversations privées sont chiffrées de bout en bout. En ce sens, le contenu des messages lui-même est chiffré, et seuls toi et tes correspondants peuvent les déchiffrer. Ni Amazon, ni la fondation Matrix.org ni personne d’autre ne peuvent déchiffrer ces messages. Donc Amazon ne voit que du « bruit », et pas le contenu des messages. Par transparence je dois souligner que je parle bien du contenu des messages, mais que les métadonnées ne sont pas chiffrées (ici aussi je peux m’étendre sur pourquoi ce n’est souvent pas un problème, et quand ça peut le devenir si ça intéresse).
Data Privacy. You may specify the AWS regions in which Your Content will be stored. You consent to the storage of Your Content in, and transfer of Your Content into, the AWS regions you select. We will not access or use Your Content except as necessary to maintain or provide the Services, or as necessary to comply with the law or a binding order of a governmental body. We will not (a) disclose Your Content to any government or third party or (b) move Your Content from the AWS regions selected by you; except in each case as necessary to comply with the law or a binding order of a governmental body. Unless it would violate the law or a binding order of a governmental body, we will give you notice of any legal requirement or order referred to in this Section 1.4. We will only use your Account Information in accordance with the Privacy Notice, and you consent to such usage. The Privacy Notice does not apply to Your Content.
Concrètement : nous sommes responsables des données, et Amazon n’y met pas son nez. Même si du contenu illégal était posté sur un salon public de matrix.org et que c’était signalé à Amazon, Amazon doit se rapprocher de nous pour supprimer le contenu et n’a pas le droit de le faire elle-même.
Centralisation
Tout ceci étant dit, il existe une menace réelle sur le fait d’utiliser Amazon pour fournir ses services, et les personnes qui suivent Framasoft y sont assez sensibles : la centralisation. Les sources sont diverses et les chiffres varient, mais Amazon sert de socle à une très (trop) grande partie des sites et services exposés sur Internet. C’est particulièrement flagrant lorsqu’un datacenter Amazon a une avarie : une partie du web tombe.
Une des grandes forces de Matrix, c’est que les salons sont répliqués sur tous les serveurs participants (lien en Anglais). Ça permet une plus grande résilience si un des nœuds tombe. Dans notre exercice de pensée qui ne correspond pas à la réalité, on imagine que les données de Matrix.org sont chez Amazon. Alors si Amazon tombe, que se passe-t-il ? Les utilisateurs de Matrix.org sont impactés, mais tous les autres utilisateurs ne sont pas impactés : ils peuvent continuer à converser entre eux, leurs serveurs se parlent tranquillement, et Matrix.org rattrapera sont retard lorsque le service reviendra en ligne.
Résilience
Le meilleur moyen de rendre Matrix plus résilient aujourd’hui, c’est d’augmenter le nombre d’instances indépendantes et de réduire le nombre de personnes qui dépendent du serveur Matrix.org.
Or pour augmenter le nombre d’instances indépendantes:
il faut que les gens puissent essayer Matrix facilement (on ne choisit pas un serveur avant de savoir pourquoi on devrait choisir un serveur) donc il faut que Matrix.org existe. Premier paradoxe!
il faut que Matrix soit efficace et agréable à utiliser, donc il faut à la fois passer du temps à améliorer les produits et passer du temps à s’assurer que le service tourne correctement… avec une main d’œuvre limitée puisque les journées ne font que 24h. Second paradoxe!
La réponse au premier paradoxe que nous avons choisie est de faire de Matrix.org la porte d’entrée principale du projet. La décentralisation et la fédération sont des sujets complexes, et il est important d’être respectueux du temps et des resources dont disposent les non-experts. Exclure le grand public de Matrix parce que ces concepts ne sont pas simples à appréhender hors des sphères techno-centriques ne nous semble pas acceptable.
La réponse au second paradoxe c’est que nous avons décidé de nous appuyer sur Amazon car ça nous fait gagner du temps de maintenance. Tout le temps qu’on ne passe pas à se battre contre des serveurs, c’est du temps qu’on passe là où on apporte le plus de valeur : à travailler sur le protocole lui-même, et sur l’offre de clients autour de lui.
En attendant
Si tu n’es pas à l’aise à l’idée d’avoir tes données chez Amazon, c’est un sentiment que je comprends et partage ! Je peux te recommander l’intégrateur etke.cc (lien en Anglais) qui pratique des tarifs assez bas et qui est bien impliqué dans notre communauté.
J’espère que je réponds à tes inquiétudes, et surtout que ça te permet de faire des choix de manière éclairée ! Encore une fois merci pour ta démarche curieuse et constructive, et n’hésite pas si tu as d’autres questions ou que j’ai oublié de répondre à certaines d’entre elles.
Un grand merci thib pour cette réponse très didactique et informative.
Du coup j’ai une question concernant sliding-sync proxy. Une fois qu’Element X sera devenu Element (je suppose que ce sera le cas, et non pas un nouveau logiciel comme le passage de Riot à Element, en passant part Riot X), ce proxy restera-t-il chez Amazon ? Ou alors est-ce temporaire tant que Element X est en développement ?
Ce proxy sera-t-il toujours indépendant de Synapse (ou dendrite) ? Donc si on veut héberger son serveur Matrix, il faudra 2 serveurs ? Ou alors sur du plus long terme les 2 seront unifiés ?
Effectivement le but c’est de remplacer Element par Element X
Element X c’est le nom du projet global qui sert à unifier les Elements. C’est un peu classe dit comme ça, mais plus concrètement on a aujourd’hui Element Web/Desktop, Element iOS et Element Android.
Chaque Element a sa propre manière de faire les appels aux API des serveurs: la même chose a été developpée 3 fois. Au delà d’être un gaspillage de ressources initial, c’est aussi beaucoup plus lourd à maintenir. Si on trouve un bug il faut revoir les 3 implémentations, et c’est donc très gourmand à maintenir.
Element a lancé les efforts autour de matrix-rust-sdk, un SDK écrit en Rust qui sert à implémenter ces appels client->serveur une bonne fois pour toute, en Rust. Un très gros contributeur à ce SDK travaille sur Fractal, le client Matrix pour GNOME (un gros merci à lui d’ailleurs !)
Element X iOS, Element X Android et à terme Element X Web vont tous se mettre à utiliser le Rust SDK. De la sorte on a le même moteur sur trois applis différentes. S’il y a un défaut de conception dans le moteur, on le corrige une seule fois et ça règle les problèmes partout.
En fait ce proxy est plutôt utile tant qu’on développe la fonctionnalité de sliding sync. C’est plus simple d’avoir un morceau de code indépendant que tu peux redéployer à volonté, plutôt que de devoir emboîter le pas du rythme de développement du serveur principal. Sliding sync est une fonctionnalité assez complexe mais aussi très attendue pour Matrix, donc le développement se fait à très haute vélocité.
Je ne fais pas partie de l’équipe de maintenance de Synapse, mais une fois que cette fonctionnalité aura rejoint la spécification stable je pense qu’elle devrait intégrer synapse. D’ailleurs, le mainteneur de Conduit, un homeserver communautaire écrit en Rust, a déjà implémenté la fonctionnalité directement dans son projet !
La seule raison pour laquelle le sliding sync proxy a été déployé sur AWS c’est parce que c’est très facile à mettre à l’échelle. Puisque c’est une fonctionnalité expérimentale on a très peu de recul sur sa capacité à encaisser les requêtes: le déployer sur AWS c’est se laisser la liberté de pouvoir jeter plus de puissance au problème le temps de le résoudre proprement.
À terme le proxy devrait disparaître à mon sens, mais il ne dépendra que d’un homeserver normal, que ce soit Synapse, Dendrite ou encore Conduit.
Pas forcément, voir le point plus haut sur Conduit
Rien n’interdit également d’avoir une seule et même machine physique (ou même un VPS) et d’avoir deux services qui tournent dessus (ton homeserver et ton sliding-sync proxy), idéalement derrière un reverse-proxy. J’ai justement fait une vidéo pour montrer comment faire ça avec docker compose!
Toujours content de répondre aux questions à propos de Matrix!
Merci beaucoup @thib je ne m’attendais pas à une réponse si complète, et aux infos bonus avec !
Je pensais effectivement aux métadonnées, plutôt qu’aux conversations elles-mêmes qui sont cryptées de bout en bout.
Si je comprends bien, si je n’utilise pas Element X (ce que je ne compte pas faire en tant que néophyte), mes infos et conversations seront hébergés chez Mythic Beasts. Donc, à la limite, c’est Mythic Beasts qui pourrait avoir mes métadonnées. C’est bien ça ?
Je ne me suis pas renseigné sur Mythic Beasts et sur leur politique vis-a-vis des données qu’ils hébergent (je ne sais pas si c’est le bon terme). Mais bon de toute façon, j’imagine que ça peut difficilement être pire qu’Amazon, et puis il faut bien que les données soient quelque part physiquement (sauf à avoir mon propre serveur, mais ça me semble insurmontable sans connaissances en réseau). J’irai peut-être fouiller quand j’aurai un moment mais en attendant ça me semble ok
.