The DMA Stakeholder Workshop: Interoperability between messaging services

A few weeks ago we found ourselves in Brussels to participate in the second stakeholder workshop for the Digital Markets Act (DMA).

The DMA is new antitrust/competition regulation from Europe which came into force in November, whose objective is to make digital markets more competitive by forcing gatekeepers (i.e. large tech companies) to reconsider some of their anti-competitive or self-preferencing practices. Gatekeepers are defined as companies which have a clear position of influence in a given market (based on revenue / market cap / number of users thresholds), and “an entrenched and durable position”. The process for designating which companies count as gatekeepers will start in May 2023.

The DMA touches upon different key topics, from self-preferencing behaviour to app store management practices - but most importantly includes interoperability for “number-independent interpersonal communication services” (NIICS), otherwise known as chat and voice/video calling and conferencing services (social media was left out for now).

This particular workshop was focused on the latter: interoperability between messaging services, with the aim of getting the different stakeholders of the industry in the same place to discuss how the legislation could be implemented. The whole idea is to figure out a practical way in which WhatsApp could interoperate with iMessage, Google Messages and others, creating an interoperable communication network where users are no longer locked into communication silos and pick their preferred service provider without compromising on who they can talk to.

About 900 people participated online, and around 80 people were present in person: the maximum the room could hold. It was particularly fun to see representatives from the whole industry turning up in person, including folks from XMPP, MIMI (the new IETF working group on messaging interoperability), MLS, us from Matrix obviously (alongside Matrix ecosystem representatives from Beeper and NeoChat!) - all together with the Body of European Regulators for Electronic Communications (BEREC), civil society representatives (like the Federation of German Consumer Organisations (VZBV) and European Digital Rights (EDRi)), mobile network operators, local network agencies, and obviously some of those who are likely to be designated as gatekeepers, such as Meta, Apple and Google.

So what was discussed?

All of the workshop proceeds were livestreamed and archived by European Commission’s webcasting service and released under the terms of the Creative Commons Attribution 4.0 International (CC BY 4.0) licence, so we’ve taken the liberty of republishing them split up into chapters so that folks can quickly refer to the discussion.

Panel 1: Introduction to horizontal interoperability between messaging services: goals, challenges and potential solutions

The first panel focused on setting up the scene and highlighting the challenges expected during the implementation phase, featuring Simonetta Vezzoso (Professor of Economics at The University of Trento), Chiara Caccinelli (Co-chair - Digital Markets WG at BEREC), Suzanne Blohm (Policy officer at Verbraucherzentrale Bundesverbands (VZBV)) and Jan Penfrat (Senior Policy Advisor at EDRi). There was a lot of emphasis around the risks of gatekeepers dragging their feet, or choosing the solution which makes it harder for SMEs or self-hosters to interoperate, as well as the challenge of introducing the new paradigm of interoperability for messaging without losing the usability aspect - see below for the full scope:

• 00:00 Welcome to the second DMA stakeholder workshop about interoperability between messaging services
• 08:03 Introduction of the panelists
• 09:26 What is the Article 7 of the Digital Markets Act (Simonetta Vezzoso)
• 26:35 Interoperability already exists in the EU, what can we learn from it (Chiara Caccinelli)
• 40:43 End user perspective and behaviour, benefits of the DMA Article 7, Challenges (Suzanne Blohm)
• 49:30 Benefits for end users, and an existing technical stack to build from (Jan Penfrat)
• 59:21 What the UI could look like (Jan Penfrat)
• 01:03:07 Question - Do users need an account on each network, or is it a true federation? (XMPP Foundation)
• 01:05:19 Question - What rule do you see for Telcos and for messaging services they provide?
• 01:10:07 Question - Does the term "user" include people running their own server/service? (Open Source Initiative)
• 01:14:50 Question - How to check the gatekeeper is not giving a suboptimal solution? (online question)
• 01:18:04 Question - Does user consent limit the power of Article 7? (Viber)
• 01:22:36 Question - Gatekeepers don't have an incentive to make appealing UIs for interoperability and might try to scare users away. Will it be addressed? (NLNet)
• 01:24:08 Question - People usually dislike popups, how to strike the balance between warning and upsetting them? (online)
• 01:27:51 Question - Have you been thinking about reputation models?
• 01:29:53 Question - Different apps use different E2EE protocols to differentiate. Could article 7 kill that differentiation? (online)
• 01:38:48 Question - What will be the paradigm of non discrimination?
• 01:33:10 Question - What about interoperability of RCS and Apple iMessage? (Orange)
• 01:34:44 Question - Do you take into account that there are not only company-run services, but also Open Source components? (Process One)
• 01:35:55 Question - What are the implications for non European users? (Beeper)
• 01:39:25 Question - Does the DMA only mandate interoperability for European users, even on a same platform? (XMPP)
• 01:40:36 Question - Will the interoperability be opt-in or opt-out? (Matrix)
• 01:41:50 Question - How avoid the standardisation to be taken over by commercial interests? (online)
• 01:43:43 Question - What will the timing look like for the DMA? (Cisco)
• 01:48:13 Question - What could be reasonable requirements for smaller services? (online)
• 01:49:00 Question - Where should gatekeeper gather to start discussion how interoperability will look like in practice? (OpenXchange)
• 01:51:11 Question - What about account portability, for users switching from one platform to another? (University of Rome)
• 01:54:53 Question - Is contact information part of the data gatekeepers need to share? (XMPP)
• 01:56:12 Closing

