What is the DMA asking for?
The final text will probably be available around mid-May and voted for in early July, but the latest version we have seen lists the following:
- Gatekeepers will have to “make the basic functionalities of their [...] communication service interoperable with other [...] communication services” by “providing the necessary technical interfaces” (i.e. opening up their APIs) “or similar solutions that facilitate interoperability, upon request, and free of charge”
- “‘Interoperability’ means the ability to exchange information and mutually use the information which has been exchanged through interfaces or other solutions”
- These APIs must preserve the same level of end-to-end encryption (if any) to remote users as is available to local users.
- “The level of security, including end-to-end encryption where applicable, [...] the gatekeeper provides to its own end users [will have to be] preserved across the interoperable services”
- In the short term (approx. 6 months after the DMA comes into force) this only applies to 1:1 messaging and 1:1 file transfer, but in the longer term it will also apply to group messaging and group file-transfer (in about two years), 1:1 voice and video calling and group voice and video conferencing (in about 4 years). But these deadlines may be further extended by the European Commission if “the gatekeeper demonstrates that this is necessary to ensure effective interoperability and to preserve the necessary level of security, including end-to-end encryption where applicable.”
Gatekeepers
Who are the “gatekeepers”?
The DMA defines a gatekeeper as a “provider of core platform services” worth over €75B or with over €7.5B of turnover in Europe, and which has at least 45 million monthly end users and 10,000 annual business users in the EU. This means only the tech giants are in scope (e.g. as of today that includes Meta, Apple, Google, Microsoft, Salesforce/Slack - not Signal, Telegram, Discord, Twitter or TikTok).
What do the gatekeepers need to do?
As a minimum, gatekeepers will have to open and document their existing APIs, so that alternative clients (i.e. alternative messaging apps) and/or bridges (see below for more about bridges) can connect to their service. The DMA requires that the APIs must expose the same level of privacy for remote users as for local users. So, if their service is end-to-end-encrypted (E2EE), these APIs must expose these E2EE semantics so that an alternative app would be able to implement the E2EE too. For E2EE-capable APIs to work, the gatekeeper will likely have to represent remote users as if they were local in their system. This applies to 1:1 and group chats, file transfers and VoIP calls/conferences too.
Once the APIs are open, services seeking to interoperate will have to implement interoperability with every gatekeeper one by one. For a sustainable solution, gatekeepers could implement an open standard like Matrix or XMPP. It would preserve end-to-end encryption and give access to their network to any app compliant with this standard. And vice-versa, third party applications implementing the same standard would be able to interoperate with any gatekeeper compliant with the standard.
Does the DMA mean the gatekeepers will have to implement an open standard such as Matrix or XMPP?
No. They can keep their existing implementations and APIs and have the other apps use a bridge. To avoid duplication of work for the apps trying to bridge into a gatekeeper’s ecosystem, if the bridge connected into a common language such as Matrix or XMPP, only one bridge would need to be maintained for all Matrix/XMPP-based apps to interoperate with the gatekeeper.
In the longer term, gatekeepers may make the choice to implement an open standard to maintain end-to-end encryption when interoperating with all the other apps. Note that Messaging Layer Security (MLS) is only an encryption protocol and won’t solve the fact that two services don’t speak the same language (like WhatsApp and Signal today would need to decrypt and re-encrypt to interoperate despite both using the Signal Protocol for encryption).
Implementing interoperability
What are the main challenges with implementing interoperability for messaging apps ?
The main challenges are technical and around security.
Technically, interoperability means that some work has to be done to connect different apps together. Either a common language needs to be defined or bridges between different apps need to be built. But there are already examples of this working, especially around the Matrix protocol.
In terms of security, enabling messaging apps to interoperate needs to not put the end users at risk, either by undermining end-to-end encryption, or in terms of spam and phishing.
Or, to be more precise, the risks need to not outweigh the benefits gained by interoperability. The key thing if E2EE needs to be broken is to be transparent with the user, so they can make an informed choice between the benefit of the service brought by interoperability and their security.
For spam and phishing, the DMA may well be the missing incentive to eventually force the industry to work on more sustainable moderation techniques.
How can interoperability be implemented?
Two services can interoperate either if they speak the same language (protocol) or if they can translate each other's languages (APIs). There are four ways to achieve interoperability between two apps:
- One app speaks the language of the other
- A bridge acts as a translator between the two apps (optionally using a standard protocol as an intermediary)
- Two apps agree to use a third-party protocol (usually an open standard like Matrix or XMPP, as it will be independent and may give access to other apps)
- A mix of 2 and 3 where one app may decide to implement an open standard which is already bridged to the other app
Option 1 - Same protocol
So for the first option where one app adapts to the others: if I wanted to develop an app focused on accessibility (e.g. big font, first-class screenreader support, streamlined navigation or similar) that gives them access to their families who are on WhatsApp, then I can just look at the API WhatsApp is providing and use it to build my app. It will then speak the same language and be fully interoperable with WhatsApp (but only WhatsApp) - and fully preserve end-to-end encryption.
Option 2 - Bridges
The first option is pretty easy to implement if the new app doesn’t exist yet, but if the two apps already exist then this second option comes into play. One of the apps (usually the one requesting interoperability) will have to locate a bridge which translates its own protocol into the one used by the gatekeeper (optionally going via an intermediary open standard like Matrix, to avoid needing different bridges for each combination of platforms). Again this will give it access to only this gatekeeper.
Option 3 - Open standard
The third option would require both apps to be converted to talk the third-party protocol (e.g. Matrix or XMPP). They could do so either by implementing it natively (which can be a relatively short job when embedding a bridge, or a longer job if the open protocol replaces entirely the app’s own protocol), or by adding a bridge on the edge of their network.
Option 4 - Bridging to an open standard
And finally if a bridge to one of the apps exists into an open standard, the other app can either implement the open standard or bridge to it.
The good thing about open standards is that they give access to many other apps, either directly or via a bridge, so once an app has done the work to speak the standard they don’t have to do it again to access other apps using the standard or bridging into it.
To some extent there is a fifth option where the gatekeeper could also have the option of supporting both the open standard and its existing protocol in what are called “multihead messengers”. It would allow them to have differentiating features only available on their native chats, without preventing users from interoperating, but it’s quite a burden to maintain.
What are the pros and cons of each implementation option?
| Effort for the Gatekeeper* | Effort for the requesting service | Is E2EE preserved? | Does this option give the requesting service access to other apps? | User discoverability | |
|---|---|---|---|---|---|
| Speak the gatekeeper’s protocol | None | Medium/large depending on the complexity of the protocol. Easier if the app doesn’t exist yet. | Yes | No | Simple, as one just uses the gatekeeper’s system |
| Bridge to the gatekeeper’s protocol | None | Medium/large depending on complexity of the protocol. | Yes, if the bridge runs on the client. No, if runs server side | Maybe, depending on the bridges’ capabilities | For 1:1s, just ask the user which provider to use to talk to the other user.
For group chat, use a decentralised identity lookup service (many options are currently being developed) |
| Both adopt an open standard | Small to large depending on the standard. (1 person during 1 month for Gitter to adopt Matrix; migrating an E2EE messenger would be harder. | Small to large depending on the standard. (1 person during 1 month for Gitter to adopt Matrix); migrating an E2EE messenger would be harder. | Yes | Yes | For 1:1s, just ask the user which provider to use to talk to the other user.
For group chat, use a decentralised identity lookup service (many options are currently being developed) |
| Gatekeeper is bridged to an open standard, requesting service implements the standard | None. Someone else would have done the bridge | Small to medium depending on the standard. (1 person during 1 month for Gitter to adopt Matrix) | Yes, if the bridge runs on the client. No, if it runs server side | Yes | For 1:1s, just ask the user which provider to use to talk to the other user.
For group chat, use a decentralised identity lookup service (many options are currently being developed) |
* Assumes the gatekeeper has already exposed its APIs, as required by DMA
How far are we from interoperability becoming a reality?
By the end of 2022 the aim is to have implemented interoperability for 1:1 text messaging and 1:1 file transfer. By the end of 2024 the aim is to have implemented interoperability for group messaging and group file-transfer. Interoperability for 1:1 voice/video calling and group voice/video conferencing will be coming down the line.
In practice, some level of interoperability already exists today thanks to “adversarial bridging” implemented using non-official APIs, like Element does. Similarly, as soon as gatekeepers open their APIs we will be seeing a flurry of new services providing interoperability. The user experience may not be as seamless as we would hope for at first, but better than nothing.
Understanding ‘bridging’
What are the security concerns with ‘bridging’?
If the service lacks end-to-end-encryption (Slack, Teams, Google Chat, non-secret chats on Facebook Messenger, Instagram, Google Messages etc) then the bridge does not reduce security or privacy, beyond the fact that bridged conversations by definition will be visible to the bridge and to the service you are interoperating with.
If the service is end-to-end encrypted (WhatsApp, iMessage, secret chats on Messenger) then the bridge will necessarily have to decrypt (and reencrypt, where possible) the data when passing it to the other service. This means the conversation is no longer end-to-end encrypted, and thus less secure (the bridge could be compromised and inspect or reroute their messages) - and so gatekeepers must warn the user that their conversation is leaving their platform and is no longer E2EE with something like this:
For instance, WhatsApp already shows similar UI (albeit not warning that E2EE has been removed) when users talk to a business via the WhatsApp business API.
The user may find the trade-off acceptable in some cases. The key thing is to be transparent and warn them when end-to-end encryption is broken, so they can make an informed choice.
If the DMA requires remote users to have the same security as local users, how can bridges work?
The DMA requires that the APIs expose the same level of security to remote users as for local users - i.e. the end-to-end encryption part of the API must be exposed. If the users in a conversation choose to use a bridge and thus decrypt the messages, then it is their choice to trade off encryption in favour of interoperability for a given conversation.
Does bridging undermine encryption in the gatekeepers’ app?
Absolutely not. Users talking to other users within the same end-to-end encrypted gatekeeper’s app will still be end-to-end encrypted (assuming the gatekeeper maintains it) - and in fact it gives the gatekeepers an excellent way to advertise the selling point that end-to-end encryption is only guaranteed when you speak to other users on the same platform.
Wouldn’t E2EE be preserved if all messaging apps shared the same underlying protocol?
Yes. But practically speaking, the EU can’t mandate the gatekeepers to throw away their existing protocols (or implement multihead messengers that also speak open protocols). So whilst it is true that if they natively spoke Matrix or XMPP then the re-encryption problem would go away, it is more realistic to focus on opening the existing APIs. Perhaps in the future some players will adopt an open standard like Matrix of their own volition.
E2EE Concerns
Could end-to-end encryption work from one messaging app to another?
End-to-end encryption will be preserved if the clients (i.e. mobile apps, web apps, etc. of the two services speak the same protocol.
It can be achieved if:
- The app requesting interoperability implements fully the protocol of the gatekeeper
- Both apps implement the same open protocol instead of (or as well as) their current separate protocols.
- The bridge to the gatekeeper is run client-side (i.e. in the app itself rather than on the server) by the app requesting interoperability, but it would need more work (see next question).
Can you make bridges safer by running them client-side?
Yes, but today most bridges are not built for it and would need some improvement. The idea of end-to-end encryption is that only the devices participating in the conversation can decrypt messages, so the messages are already exposed on the user’s device, which means that E2EE isn’t broken if the bridge runs on said device - this avoids decrypting them on a server.
Current iMessage bridges (like the open source iMessage bridge run by the Matrix community) are examples of client-side bridges. They work by running iMessage on a local iPhone or Mac and then re-encrypting the messages there before sending them to the remote user (i.e. the person not using iMessage). There is lots of development happening in this space and, with open APIs guaranteed by the DMA, the work in this area should be able to speed up significantly. The main obstacle to client-side bridge development has been the lack of reason to try to build them, in a non-DMA world!
User discovery
How can you find the person you want to message if you aren’t using the same app as each other?
The platonic ideal of interoperability in terms of real-time messaging would be as follows…
Alice is on one app and she wants to talk to Bob who is on another app. Alice doesn’t want to think about which app Bob is using. With email this situation is solved by knowing Bob’s email address. But in the world of real-time communication the current set-up of closed applications has set different expectations. Currently Alice expects Bob to be discoverable on a given app because the app has access to her contacts and has mapped Bob’s phone number or email to its database of users.
To provide this experience to the users in an interoperable world, we would need a system providing the same mapping so any application knows which identifiers (phone or email) are linked to Bob and which chat app Bob is using. But all of this is very sensitive information and there is no single central entity we can trust with the entire world’s database of identifiers! So ideally it would be decentralised across trusted services. However decentralised identity is still an emerging technology, which is why some DMA critics claim interoperability is not feasible. However, DMA is precisely the incentive needed to take decentralised identity mainstream - the main lack of progress has been lack of motivation in a non-DMA world!
So in the meantime, we have to work around it with the experience provided to the user.
For 1:1 chats this is easy: Alice can simply ask Bob which service he is using, that way she knows where to find Bob.
© Matrix.org
To some extent, this is what we do today, except today Alice would have to install and register to BobChat to talk to Bob or vice versa. In an interoperable world they don’t have to change applications or create another account.
For group chats it is harder, and this is why the deadline for group chats in the DMA is years away. The problem is that you need a way to verify the identity of all the users in a group on different platforms - effectively looking up and mapping their identity in a secure manner which stops services from maliciously spoofing identities.
One possible way to solve this would be for users to explicitly link their identity on one service with the one on the gatekeeper’s service - e.g. if at one point Bob has explicitly said that in AliceChat his identity should be mapped to his identity in BobChat, then Alice doesn’t have to validate him herself. It also gives Bob a way to block himself from ever being unwittingly bridged to AliceChat.
Another approach would be for service providers to publish attestations which prove ownership for each user of a given identifier (e.g. proving that a given user is on the service using a given phone number, signed with that user’s personal identity key). Such attestations could then be tracked in a decentralised index, providing a way to look up ways of contacting a given user - similar to Keybase’s original vision, but decentralised.
There are many other approaches too - and the onus is on the industry to figure out the best solution for decentralised identity in the next 3-4 years in order to realise the most exciting benefits of the DMA and ultimately provide the best experience for the end user. Real-time communication has been allowed to spiral into a situation where it ‘belongs’ to a small number of primarily silicon valley-based tech companies. The DMA is an opportunity to wind back that vice-like grip and put freedom back into the hands of the users - just like it has always been with telephones and emails.
