One question I'm often asked is what metadata Matrix leaks. It does get tiring answering the same questions, so I'm creating an article I can simply link to any time someone asks.

I am on record many times saying Matrix leaks metadata. However, one thing that many people fail to understand is exactly what Matrix leaks, and why.

Note: For the purposes of this article, it's assumed users are communicating using end-to-end encryption (E2EE). In non-E2EE rooms, you can expect everything mentioned here to be leaked, as well as actual message contents.

What is a metadata leak?

Metadata leaks are when your messaging app includes metadata in a way that's not encrypted end-to-end. This includes the dates and times you send messages, who you send them to, how frequently you send messages, and more. Many messengers allow you to set status messages and profile pictures. These are not encrypted, and are thus leaked. The issue with metadata leaks is they can fairly easily reveal sensitive information, even when you don't expect them to.

What metadata does Matrix leak?

Matrix supports end-to-end encryption (E2EE). This protects the contents of messages, such that nobody can read them except the intended recipients. E2EE can be enabled manually in Matrix rooms, but is also enabled by default in 1:1 chats (DMs). Some clients may not enable E2EE by default, so you should always verify whether messages are sent E2EE.

Matrix's E2EE does not, however, encrypt everything. The following information is not encrypted:

To demonstrate some examples of these leaks, I have made some examples available:

Who can view metadata?

The following metadata can be seen by any homeserver with at least 1 member in an E2EE room:

The following information is publicly available:


Why does Matrix leak metadata?

Federated networks are naturally more vulnerable to metadata leaks than P2P or centralized networks. These leaks can be fixed, at the expense of increased complexity of the protocol (thus making it more vulnerable to faulty implementations). Matrix's failure to prevent these leaks is necessary for proper functioning of the protocol.

Some metadata must be leaked due to features Matrix provides. For example, Matrix's message verification requires knowing which user and device sent a message (to know which key to verify with). In other cases (such as global profile pictures and nicknames), the information is considered public anyway, and therefore has no need to be encrypted. Matrix's failure to prevent these leaks is a triviality.

Some metadata leaks are accepted for performance requirements. For example, message reactions and read receipts might not be encrypted because Matrix's E2EE is slower than normal (non-E2EE) messaging. Encrypting reactions and read receipts could provide a painful user experience (UX). Matrix's failure to prevent these leaks is a design feature.

Some metadata leaks are simply a matter of the protocol's failure to consider them. For example, room-specific nicknames, room-specific profile pictures, and message edit events could all be encrypted without breaking the protocol. Matrix's failure to prevent these leaks is a design flaw.

Note: Though edit events are leaked, message contents are not.

All original non-code/non-software content is committed to the public domain, except where otherwise explicitly stated. Code/software is licensed under the BSD 3-clause license, except where otherwise explicitly stated. Content not originally created by Serpent Security may be subject to separate licensing terms.