Le DMA et le casse-tête de l'interopérabilité des messageries

Le DMA et le casse-tête de l’interopérabilité des messageries

Téléphone maisons

Avatar de l'auteur
Jean-Marc Manach

Publié dans

Droit

31/03/2022 23 minutes
27

Le DMA et le casse-tête de l'interopérabilité des messageries

Le Digital Market Act prévoit d'obliger les principales plateformes de messagerie à l'interopérabilité. De nombreux experts et professionnels de la sécurité y voient une usine à gaz insurmontable. Les co-fondateurs de Matrix, un protocole promouvant précisément l'interopérabilité, y voient du pain béni pour le futur des messageries.

« Les législateurs de l’UE ont convenu que les plus grands services de messagerie (tels que WhatsApp, Facebook Messenger ou iMessage) devront s’ouvrir et être interopérables avec les plus petites plateformes de messagerie, si elles en font la demande », lisait-on dans les négociations autour du Digital Market Act, que les négociateurs du Parlement européen et du Conseil ont validé la semaine passée :

« Les utilisateurs des petites ou grandes plateformes pourront alors échanger des messages, envoyer des fichiers ou passer des appels vidéo sur toutes les applications de messagerie, ce qui leur donnera un choix plus large. »

Ne seront concernées que les sociétés « dont la capitalisation boursière atteint au moins 75 milliards d’euros ou dont le chiffre d’affaires annuel dépasse les 7,5 milliards d’euros ».

Si Signal et Telegram seront donc a priori épargnés, un telle interopérabilité n'est pas sans poser problème : comment faire, par exemple, pour rendre interopérables des messageries chiffrées de bout-en-bout (E2EE) telles WhatsApp avec celles qui ne le sont qu'en option, comme Facebook Messenger ?

Andreas Schwab, rapporteur du Parlement européen sur le dossier, expliquait à TechCrunch que « cela viendra, mais il faudra aussi que ce soit sécurisé. Si les autorités de régulation des télécommunications déclarent qu'il n'est pas possible de proposer des discussions de groupe chiffrées de bout en bout dans les neuf mois à venir, nous le ferons dès que cela sera possible, cela ne fait aucun doute. »

Selon lui, les services de messagerie soumis à l'exigence d'interopérabilité devront ouvrir leurs API aux concurrents afin de fournir une messagerie interopérable pour les fonctionnalités de base. L'exigence étant intentionnellement asymétrique, cela signifie que les services de messagerie plus petits qui ne relèvent pas du DMA ne sont pas tenus de s'ouvrir aux gardiens (« gatekeepers »), mais peuvent eux-mêmes se connecter aux Big Tech :

« Les premières fonctionnalités de messagerie de base seront les messages d'utilisateur à utilisateur, les appels vidéo et vocaux, ainsi que le transfert de fichiers de base (photos, vidéos), puis au fil du temps, d'autres fonctionnalités telles que les discussions de groupe viendront. Tout doit être chiffré de bout en bout. »

En attendant la version définitive du texte, on se référera aux projets d'interopérabilité du DMA qu'avait tweeté Benedict :

« Permettre à tout fournisseur d'[apps de messagerie], à sa demande et gratuitement, de s'interconnecter avec les [apps de messagerie] de l'opérateur. L'interconnexion est assurée dans des conditions et une qualité objectivement identiques à celles qui sont disponibles ou utilisées par l'opérateur, ses filiales ou ses partenaires, permettant ainsi une interaction fonctionnelle avec ces services, tout en garantissant un haut niveau de sécurité et de protection des données personnelles. »

Le DMA endommagera-t-il le chiffrement de WhatsApp ?

« De grands noms de la sécurité Internet ont vivement critiqué la nouvelle législation DMA », écrit toutefois The Verge, arguant que « les nouvelles règles de l'UE endommageront le chiffrement de WhatsApp » :

« Le consensus parmi les cryptographes est qu'il sera difficile, voire impossible, de maintenir le chiffrement entre les applications, avec des implications potentiellement énormes pour les utilisateurs. »

Si Signal est suffisamment petit pour ne pas être affecté par le DMA, le texte concernera très certainement WhatsApp, qui utilise le protocole Signal et appartient à Meta/Facebook. Le résultat pourrait être qu'une partie, sinon la totalité, du chiffrement de bout en bout de WhatsApp risque d'être affaiblie, voire supprimée, privant un milliard d'utilisateurs des protections de la messagerie sécurisée.

Il n'y aurait en effet aucun moyen de fusionner différentes formes de chiffrement sur des applications avec des caractéristiques de conception différentes, explique Steven Bellovin, chercheur renommé en sécurité Internet et ancien technologue en chef à la Federal Trade Commission :

« Essayer de réconcilier deux architectures cryptographiques différentes est tout simplement impossible ; un côté ou l'autre devra faire des changements majeurs. Une conception qui ne fonctionne que lorsque les deux parties sont en ligne sera très différente de celle qui fonctionne avec des messages stockés... Comment faites-vous pour que ces deux systèmes interagissent ? »

Une autre approche suggérée par le DMA, mais tout aussi insatisfaisante pour les défenseurs de la vie privée, consisterait à déchiffrer puis re-chiffrer les messages envoyés entre plates-formes utilisant des protocoles de chiffrement incompatibles, brisant le chiffrement de bout en bout et créant dès lors un point de vulnérabilité.

Alec Muffett, un expert en sécurité Internet et ancien ingénieur de Facebook qui a récemment aidé Twitter à être accessible via Tor, explique à The Verge que ce serait une erreur de penser qu'Apple, Google, Facebook et d'autres entreprises technologiques fabriquent des produits identiques et interchangeables qui pourraient facilement être combinés :