Panel 2: Exploring the technical aspects of interoperability (Part 1): end-to-end encryption, security of the service

Then, after a quick lunch, the second panel went into the nitty gritty of how end-to-end encrypted interoperable messaging (1:1 messaging is the first milestone to be delivered, hence the focus) could actually be implemented by the gatekeepers. The panel starred Paul Rösler from FAU Erlangen-Nürnberg, who gave a great overview of end-to-end encryption in general, Alissa Cooper from Cisco who explained the merits of open interoperable protocols, Eric Rescorla from Mozilla explaining the merits of standardisation, yours truly from Matrix explaining and demonstrating how one can actually use a standardised open protocol to interoperate without sacrificing privacy (effectively fleshing out our blog posts from last year) and then finally Stephen Hurley from Meta to explain how they are thinking about DMA obligations.

The panel ended up being a relatively exciting tour through the landscape of DMA practicalities, and it was a lot of fun to actually demonstrate a minimum viable prototype of client-side bridging thanks to Travis’s work packaging up standalone client-side bridges for WhatsApp and Google Chat (strictly for demonstration illustrative purposes only). The slides (and demo) were sadly a bit fuzzy on the recording, but you can see our slides below and grab everyone’s presentations from the European Commission website:

When DMA first became headline news last year, there was a lot of very vocal concern that it would somehow end up undermining end-to-end encryption (despite the legislation explicitly requiring that E2EE must be preserved when interoperating). Hopefully this session demonstrated that both the European Commission and the various panellists are dead serious about achieving interoperability without sacrificing privacy - whether that’s via the brute-force approach of client-side bridges, or the more sophisticated approach of client-side bridges which bridge to client-side APIs, or by incrementally or entirely adopting a true open standard protocol like Matrix, XMPP, or whatever MIMI comes up with.

You can see the whole panel split into the various sections below:

• 00:00 Opening
• 01:23 Introduction of the panellists
• Interoperable Messaging - Paul Rösler (FAU)
• 03:10 Interoperable end-to-end (E2EE) encryption options (Paul Rösler)
• 05:24 Requirements for interoperable E2EE (Paul Rösler)
• 09:22 Options for interoperable E2EE (Paul Rösler)
• 13:54 Confidentiality, Privacy & Abuse prevention (Paul Rösler)
• 19:07 Group Messaging (Paul Rösler)
• DMA Stakeholder Workshop: Interoperability - Eric Rescorla (Mozilla)
• 22:44 Learning from QUIC (Mozilla)
• 24:14 E2EE and interoperability (Mozilla)
• 25:50 Key Establishment in a E2EE interoperable system (Mozilla)
• 27:16 Message and media formats in a E2EE interoperable system (Mozilla)
• 28:30 Identity in a E2EE interoperable system (Mozilla)
• 30:49 Multiple gatekeeper scenarios (Mozilla)
• 31:41 Suggested framework for interoperability (Mozilla)
• DMA Stakeholder Workshop: Interoperability - Alissa Cooper (Cisco)
• 35:20 Discussing how the UX of a DMA compliant product can look like (Cisco)
• 36:38 The use case for enterprise interoperability (Cisco)
• 30:47 Approaches to DMA Compliance (Cisco)
• 43:57 Limits of the per-gatekeeper, in-house solution approach (Cisco)
• 48:19 Strengths of the consolidated (standardised) solution (Cisco)
• 50:00 Implications & requirements of the consolidated solution (Cisco)
• Implementing Interoperability for the DMA - Matthew Hodgson (Matrix)
• 52:03 Implementing Interoperability in practice for the DMA (Matrix)
• 53:00 A practical path to full interoperability (Matrix)
• 54:35 Defining the problem we're solving (Matrix)
• 55:15 Approach 1 Client-side bridging using server-side APIs (Matrix)
• 57:21 Approach 2 Client-side bridging using client-side APIs (Matrix)
• 58:48 Approach 3 Polyglot app, using a 3rd party protocol à la iMessage (Matrix)
• 01:00:06 Approach 4 Using an open protocol (Matrix)
• 01:00:42 Pros & Cons of each approach (Matrix)
• 01:01:55 DEMO of client-side bridging (Matrix)
• Meta's view on the DMA as seen from WhatsApp - Stephen Hurley (Meta)
• 01:06:45 Meta's view on the DMA as seen from WhatsApp (Meta)
• Questions
• 01:17:12 Matthew (Matrix) remind that not only the demo showed client-side bridging was possible, but iMessage has been doing it for years via SMS & iMessage
• 01:17:54 Meta has two IM platforms (Instagram and Facebook) that are not E2EE. What is Meta going to do about those platforms? (Beeper)
• 01:18:45 How to balance discoverability and privacy?
• 01:21:04 How to solve the problem of different E2EE protocols? (online)
• 01:24:48 Do some of the panellists think the best option is not a single standardised protocol? (OpenXchange)
• 01:33:46 Which measures by gatekeepers to preserve security integrity and privacy can be considered proportionate?
• 01:36:38 How many people have worked on the client-side demo?
• 01:38:56 Does it really matter that MLS is not "done"?
• 01:47:30 How will article 7 ensure private keys will never transit over the network? (online)
• 01:53:00 What about interoperability of features like custom emojis, removing messages, etc? (online)
• 01:57:42 What does the rest of the panel thinks about the guarantees they can provide when a message leaves a system? (XMPP)

