The three main EU institutions are expected to meet next week for the 4th trilogue for the Digital Markets Act (DMA). The French presidency has been pushing everyone hard to iron out the last disagreements in order to meet the self-set deadline of the end of March.
Targeted advertising, interoperability and adapting the regulation to the ever-moving digital markets are still the most controversial subjects but Andreas Schwab, the rapporteur for the act, is confident the deadline is achievable.
The latest position seems to be that whilst interoperability is still on the menu (which wasn’t necessarily the case a couple of weeks ago), and requiring end-to-end encryption to be preserved, it looks to have been limited to one-to-one interactions – leaving aside the far bigger chunk of group chats and calls. The reason given is: “Interoperable end-to-end encrypted group chats are technically not feasible.”
That assertion is not correct.
Interoperable end-to-end encryption for group chat
End-to-end encryption means only the devices involved in a conversation can read it. The servers relaying the conversation have no visibility of the content. Interoperable means that users from different communication services can communicate with one another.
From a basic use case perspective, end-to-end encrypted group chats have been supported for years by many services and protocols including WhatsApp, Matrix, XMPP, Wire, Signal, Threema and others. Signal’s Double Ratchet algorithm is available in the public domain and both Matrix’s Megolm protocol and XMPP’s OMEMO protocol are even published as open standards, which means that they provide interoperability for end-to-end-encrypted group chats. So interoperable end-to-end encrypted group chats are not just technically feasible; they already exist.
It is true that end-to-end encrypted group chats (even closed, proprietary ones) bring another level of complexity, but one simple approach is to leverage end-to-end encrypted 1:1 communications to set-up the group communication; with the encryption keys for the group shared over the secure 1:1 links. This approach has been taken by Signal in the Signal Protocol and Matrix with Megolm. The downside is scalability. If there are tens of thousands of users in a group then you end up having to send tens of thousands of messages to synchronise the encryption. However it’s perfectly operable for group chats with well into thousands of participants.
Messaging Layer Security (MLS) is another encryption protocol being defined by the IETF which isn’t finalised yet. MLS proposes a more scalable option for encrypted group chats. Rather than each device sending keys to every other device, they pair up and exchange keys in a hierarchy to get to the same end result. But the idea is the same: build group encryption layered on top of 1:1 exchanges. MLS is not a complete game changer as every device still has to announce its existence to every other device when you join a group, but it’s further proof that interoperable end-to-end encrypted group chats are feasible. MLS is implemented by Cisco Webex, for example.
The key point is that whether an end-to-end encrypted chat is 1:1 or group is irrelevant when it comes to interoperability. If multiple services are interoperating in an end-to-end encrypted manner, they all need to speak the same language right down to the device.
There are only two ways to do this:
1. Open APIs: the requesting service implements the gatekeeper’s language
This means that anyone wanting to interoperate with, say, WhatsApp (for either 1:1 or group chat) will have to implement WhatsApp’s protocol and encryption. And if they also want to interoperate with, for example, Signal they will have to do it all over again. This method enables services to interoperate securely with gatekeepers one by one. The limitations are that it will be hard for these services to support chats (1:1 or group) which bring both WhatsApp and Signal users in the same discussion. Every device has to speak every language, but at least users have the building blocks to get at each other’s messages rather than then being arbitrarily locked away by the gatekeepers.
Another option enabled by open APIs is to use bridges, which will decrypt what is coming from one side and re-encrypt it with the other side’s protocol. This would provide encrypted communication but not end-to-end; whilst the communication is then encrypted for most of the time, the bridge becomes a potential point of failure. The end result is better than no encryption at all (which is actually all most services provide — Microsoft Teams, Slack and group chats in Telegram for example). It also alleviates the limitations of full end-to-end encryption via open APIs, as applications interoperating with gatekeepers can delegate the “translation” to the bridge. But it is still less secure than full end-to-end encryption.
2. Open standard: all services, including the gatekeepers’, speak the same end-to-end encrypted language
In this case every service only has to implement one language and will have access to every other service speaking the same standard. Users from different services can be brought together into the same chat (1:1 or group) in a completely secure manner with full end-to-end encryption. Existing open standards supporting end-to-end encryption include Matrix and XMPP.
To conclude: whether a chat is 1:1 or group is completely irrelevant to the feasibility of end-to-end encrypted interoperability. Interoperable end-to-end encrypted group chats already exist, and are used by millions of people via open standards like Matrix or XMPP. The simple first step towards the implementation of end-to-end encrypted interoperability (1:1 or group alike) is to mandate open APIs, but the longer term scalable and privacy-focused implementation would be via open standards.
Ian Brown is an interoperability researcher and visiting CyberBRICS Professor at FGV Law School.