« Si vous entrez dans un McDonald's et dites : "Afin de briser les monopoles des entreprises, j'exige que vous incluiez un plateau de sushis d'un autre restaurant avec ma commande", ils vous fixeraient à juste titre. Que se passe-t-il lorsque les sushis demandés arrivent par coursier chez McDonald's depuis le restaurant de sushis ostensiblement demandé ? McDonald's peut-il et doit-il servir ces sushis au client ? Le coursier a-t-il respecté les mesures d'hygiène et de sécurité ? »

Actuellement, chaque service de messagerie assume la responsabilité de sa propre sécurité. Muffett et d'autres font valoir qu'en exigeant l'interopérabilité, les utilisateurs d'un service seront exposés à des vulnérabilités qui pourraient avoir été introduites par d'autres. « En fin de compte, la sécurité globale n'est aussi solide que le maillon le plus faible », résume The Verge.

Un autre sujet de préoccupation soulevé par les experts en sécurité est le problème posé par les identifiants associés aux messageries. « Comment dites-vous à votre téléphone à qui vous voulez parler, et comment le téléphone trouve-t-il cette personne? », explique Alex Stamos, directeur de l'Observatoire Internet de Stanford et ancien responsable de la sécurité chez Facebook :

« Il n'y a aucun moyen d'autoriser le chiffrement de bout en bout sans faire confiance à chaque fournisseur pour gérer la gestion de l'identité... Si l'objectif est que tous les systèmes de messagerie traitent les utilisateurs exactement de la même manière, alors c'est un cauchemar en termes de sécurité et de confidentialité. »

Sur Twitter, Stamos se montre encore plus pessimiste : « comme de nombreuses personnes l'ont souligné, fédérer un espace de noms chiffré de bout en bout à travers de nombreux fournisseurs est un défi technique très ouvert » :

« Un cynique pourrait dire qu'il s'agit d'une façon d'interdire efficacement l'E2EE tout en le présentant comme une mesure antitrust contre la technologie. »

Réagissant lui aussi sur Twitter, Steven Bellovin précise son propos : « Exemple : Twitter me connaît sous le nom de @SteveBellovin. Apple me connaît par mon AppleID, une adresse électronique personnelle. Signal me connaît par mon numéro de téléphone. Google me connaît par l'adresse électronique officielle de mon université. Facebook ne me connaît pas... » :

« Vous recevez un message de StevenBellovin, utilisateur de WhatsApp. Qui est-ce ? C'est moi ? Un agresseur ? Ou quelqu'un d'autre portant le même nom ? (Pour autant que je sache, il n'y a pas d'autres Steven Bellovin sur la planète ; mon nom de famille est si rare. Je connais cependant d'autres collisions de noms dans la famille).
NB : C'est le plus gros problème de E2EE dans Zoom.
»

Ordonner aux médecins de guérir le cancer ?

Dans un autre article intitulé « Trois façons dont l'Union européenne pourrait ruiner WhatsApp », Casey Newton, qui suit l'intersection de la Silicon Valley et de la démocratie pour The Verge, estime même qu' « il n'est pas exagéré de dire que l'avenir du chiffrement de bout en bout est en jeu ».

Pour Alex Stamos, « rédiger une loi ordonnant de "permettre une interopérabilité totale sans créer de risques pour la vie privée ou la sécurité" revient à ordonner aux médecins de guérir le cancer ».

Interrogé à ce sujet, Will Cathcart, le chef de WhatsApp, répond à Casey Newton : « je me demande si cela va briser ou porter gravement atteinte à la vie privée, si cela va casser une grande partie du travail de sécurité que nous avons fait et dont nous sommes particulièrement fiers, et si cela va réellement conduire à plus d'innovation et de compétitivité ».

Il estime qu'une telle interopérabilité irait à l'encontre des efforts entrepris par les messageries pour lutter contre le spam, la désinformation et les discours de haine, ainsi que la confidentialité.

La nature centralisée de WhatsApp lui permet en effet d'identifier et de supprimer le spam avant qu'il n'atteigne ses utilisateurs, et il supprime des millions de comptes chaque mois pour s'y être essayé. Les services tiers qui se connectent à WhatsApp peuvent ne pas être aussi agressifs, voire plus tolérants.

WhatsApp a aussi adopté des limites de transfert pour réduire la propagation virale des messages, suite à des campagnes de désinformation ou d'appels à la haine. Mais les services tiers peuvent ne pas être tenus de le faire. Seraient-ils autorisés à utiliser l'API ? WhatsApp serait-il obligé de les laisser faire ?

WhatsApp peut garantir aux utilisateurs un chiffrement de bout en bout et que ses nouveaux messages éphémères sont effectivement supprimés, car il peut voir toute la chaîne de communication. Cependant, il ne pourra pas voir ce que les applications tierces font avec les messages après leur livraison, ce qui fait craindre que les utilisateurs ne puissent être aussi protégés.

Les experts interrogés par Cathcart suggèrent que ceux ayant préparé le DMA n'auraient semble-t-il pas consulté les experts en sécurité, cryptographie, et protection de la vie privée.

Casey Newton se demande également ce que l'interopérabilité fera réellement pour rendre le marché de la messagerie plus compétitif :

« Le courrier électronique est une norme ouverte et interopérable et ce depuis des décennies ; mais aujourd'hui, Apple, Google et Microsoft détiennent environ 90 % du marché. Pendant ce temps, le marché des applications de messagerie est beaucoup plus dynamique, même sans interopérabilité : il comprend des applications de Meta, Telegram, Signal, Snap et autres. »