Panel 3: Exploring the technical aspects of interoperability (II): data collection, identification of users, quality of interoperable services, system management, integrity of the service/prevention of misuse

Finally, we launched into the third and final session of the day - a second technical panel to dig into questions of identity, usability, data privacy, consent and anti-abuse in a DMA world. Relative to the second panel, there were more questions than answers here, as the panellists discussed whether users would need to consent or opt-in/opt-out of interoperability, and debated the various data privacy implications of DMA. The panel starred Stephen Hurley from Meta again, Lucas Verney from PEReN, Markus Klein from Bundesnetzagentur and Rohan Mahy from Wire introducing the MIMI working group at IETF.

• 00:00 Opening and panellists introduction
• Meta / WhatsApp
• 02:21 User Safety on WhatsApp
• 06:51 Consenting to interoperability
• 07:56 Objective criteria to assess whether a request is reasonable or not
• PEReN
• 09:00 PEReN is a French government digital expertise hub
• 10:12 Efficient design for effective interoperability
• 11:25 Reconciliation identity between services
• 13:40 Discoverability between platforms of different scales
• 16:27 Should fancy features (e.g. emoji reactions) be interoperable?
• 17:22 Quality of Service
• 19:02 Security goes beyond E2EE
• Bundesnetzagentur
• 20:26 Bundesnetzagentur views on the DMA
• Wire
• 26:39 Federation and Interoperability issues are similar
• 28:10 Standards-based interoperability and the MIMI working group
• 29:18 Identifiers, devices, handles
• 30:50 User introduction & discovery
• 31:30 Messaging content
• 34:06 Why MIMI picked MLS for E2EE?
• 35:54 Server to server transport mechanism
• 36:38 E2EE Cryptographic identity
• 39:00 MIMI's standardisation work provides a strong foundation for other features
• 40:25 Why is standardized interoperability beneficial?
• Questions
• 44:30 What about terms of service, minimum usage age enforcement etc?
• 48:03 How can identity be maintained separately from networks? How will differing policies of services be respected?
• 52:26 Does WhatsApp rely on the phone number as a primary identifier?
• 53:29 Some systems like Telegram have pseudonymous IDs. How would that work with platforms relying on e.g. phone numbers?
• 55:42 Should the service name be part of the identifier?
• 57:33 Can the DMA improve how authentication is handled?
• 59:51 What made the GDPR successful is the potential fines. What about the DMA?
• 01:03:48 How can interoperability be designed to stop leaking contact lists?
• 01:09:15 Are we doing cookie banners again?
• 01:15:57 Should we think about some integration with eIDAS for more trustworthy identities?
• 01:19:48 Are all the protocols like Matrix or MIMI free to use, or do they have a fee?
• 01:22:32 Are there really concerns about the DMA and security?
• 01:27:40 Does Meta expect to provide a EU-only and a global version of their messengers?
• 01:29:55 The views expressed here regarding consent are concerning when it comes to self-hosting
• 01:36:20 Closing

Conclusion

This was a fascinating opportunity to have a front-row seat at history being made, as the various key players finally got down to business on the practical implications of DMA interoperability.

We saw the full spectrum of options on the table, from Meta’s implications that they would simply open their existing API complete with the existing Double Ratchet Encryption, to the pragmatic approach of Matrix (“at first we’ll bridge, and then the players should gradually converge on an open standard”) to the more idealistic approach of MIMI (“everyone should natively adopt an entirely new open standard built on MLS”). The next step is to establish a reference implementation and approach, and in the end it seems likely that the approach that works will be the one which the gatekeepers can actually practically adopt within the punchy timeframes built into the legislation:

You can also check out Carl Schwan’s writeup (from NeoChat), as well as Eric Rescorla’s braindump on DMA interoperability that accompanies his talk.

We live in interesting times, and it’s fascinating to see Matrix’s vision of interoperable communication being cemented into regulation by the EU. Our view is that as long as the gatekeepers open their APIs and add support to model remote users in their systems, then at least the wider world can implement client-side bridges to crack the door of the gatekeepers open - and then as gatekeepers refresh their stacks and new players emerge, they’ll likely implement the common protocol (if it’s fit for purpose) rather than burn time reinventing the wheel on proprietary solutions. Meanwhile, the DMA provides welcome encouragement to ensure that open protocols like Matrix can rise to the challenge and fill the gap - whether that’s independently or as part of IETF’s MIMI initiative. May the best solution win!