Privacy considerations of interoperable end-to-end encrypted messaging

The wide deployment and use of end-to-end encrypted messaging has raised the bar for secure communication — a significant portion of online communication today cannot be accessed by intermediaries tasked with transporting messages between users. The secure messaging ecosystem, however, is significantly fragmented — user bases are divided between dedicated messaging apps (e.g., Signal, WhatsApp and iMessage), social media platforms (e.g., Facebook Messenger, X Chat, Mastodon) and group messaging apps (e.g., Slack, Teams, Matrix). While each of these applications serves a specific purpose and user base, they also create lock-in — users are confined to silos, making it difficult to communicate with users of different messaging services and to switch between them. Secure messaging advocates are now developing mechanisms for different messaging services to interoperate while maintaining the security guarantees of end-to-end encryption.

More Interoperable Instant Messaging, or MIMI, is a working group at the IETF formed to develop an interoperable messaging protocol. It is working on specifications that would allow users of different messaging providers to identify, reach and exchange messages with each other. MIMI builds on the Messaging Layer Security (MLS) standard to establish confidential end-to-end encrypted communication, and joins other efforts, such as the RCS and ActivityPub protocols, to do so. MIMI’s work has coincided with the EU’s Digital Markets Act (DMA), which directed designated online messaging service providers to enable interoperability on their platforms. Discussions in the working group have slowed down since the DMA enforcement deadline passed in 2024 and the group now awaits implementations to emerge.

Interoperability can improve privacy by allowing users of less private messaging providers to move to more privacy-respecting alternatives, while still being able to communicate with users who choose to remain. The converse is also true — interoperability can enable privacy-invasive services to gain prominence, highlighting the need for carefully designed standards that maintain user privacy in interoperable messaging scenarios and for continuous evaluation of deployments. We explain the MIMI protocols and summarize key privacy considerations discussed by the working group in order to inform efforts to enable secure interoperable messaging.

How MIMI works

We describe MIMI’s design as specified in the current set of documents adopted by the working group, all of which remain in the draft stage at the time of writing. MIMI relies on the Messaging Layer Security (MLS) standard for key establishment, authentication and ensuring confidentiality of messages in a group setting. MIMI adds an interoperability layer on top of MLS by defining standards for identifying and discovering users across disparate messaging providers and exchanging messages between them.

Every conversation in MIMI is represented as a “room”. Communication between two users is considered to be a room with two participants, and a group chat can be a room with many participants, with each of them possessing one or more participating clients (i.e., user devices). In an interoperable setup, each participant in a room can be affiliated with a different messaging provider. A message between participants of a MIMI room traverses three messaging providers: the sender’s messaging provider, a “hub” provider, and the receiver’s messaging provider. While MIMI is silent on how messaging providers communicate with their own users, messages between providers must pass through the hub, which is one of the messaging providers in the room, chosen to coordinate its activity.

The hub is responsible for coordinating room policies, membership and message ordering for the room. A room’s policies can include administrative operations like who can join, who can send messages, what functionalities are available to the room, and the delegation of these responsibilities among participants. They are defined and enforced by the hub, set by the creator or administrator of the room at the time of creation, and can be examined by its members when they join the room.

Privacy considerations in a federated messaging setup

With end-to-end encryption becoming a default in secure messaging apps and protecting the contents of messages, the privacy focus moves to metadata minimization. In a federated setup, the presence of multiple messaging providers runs the risk of metadata accumulating with multiple parties. While metadata is a necessary by-product of delivering messages, it often reveals private information about users, including the participants in a group, their affiliations with different messaging providers, online status, the timing and frequency of communication between group members, and information about the types of content being shared (e.g., large files, videos) between them.

The authors of MIMI have designed a few protections to keep messaging providers from learning about the participants in a room. SemiPrivateMessages is a proposed MLS extension that hides information about room membership from providers other than the hub by encrypting handshake messages to the group members and the hub alone. The hub, in its role as the room host, is privy to more metadata than other messaging providers represented in the room. Minimal metadata rooms is a construct that seeks to hide knowledge of room membership from the hub by assigning pseudonyms to participants that the hub can use to forward messages — the design of this portion has not been fully fleshed out. While regular messages transit through the hub, MIMI envisions that larger messages like images and videos remain hosted by the sender’s messaging provider due to resource constraints. To prevent revealing information about message recipients in such cases, MIMI suggests proxying downloads through the hub or using OHTTP to download messages anonymously.

A key privacy consideration in the design of secure messengers is how messaging providers assert their users’ identity and the identifiers users utilize to address one another. Common identifiers in secure messaging services include phone numbers, email addresses and different types of user handles, some of which can be pseudonymous in nature. In the centralized secure messaging applications prevalent today, messaging providers are still trusted to provide a true identity for the “ends” and not to add or remove participants from end-to-end encrypted conversations. Messaging providers have developed manual and semi-automated ways for users to verify the identities of people they are conversing with out of band, but users do not always perform the verification. This issue is exacerbated in a federated messaging setup as a user has to trust not only their own messaging provider but also all the providers represented in a room to provide a true identity of their users. The questions of user identity and identifiers are largely open in the MIMI working group. Two individual submissions discussed by the group explore the problem space, surveying ways for users to manage and assert their identity independently of their messaging providers and choosing identifiers that allow users to communicate anonymously.

A related problem to user identity is user discovery. An interoperable messaging system must grapple with how users enrolled with messaging providers are discovered and who is permitted to communicate with them. The MIMI working group has specified an opt-in process allowing users to choose whether they want to be reached by someone who knows their user handle. User lookup operations in MIMI bypass the hub to prevent it from learning about who a particular user wants to communicate with. The design process in the working group has surfaced some complex discovery scenarios that are unique to federated messaging systems — a user may be enrolled with multiple messaging providers participating in a federated system and may prefer to be reached through a particular provider in one context while not revealing their affiliation with a provider in another context.

Though these privacy considerations are being discussed in the working group, most of them remain optional in order to maintain compatibility with a wide range of messaging providers and enable their participation in the federated system. Any deployment that may emerge from these standards would need to navigate these privacy configurations in addition to the complex dynamics of interconnection that would arise between different messaging providers.

Where this leaves us

Two years after the DMA’s messaging interoperability requirement came into effect, the solutions offered by big tech companies leave much to be desired. WhatsApp offers a centralized way to interoperate through its API, which requires that participating messaging providers reveal user IP addresses to Meta, disallows message buffering by providers, and is restricted to users located in the EU. Apple and Google have enabled interoperable messaging between iMessage and the Google Messages app over the Rich Communication Services (RCS) protocol, but this requires support from the users’ mobile carriers and is restricted to using phone numbers as the user identifier.

These efforts serve as an encouraging demonstration that it is possible to build secure messaging systems that can also interoperate, but highlight the need for a greater level of engagement with the design and privacy tradeoffs of such systems. Regulators and interoperability advocates must articulate a more granular set of requirements from these systems to ensure privacy-respecting outcomes, and not leave the details up to the implementers.

This blog post was written by Divyank Katira.