Cela s'explique en partie parce que les entreprises peuvent ajouter des fonctionnalités plus rapidement et qu'elles n'ont pas à créer d'API ouvertes pour les prendre en charge. Snap avait ainsi déclaré il y a deux ans que « l'interopérabilité peut très bien fonctionner dans le cas de services standardisés, de type commodité, comme la téléphonie ou la banque de détail. En revanche, rien ne permet de créer une approche unique et standardisée dans cet espace » :

« Il serait illusoire de penser qu'une autorité de la concurrence puisse imposer l'interopérabilité à l'ensemble du secteur, car cela aurait pour effet d'affaiblir le marché et d'empêcher les nouveaux arrivants d'innover. Une telle approche créerait une lourde charge technologique et administrative et nuirait à l'innovation sur le marché. »

Pour Casey Newton, « la pression simultanée de l'Europe pour une concurrence accrue et une confidentialité maximale des utilisateurs semble être un cas clair où une main ne sait pas ce que fait l'autre. Le fait est que presque personne que j'ai lue ou à qui j'ai parlé ne pense que vous pouvez faire les deux, du moins pas de la manière proposée par l'UE ». Et de conclure :

« La réglementation consiste toujours à tenter de résoudre des problèmes anciens sans en créer trop de nouveaux dans le processus. Mais pour y parvenir, il faut acquérir une connaissance technique approfondie des questions en jeu et en discuter publiquement avec des experts. Jusqu'à présent, l'Union européenne n'a pas fait preuve de beaucoup d'efforts dans ces deux domaines. Pour que la messagerie chiffrée ait un véritable avenir, il va falloir que cela change, et vite. »

Le meilleur résultat possible imaginable pour l'internet ouvert

Tous les experts en sécurité n'ont pas réagi aussi négativement au DMA. Matthew Hodgson, cofondateur de Matrix, un protocole standard ouvert et léger pour la communication en temps réel et favorisant précisément l'interopérabilité et la décentralisation, reconnaît les difficultés liées à l'interopérabilité obligatoire.

Mais il estime qu'elles seront compensées par les avantages qui découleront de la remise en question de l'insistance des géants de la technologie sur les écosystèmes de messagerie fermés.

Sur le blog de Matrix, Hodgson qualifie le DMA de « législation absolument historique, où l'UE a décidé de ne pas démanteler les gardiens afin de créer un marché plus compétitif – mais plutôt de "les ouvrir" » :

« C'est une incroyablement bonne nouvelle pour l'Internet ouvert, car il oblige les contrôleurs d'accès à fournir des API ouvertes pour leurs services de communication. En d'autres termes : les géants de la technologie ne pourront plus enfermer arbitrairement leurs utilisateurs dans leurs jardins clos ; ils seront légalement tenus d'exposer les API à d'autres services. »

Bien que les résultats officiels de l'accord n'aient pas encore été publiés, il espère que le DMA exigera que :

  • Les « gatekeepers » fournissent des API ouvertes et documentées à leurs services, sur demande, afin de faciliter l'interopérabilité (c'est-à-dire pour que d'autres services puissent communiquer avec leurs utilisateurs).
  • Ces API conservent le même niveau de chiffrement de bout en bout (le cas échéant) pour les utilisateurs distants que celui disponible pour les utilisateurs locaux.
  • Cela s'applique à la messagerie 1:1 et au transfert de fichiers à court terme, et à la messagerie de groupe, au transfert de fichiers, à la VoIP 1:1 et à la VoIP de groupe à plus long terme.

« Dans le passé, les gardiens de l'accès à l'information ont rejeté l'effort d'[interopérabilité] comme n'en valant pas la peine », a déclaré Hodgson à The Verge. « Après tout, la ligne de conduite par défaut est de construire un jardin clos, et après en avoir construit un, la tentation est d'essayer de piéger autant d'utilisateurs que possible » :

« C'est le meilleur résultat possible imaginable pour l'internet ouvert. Plus jamais une grande entreprise technologique ne pourra retenir ses utilisateurs en otage dans un jardin clos, ni fermer arbitrairement ou saboter ses API. »

Cherchant à répondre aux « nombreuses voix très expérimentées [qui] ont crié que l'interopérabilité obligatoire via des API ouvertes va irrévocablement saper les messagers chiffrés de bout en bout comme WhatsApp », il estime qu'elles émaneraient « principalement d'une préoccupation selon laquelle le DMA essaie en quelque sorte de subvertir le chiffrement de bout en bout, bien qu'il exige explicitement que les API doivent exposer le même niveau de sécurité, y compris de bout en bout ».

Il propose des solutions en ce sens :

  • « Exécuter le pont dans un endroit relativement sûr – par exemple le client de l'utilisateur. Il y a déjà beaucoup de travail en cours dans Matrix pour exécuter des ponts côté client, de sorte que votre ordinateur portable ou votre téléphone maintienne efficacement une connexion à iMessage ou WhatsApp ou quoi que ce soit comme s'il était connecté… mais relaie ensuite les messages dans Matrix une fois re-chiffrés.
  • Le portier pourrait passer à un protocole chiffré de bout en bout décentralisé comme Matrix pour préserver le chiffrement de bout en bout. C'est évidemment un travail important du côté du gardien, mais qui ne devrait pas être exclu.
  • Dans le pire des cas, signaler à l'utilisateur que sa conversation n'est pas sécurisée (l'équivalent du chat d'un avertissement de certificat TLS effrayant). Honnêtement, c'est quelque chose que les applications de communication (y compris celles basées sur Matrix !) devraient faire de toute façon : en tant qu'utilisateur, vous devriez être en mesure de dire quels tiers (bots, intégrations, etc.) ont été ajoutés à une conversation donnée »

