We Don’t Have to Sacrifice Encryption to Achieve Messaging Interoperability

In late March, the three arms of the European Union’s government—the European Commission, European Council, and European Parliament—reached agreement on implementation details regarding the Digital Markets Act (DMA), which became law in December of 2021. The DMA contained high-level language regarding platforms’ obligation to allow separate software systems to interact with each other and exchange information—known as “interoperability”—and the new agreement has gone into (somewhat) deeper detail.

In simple terms, the agreed-to language would require large online platforms that offer instant messaging capability, such as WhatsApp, Apple iMessage, or Google Meet, to allow other messaging services to send and receive messages to and from their users, if the other service requests such access. The requirement only applies (for now) to one-to-one messages—not group chats. The EU believes that increased competition amongst the large online platforms is needed, and interoperability gives users the chance to move providers without having to worry about the network of friends and family that would become inaccessible. Reducing the importance of these “network effects” also makes entering the market much more accessible for new services, as they would no longer have to fight an uphill battle against the larger platforms.

The release of the agreement drew criticism, however, from another group of digital rights activists. Advocates dedicated to increasing access to end-to-end encryption (E2EE) have criticized the rules out of a concern that messages that travel from one service to another would lose the benefit of end-to-end encryption. The worry is that the WhatsApp client application on one person’s phone is not going to know how to encrypt a message in a way that the Google Chat app on another’s phone can decrypt successfully.

On the surface, that makes perfect sense. How could a messaging service build an app capable of decrypting messages coming at it from potentially any service? Encryption schemes are complex, and each service that implements E2EE likely does so differently than every other. It would be a large burden, not to mention an invitation to bugs and security failures, to expect every service to implement every other service’s scheme. The obvious pragmatic solution would be to give up on E2EE—at least for messages traveling across services.

Getting past this reasoning requires taking a step back and approaching the problem with a collaborative process. What would work best for the actual people that use all these services is both interoperability and end-to-end encryption. To achieve that, the services will need to work together for the benefit of everyone to establish a common protocol for encrypting and decrypting messages traveling across services.

This isn’t radical: it’s how the internet has operated since its earliest days. The protocols that drive everything from how electrical pulses travel across wires to email and the world wide web are developed collaboratively by people who then go out and use them to build the platforms and products we enjoy every day.

Perhaps it isn’t a surprise, therefore, that one of the standards organizations, the Internet Engineering Task Force (IETF), has been working on a draft specification that solves one of the big problems at the intersection of encryption and interoperability. Messaging Layer Security (MLS) is a protocol specification that describes how messaging clients can work together to maintain end-to-end encrypted communications. It’s been under development by a broad range of people, including academics, civil society, and representatives from Cisco, Google, Mozilla, and Facebook. Once it reaches final publication, which should be quite soon, it will provide an agreed-upon method for different services’ apps to encrypt messages such that any other service’s app can decrypt them—as long as it has the correct decryption key, of course.

What’s more, the MLS community is also building implementation libraries that platforms can use to include MLS capability in their own apps without even having to do the in-depth cryptographic coding themselves. These open-source libraries can be publicly audited and easily updated if needed, and all of the platforms using these libraries will benefit from those updates.

Similarly, Google and a number of the wireless phone providers have been working together on a specification to replace SMS and MMS called Rich Communications Services (RCS). RCS—which Android and a number of mobile carriers have already rolled out—supports end-to-end encrypted messages across platforms and carriers, as well as functionality, such as emojis.

One important note, however, is that the kind of collaborative work we’re talking about here takes time. The first draft of the MLS specification was published in August of 2019, and was in planning even before that. It is only now approaching final publication. RCS saw initial development start in 2007, and real concerted work only began in 2018. The EU will want to consider its timeline for implementation of the DMA’s interoperability provisions, which currently calls for compliance within six months, in that light. It would be better for covered platforms to work together to make encrypted messaging interoperability work, rather than scrambling to deliver immediate interoperability that destroys privacy. Doing something right takes time.

MLS also isn’t a complete solution. It describes how to use cryptographic keys to encrypt a message for a given recipient, but it doesn’t address other questions, such as how to find your friend’s public key (often referred to as the “key distribution” problem), what service and what username to use for a given person (which is a broader issue wrapped up with questions of digital identity), or even how to deliver messages from one service to another. Encryption advocates have pointed to these problems as further reasons why interoperability and encryption are incompatible.

Fortunately, what MLS does give us is a template for how to tackle those problems: collaboratively. By working together at organizations such as the IETF and the World Wide Web Consortium (W3C), the community of messaging platforms can address the other issues raised by messaging interoperability in ways that benefit the everyday people that use the various services. Indeed, communications projects focused on interoperability, such as the Matrix project, are already thinking about these other issues. (Editor’s note: the author serves as a member of the board of directors of the Matrix Foundation, a non-profit focused on overseeing the protocol’s specification and promoting Matrix).

None of these problems have neat or simple solutions, and they all have vested interests attached to them that will try to sway conversations in one way or another. But neither are they intractable. We can take a deep breath and follow the collaborative example of most of the protocols that underpin the entirety of the internet, including MLS. Doing so will lead to solutions that improve the internet for everyday people without compromising the privacy protections they deserve.