« Dans l'ensemble, nous pensons que les avantages de rendre obligatoires les API ouvertes l'emportent sur les risques que quelqu'un exécute un pont vulnérable à grande échelle et sape l'E2EE de chacun », conclut-il. « Il vaut mieux avoir la possibilité d'accéder à vos données en premier lieu que d'être pris en otage dans un jardin clos ».

Il a aussi, depuis, rédigé un second billet plus technique et organisationnel, décrivant comment pourrait être implémentée l'interopérabilité « dans un monde DMA », ainsi qu'une FAQ technique sur les conséquences du DMA.

S'il reconnait qu'un maillage de ponts reliant les API ouvertes des fournisseurs propriétaires en les convertissant en normes ouvertes « peut sembler difficile à manier au premier abord », il estime que « c'est précisément le type de conduits qui relie les réseaux téléphoniques et Internet dans la pratique » : 

« Il n'est conceptuellement pas différent de convertir les appels téléphoniques à commutation de circuits en VoIP, ou câblés en Ethernet sans fil, ou l'un des autres ponts que nous prenons entièrement pour acquis dans nos vies grâce à leur transparence. »

Démystifier les clichés autour de l'interopérabilité

Dans un précédent billet, Amandine Le Pape, co-fondatrice de Matrix, cherchait elle aussi à démystifier les problèmes que poserait l'interopérabilité, tout en précisant qu'elle « est évidemment celle sur laquelle nous avons particulièrement veillé, car si elle atterrit bien elle pourrait faire passer le succès de Matrix à un niveau supérieur du jour au lendemain » :

« Si dans notre esprit l'interopérabilité implique automatiquement "standard ouvert", il existe en fait différentes manières de l'implémenter, selon jusqu'où l'on veut aller. Les débats typiques ici ont été de savoir s'il fallait forcer les gardiens à maintenir des API ouvertes et bien documentées, ou s'il fallait aller de l'avant et imposer une norme ouverte, et toutes les nuances entre les deux. »

Tirant parti de ses nombreux échanges avec des conseillers politiques d'États membres européens, « il a été assez fascinant de réaliser que c'étaient toujours les mêmes arguments qui nous étaient présentés. Nous avons fini par les énumérer [...] et avons pensé qu'il serait utile de les publier pour que tout le monde puisse y accéder ».

Elle répond ainsi à 11 problématiques qu'elle qualifie de « mythes », et bat en brèche le fait qu' « il est impossible d'avoir un standard à la fois ouvert, décentralisé et sécurisé faux : HTTPS l'a fait, Matrix l'a fait », ou que ce serait « difficile et coûteux ⇒ faux : Gitter (une messagerie de type Slack, ndlr) a été intégrée à Matrix en moins d'un mois, avec un seul développeur ».

Elle explique en outre que l'intéropérabilité n'est pas « incompatible avec le chiffrement de bout en bout : le courrier électronique l'a prouvé avec S/MIME et PGP », et conteste qu' « il n'y a pas de besoin utilisateur ⇒ faux : 25 % des utilisateurs de deux applications de communication perdent le contact avec des amis parce qu'ils utilisent trop d'applications ».

Elle rappelle également que des entreprises se rassemblent pour pousser à l'interopérabilité, comme la Coalition for Competitive Digital Markets, dont font partie Element, le client développé par Matrix, ainsi que ProtonMail, Infomaniak, NextCloud, Tutanota ou encore Vivaldi. 

« Impossible de modérer les réseaux sociaux construits sur un standard ouvert » ? Pas d'accord : les réseaux décentralisés ont a contrario « poussé à l'adoption de techniques de modération beaucoup plus sophistiquées que les approches grossières des silos centralisés ». 

Enfin, elle estime que la définition d'une norme ouverte est d'autant plus faisable que Matrix (qui propose des ponts avec Telegram, Discord, Slack/Matermost et WhatsApp, et qui est utilisé par Element, Tchap ou Citadel Team, entre autres), XMPP (utilisé par Jitsi, Pidgin, Psi, etc.) et ActivityPub (utilisée par Mastodon, NextCloud et PeerPub) existent déjà : 

« Par exemple, Matrix a été géré par son propre organisme de normalisation (The Matrix Foundation) et pourrait être ratifié par un organisme plus établi comme l'IETF, l'ETSI ou le W3C si nécessaire. »

« Évidemment, le diable sera dans les détails de la façon dont le texte final sera formulé, ainsi que les limites, les obligations et les contrôles mis en place, mais dans l'ensemble, cela devrait être une amélioration pour tous les utilisateurs et entreprises européens et nous attendons avec impatience ! », conclut-elle.

Les précédents ratés, ou limites, du RGPD

Ian Brown, chercheur en interopérabilité et professeur invité CyberBRICS à la FGV Law School, estime lui aussi sur Interoperability.news que « les discussions de groupe chiffrées de bout en bout interopérables ne sont pas seulement techniquement réalisables ; elles existent déjà [et] sont prises en charge depuis des années par de nombreux services et protocoles, notamment WhatsApp, Matrix, XMPP, Wire, Signal, Threema et autres » :

« L'algorithme Double Ratchet de Signal est disponible dans le domaine public et le protocole Megolm de Matrix et le protocole OMEMO de XMPP sont même publiés en tant que normes ouvertes, ce qui signifie qu'ils offrent une interopérabilité pour les discussions de groupe chiffrées de bout en bout. »

Il évoque également Messaging Layer Security (MLS), un autre protocole de chiffrement défini par l'IETF. Il n'est pas encore finalisé, mais propose une option plus évolutive pour les discussions de groupe chiffrées.

Pour lui, « le fait qu'un chat chiffré de bout en bout soit 1:1 ou de groupe n'a pas d'importance en matière d'interopérabilité. Si plusieurs services interagissent de manière chiffrée de bout en bout, ils doivent tous parler la même langue jusqu'à l'appareil. Il n'y a que deux façons de procéder » :

  1. Open API : le service demandeur implémente le langage du « gatekeeper ». Cela signifie que toute personne souhaitant interagir avec, par exemple, WhatsApp (pour une discussion en tête-à-tête ou en groupe) devra implémenter le protocole et le chiffrement de WhatsApp. Et s'ils veulent également interagir avec, par exemple, Signal, ils devront tout recommencer.
  2. Standard ouvert : tous les services, y compris les « gatekeepers », parlent le même langage chiffré de bout en bout. Les utilisateurs de différents services peuvent être réunis dans le même chat (1: 1 ou groupe) de manière totalement sécurisée avec un chiffrement complet de bout en bout. Les normes ouvertes existantes prenant en charge le chiffrement de bout en bout incluent Matrix et XMPP.

« Des discussions de groupe chiffrées de bout en bout interopérables existent déjà et sont utilisées par des millions de personnes via des normes ouvertes telles que Matrix ou XMPP », conclut-il :

« La première étape simple vers la mise en œuvre de l'interopérabilité chiffrée de bout en bout (1:1 ou groupe) consiste à imposer des API ouvertes, mais la mise en œuvre évolutive et axée sur la confidentialité à plus long terme se ferait via des normes ouvertes. »

Encore faut-il que les messageries et organismes de normalisation parviennent à trouver un terrain d'entente.

Faire en sorte que toutes les applications de messagerie utilisent une seule norme serait un défi important et chronophage. « Potentiellement, vous pourriez simplement avoir une situation où tout le monde passe à Matrix », explique à Wired Nadim Kobeissi, cryptographe et fondateur de la plateforme de publication décentralisée Capsule Social, qu'il vient de lancer :

« Mais Matrix est une architecture de sécurité fondamentalement différente, non seulement du point de vue du chiffrement de bout en bout, mais également du point de vue de la modélisation des menaces. »

Les entreprises devraient reconstruire l'intégralité de leurs systèmes de chiffrement et modifier plusieurs fonctionnalités de leurs applications, un processus qui pourrait prendre des années, estime Wired :

« Prenez Meta : en 2019, la société a déclaré qu'elle allait chiffrer par défaut les DM Instagram et Messenger de bout en bout et intégrer leur infrastructure à WhatsApp. Trois ans plus tard, l'entreprise tente toujours de démêler ses systèmes et d'ajouter des dispositifs de sécurité. La transition a été plus difficile que prévu alors que Meta contrôle toute la technologie impliquée. »

De plus, souligne Wired, la volonté de changement des entreprises dépend aussi du degré de pression que la Commission européenne, qui appliquera la DMA, exercera sur elles. Or, si le DMA pourrait entraîner des amendes de plusieurs millions de dollars pour les entreprises qui ne se conforment pas, le RGPD a d'ores et déjà démontré que c'était, en pratique, bien plus compliqué :

« Le RGPD a été mal appliqué, y compris une disposition qui dit que les gens devraient pouvoir transporter leurs données d'une application à une autre. Les entreprises technologiques n'auront peut-être pas le choix si la Commission européenne applique le DMA, mais cela pourrait être le cadet de leurs soucis. »

La Cour des comptes européenne déplore elle aussi les problèmes d'interopérabilité

Coincidence : dans un rapport consacré à la cybersécurité des institutions, organes et agences de l'UE (IOAUE), la Cour des comptes européennes déplore « un niveau de préparation globalement insuffisant par rapport aux menaces » et notamment que « les outils de communication de base tels que les solutions de courrier électronique crypté ou de visioconférence ne sont pas totalement interopérables » : 

« Les IOAUE ne disposent pas encore tous de solutions appropriées pour échanger des informations sensibles non classifiées, et ceux qui en ont recourent généralement à des produits et à des systèmes qui leur sont propres, ce qui pose des problèmes d'interopérabilité. »

IOAUE

La Cour a constaté que les IOAUE « utilisaient pas moins de 15 logiciels de visioconférence différents, mais même lorsque plusieurs IOAUE recourent à un logiciel/une plateforme identique, l'interopérabilité fait bien souvent encore défaut ».

En outre, les orientations indiquant quelles informations peuvent être partagées ou examinées (selon le degré de sensibilité) sur telle ou telle plateforme diffèrent entre les IOAUE : « Tous ces problèmes sont source d'inefficience sur le plan économique et opérationnel et peuvent mettre en péril la sécurité » : 

« Nous avons relevé des problèmes d'ordre opérationnel dans l'échange d'informations sensibles non classifiées, par courrier électronique crypté (sic) ou visioconférence, en raison du manque d'interopérabilité entre les solutions informatiques, d'orientations contradictoires sur leur utilisation autorisée ainsi que de l'absence de marquages communs et de règles communes de traitement concernant les informations. »

Écrit par Jean-Marc Manach

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le DMA endommagera-t-il le chiffrement de WhatsApp ?

Ordonner aux médecins de guérir le cancer ?

Le meilleur résultat possible imaginable pour l'internet ouvert

Démystifier les clichés autour de l'interopérabilité

Les précédents ratés, ou limites, du RGPD

La Cour des comptes européenne déplore elle aussi les problèmes d'interopérabilité

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (27)


En lisant le titre, je me demandais bien pourquoi il y avait du Direct Memory Access dans Whatsapp. En fait, il y a juste surcharge du symbole DMA.


Je me suis posé la même question


Je me disais en début d’article qu’il faudrait justement un protocole commun (comme tente de le faire MATTER pour la domotique) chargé de synchroniser les en-têtes des échanges, et agnostique mais pouvant être implémenté dans un client multi-plateforme. Chaque échange resterai sur l’API concernée, et chacun pourrait proposer des fonctionnalités via des plugins par exemple.



Après, clairement, quand on voit le bordel sur e-mail (limites serveurs qui sont pas communiquées - vive les pièces jointes de 5Mo maxi qu’on découvre après), ça va pas être facile…


Clairement, l’interopérabilité ça n’arrivera pas. Mais si on pouvait avoir Whatsapp, Signal et Telegram dans Pidgin, ce serait déjà pas mal. Pour ça, il faudrait que le protocole soit public.


Le dernier paragraphe résume tout… ça ne se fera pas.


Xmpp et omeo en chiffrage ça marche et c’est standard depuis longtemps. Même Facebook était en Xmpp avant… Ce qui permetait aux Windows phone d’avoir Facebook dans la discussion SMS. C’était la vie. Puis what’s app et Facebook ont tout péter


C’est Google, surtout, qui était un grand promoteur de xmpp, et l’a tué du jour au lendemain.


Et si on commencait avec le RCS ?


Les emails ? jamais ça ne fonctionnera…


Franchement ça me parait être du FUD tout ça.



Tout ce qui existe aujourd’hui ne changera pas : sur les réseaux qui supportent le E2EE, entre deux contacts du même réseau ça restera chiffré.



Oui il y a un doute sur la faisabilité technique quand ça va passer d’un service à l’autre. Sauf que :




  • On a vécu des décennies sans E2EE sur l’IM sans que ça n’emeuve personne (on pouvait littéralement sniffer les conversations MSN de la maison avec Wireshark). Donc pour le cas marginal au début où on passera d’un protocole à l’autre ok vivra très bien sans chiffrement en attendant qu’une solution technologique soit trouvée par les acteurs.

  • Les GAFAMs savent très bien travailler ensemble à des solutions techniques quand le besoin existe. Le texte se limite aux entreprises faisant plus de 75Md de CA soit des entreprises qui ont largement les moyens de coopérer, même forcées, pour trouver une solution technique à ce problème si elles le veulent (mais mon petit doigt me dit qu’elle feront aucun effort)



Franchement le texte est bien. Oui le problème du chiffrement peut être compliqué à gérer mais on est sur un sophisme de la solution parfaite là. Entre deux utilisateurs d’un même réseau, tout restera exactement comme aujourd’hui.



N’oublions d’ailleurs pas que quand ça les a arrangé par le passé, les GAFAMs ont su nous pondre des messageries interoperables (MSN avec Facebook, Google avec Jabber, Jabber avec Facebook).



L’interoperabilité chiffrée est possible, le mail le fait très bien. C’est sûr que ça demande du travail de coopération. Mais les gains derrière seront réels pour l’utilisateur. Franchement ça vaut la peine de leur faire un peu se sortir les doigts.


Comme toujours des qu’il faut se contraindre un peu tu peux être sur que les GAFAM vont faire pleuvoir les éditos ( Remember les édito RGPD) pour dire que ca va tuer le marché, la sécurité, …..



L’ARCEP a bien réussi à imposer des protocoles interop aux opérateurs en France, et pourtant je peux vous garantir que ca chouine à chaque réunion interop des que ca demande d’évoluer mais au final c’est toujours le même scénario: Les gros trouvent un accord sur le format/fonctionnement et le reste suit.
Ca sera pareil ici, une fois que les gros (FB google, apple, microsoft, twitter) se seront mis d’accord tous les autres implémenteront le protocole pour être compatible.


Google Soutient le RCS et Il me semble qu’il ne propose pas d’autre solution.
Or niveau standard, le RCS est quand même un standard de la GSMA (et pas un truc spécifique à Android).



Il faudrait que Apple arrête de soutenir le harcèlement scolaire à son profit et intègre ce standard à son téléphone.


je ne vois pas le problème, on pourrait surement faire comme pour le wifi, chaque box ou tel. peuvent choisir le protocole de chiffrement pour sa clef comme wpa ou wpa2.



Bon cela suppose aussi que chaque plateforme supportent plusieurs standard.



Ex : j’appelle untel via ma plateforme et par défaut j’ai paramétré avec matrix. Mon interlocuteur en sera avertie libre à lui de me répondre en utilisant le même protocole. Ca serait un peu plus dur pour les salons ou il faudrait que tous le monde se mettent d’accord avant d’entrer pour utiliser le même chiffrement.



RedWave a dit:


Après, clairement, quand on voit le bordel sur e-mail (limites serveurs qui sont pas communiquées - vive les pièces jointes de 5Mo maxi qu’on découvre après), ça va pas être facile…




Suis un peu hors-sujet, mais je me souviens qu’en 2000 la limitation des pièces jointes était de 5 Mo en général. Je trouve délirant de penser qu’en 2022, alors que les débits ont explosé (en 2000 on était entre le modem 33,6 et l’ADSL 512 kb/s), tout comme les tailles de disques durs (on était à quelques Go me semble), on reste à des tailles de pièces jointes du même ordre, dans beaucoup d’organisations et sociétés.


En vérité c’est sain. Je ne me vois pas accepter des PJ de 1Go sur un serveur mail, qu’on soit en 2022 ou pas. Et si tu souhaites balancer un PJ plus gros que 5 Mo à toi de te bouger le cul pour diminuer sa taille ou utiliser un meilleur moyen pour partager.


Hugues1337

En vérité c’est sain. Je ne me vois pas accepter des PJ de 1Go sur un serveur mail, qu’on soit en 2022 ou pas. Et si tu souhaites balancer un PJ plus gros que 5 Mo à toi de te bouger le cul pour diminuer sa taille ou utiliser un meilleur moyen pour partager.


Je ne vois pas la raison. Sur un serveur mail en 2010 j’avais autorisé 100 Mo pour être tranquille. Sinon on peut aussi considérer que 5 Mo c’est beaucoup trop gros (ça l’était en 2000, ça mettait du temps à partir par modem, on parle de plus d’une minute).


OlivierJ

Je ne vois pas la raison. Sur un serveur mail en 2010 j’avais autorisé 100 Mo pour être tranquille. Sinon on peut aussi considérer que 5 Mo c’est beaucoup trop gros (ça l’était en 2000, ça mettait du temps à partir par modem, on parle de plus d’une minute).


C’est crade. Je ne vois pas à quel moment c’est normal d’envoyer 100 Mo par mail. C’est utiliser les mails pour un truc pas conçu pour. Tu prends nextcloud à côté qui fera le taff (partager des data) bien mieux et plus sécurisé.


Hugues1337

C’est crade. Je ne vois pas à quel moment c’est normal d’envoyer 100 Mo par mail. C’est utiliser les mails pour un truc pas conçu pour. Tu prends nextcloud à côté qui fera le taff (partager des data) bien mieux et plus sécurisé.


Et pourquoi envoyer 5 Mo ce ne serait pas crade ? C’est quoi la limite ?



La réponse c’est que la limite est relativement arbitraire, et qu’en 2000 la limite était de 5 Mo parce que les débits et les disques étaient faibles (par rapport à après), et qu’il n’y a aucune raison de rester limité, d’ailleurs certains mails sont à 10 ou 20 Mo depuis longtemps. Et en 1991 (mes premiers mails) la limite devait être < à 5 Mo.



Ce qui est crade ce sont les pages Web qui de nos jours en moyenne font 10 x plus qu’à une époque.


OlivierJ

Et pourquoi envoyer 5 Mo ce ne serait pas crade ? C’est quoi la limite ?



La réponse c’est que la limite est relativement arbitraire, et qu’en 2000 la limite était de 5 Mo parce que les débits et les disques étaient faibles (par rapport à après), et qu’il n’y a aucune raison de rester limité, d’ailleurs certains mails sont à 10 ou 20 Mo depuis longtemps. Et en 1991 (mes premiers mails) la limite devait être < à 5 Mo.



Ce qui est crade ce sont les pages Web qui de nos jours en moyenne font 10 x plus qu’à une époque.


C’est crade car les serveurs mails sont pas conçus pour. Tu te retrouves à devoir faire souvent le ménage pour pas péter les limites du serveur. Et t’es pas à l’abris d’une tempête de mail avec un reply to all foiré. Bref.
Puis bon, pas pour rien que gmail (par exemple) empêche d’envoyer des trop grosses PJ et propose d’utiliser… gdrive si tu dépasses la limite.



Donc si y’a une raison : c’est pas conçu pour.


Hugues1337

C’est crade car les serveurs mails sont pas conçus pour. Tu te retrouves à devoir faire souvent le ménage pour pas péter les limites du serveur. Et t’es pas à l’abris d’une tempête de mail avec un reply to all foiré. Bref.
Puis bon, pas pour rien que gmail (par exemple) empêche d’envoyer des trop grosses PJ et propose d’utiliser… gdrive si tu dépasses la limite.



Donc si y’a une raison : c’est pas conçu pour.


“pas conçu pour”, ben c’est dommage on envoie des pièces jointes par mail depuis 30 ans environ…
Ça c’est la pratique. Donc la limite est arbitraire et surtout devrait suivre l’évolution des moyens (en disque et réseau). On ne va pas me faire croire que si on pouvait gérer 5 Mo en 2000, on ne peut pas gérer 50 Mo en 2022 ! (en fait on peut gérer bien plus avec la croissance des moyens).



Et dans les systèmes où on a des limites plus hautes, aucun souci avec le serveur de mail (j’en ai monté et géré), de toutes façons on n’envoie pas souvent des pièces jointes plus grosses que 20 Mo. Et on peut mettre des tailles max aux BAL, ce qu’on fait en général.



Le Web n’était sans doute pas conçu pour avoir des tonnes de Javascript partout, mais c’est comme ça. Par ailleurs, rien que l’idée du webmail au début j’ai trouvé ça bizarre, on avait POP/IMAP et SMTP, pourquoi enrober ça dans du HTML et demander à avoir un serveur Web en plus du serveur mail ? C’est pas efficace du tout.


OlivierJ

“pas conçu pour”, ben c’est dommage on envoie des pièces jointes par mail depuis 30 ans environ…
Ça c’est la pratique. Donc la limite est arbitraire et surtout devrait suivre l’évolution des moyens (en disque et réseau). On ne va pas me faire croire que si on pouvait gérer 5 Mo en 2000, on ne peut pas gérer 50 Mo en 2022 ! (en fait on peut gérer bien plus avec la croissance des moyens).



Et dans les systèmes où on a des limites plus hautes, aucun souci avec le serveur de mail (j’en ai monté et géré), de toutes façons on n’envoie pas souvent des pièces jointes plus grosses que 20 Mo. Et on peut mettre des tailles max aux BAL, ce qu’on fait en général.



Le Web n’était sans doute pas conçu pour avoir des tonnes de Javascript partout, mais c’est comme ça. Par ailleurs, rien que l’idée du webmail au début j’ai trouvé ça bizarre, on avait POP/IMAP et SMTP, pourquoi enrober ça dans du HTML et demander à avoir un serveur Web en plus du serveur mail ? C’est pas efficace du tout.


C’est de la surcouche sur de la surcouche depuis 30 ans. Par exemple MS fait de l’anti-tempête de mail, mais dans son coin…. J’ai pas creusé mais je serais pas étonné que tu as pas accès à ça dans un vrai Exchange. C’est un service qui est bien trop vieux, trop obsolète, trop facile à hacker et trop multiple.
Donc ouais tu “peux” faire des mails avec des PJ de 1Go ça marche. Tu peux faire du TLS aussi. Tu peux aussi chiffrer. Mais c’est de la surcouche.



En limitant à 5 Mo (voir 10 Mo) et en forcant à utiliser un drive (de type nextcloud, ou un simple serveur samba si 100% interne) tu évites pas mal d’emmerde et tu as quelque chose de bien plus moderne.



En vrai tu attends comme moi un remplaçant moderne aux mails.


Hugues1337

C’est de la surcouche sur de la surcouche depuis 30 ans. Par exemple MS fait de l’anti-tempête de mail, mais dans son coin…. J’ai pas creusé mais je serais pas étonné que tu as pas accès à ça dans un vrai Exchange. C’est un service qui est bien trop vieux, trop obsolète, trop facile à hacker et trop multiple.
Donc ouais tu “peux” faire des mails avec des PJ de 1Go ça marche. Tu peux faire du TLS aussi. Tu peux aussi chiffrer. Mais c’est de la surcouche.



En limitant à 5 Mo (voir 10 Mo) et en forcant à utiliser un drive (de type nextcloud, ou un simple serveur samba si 100% interne) tu évites pas mal d’emmerde et tu as quelque chose de bien plus moderne.



En vrai tu attends comme moi un remplaçant moderne aux mails.


Je ne vois pas trop pourquoi on remplacerait le mail, ça fonctionne bien et à très grande échelle.
Et si on n’avait pas d’emmerdes en 2000 avec 5 Mo, on ne devrait pas avoir d’emmerdes en 2020 avec 10 fois plus (ou même 50 fois plus vu l’inflation des moyens). C’est comme si tu voulais qu’on reste à des pages Web de 50 k.


Hugues1337

C’est de la surcouche sur de la surcouche depuis 30 ans. Par exemple MS fait de l’anti-tempête de mail, mais dans son coin…. J’ai pas creusé mais je serais pas étonné que tu as pas accès à ça dans un vrai Exchange. C’est un service qui est bien trop vieux, trop obsolète, trop facile à hacker et trop multiple.
Donc ouais tu “peux” faire des mails avec des PJ de 1Go ça marche. Tu peux faire du TLS aussi. Tu peux aussi chiffrer. Mais c’est de la surcouche.



En limitant à 5 Mo (voir 10 Mo) et en forcant à utiliser un drive (de type nextcloud, ou un simple serveur samba si 100% interne) tu évites pas mal d’emmerde et tu as quelque chose de bien plus moderne.



En vrai tu attends comme moi un remplaçant moderne aux mails.


Le drive a deux problèmes en entreprise :




  • des manips en plus à faire alors que la PJ est beaucoup plus simple

  • chaque boîte utilise un service et souvent les DSI bloquent les autres, donc entre entreprises différentes c’est galère


mtaapc

Le drive a deux problèmes en entreprise :




  • des manips en plus à faire alors que la PJ est beaucoup plus simple

  • chaque boîte utilise un service et souvent les DSI bloquent les autres, donc entre entreprises différentes c’est galère


Les bons clients de messagerie gèrent automatiquement le stockage sur un drive.



Ils bloquent vraiment des services de stockage comme dropbox ?


Mihashi

Les bons clients de messagerie gèrent automatiquement le stockage sur un drive.



Ils bloquent vraiment des services de stockage comme dropbox ?


Il est plus rapide de demander : “Qu’est ce qu’ils ne bloquent pas ?”



Pour Dropbox, voici la charmante réponse (DTC) : “Désolé, ce site Web n’est pas approuvé.”


Conserver la même taille (ou ordre de grandeur à minima) ça permet de réduire les coûts. Ça n’apparaît pas comme une régression pour l’utilisateur donc ça passe.


L’autre souci avec les Drives (je pense à OneDrive en entreprise), c’est la preuve/persistance.




  • Souvent, envoyer une PJ par email sert de preuve de livraison (un travail, une facture)

  • Les liens OneDrive ont un gros souci d’expiration, soit parce que c’est “une adresse email qui n’appartient pas à votre organisation” et il y a une date maximale de téléchargement, ou, le pire du pire : il faut garder le fichier à vie dans un dossier et ne surtout pas y toucher, car s’il est déplacé, c’est terminé (coucou les symlinks Microsoft?)



Bref, l’email est là pour rester encore quelques centaines d’années. Il faudrait potentiellement implémenter des mécanismes d’économie de PJ par hash, il est évident que 4 PPT de 100Mo l’un derrière l’autre parce qu’on a changé de version, c’est pas top, mais c’est comme ça