We Abandoned Matrix: The Dark Truth About User Security and Safety (2024)

WE HAVE MOVED TO SIMPLEX Anyone that agrees to our Code of Conduct is welcome to join our Simplex Hack Liberty Community Room and our Simplex server , a decentralized, metadata resistant alternative to Matrix! Incognito profiles welcome! Why Federation Must Die The appeal of federation lies in its potential to empower individuals, groups, and communities by enabling the use of open-source software and facilitating decentralized interactions across servers. This model offers a degree of censorship resistance, as the messages or images are replicated across multiple servers, making it difficult for any single entity to censor or control the content. However, after over two years of administrating public federated services (Matrix, Lemmy), I’ve learned first hand the fundamental problems associated with the design of all federated protocols. Problems with Matrix (Protocol) Metadata Leakage From serpentsec.1337.cx/matrix : 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. Matrix’s E2EE does not, however, encrypt everything. The following information is not encrypted: Message senders Message senders are never encrypted Due to Matrix’s design, encrypting session/device IDs would break verification It’s impossible to prevent timestamps from leaking, since the server can simply note when an event is received anyway Join/leave/invite and other room events are never encrypted While contents are not leaked, an attacker can know when messages are edited Reactions are never encrypted Read receipts are never encrypted Nicknames are never encrypted Profile pictures are never encrypted To demonstrate some examples of these leaks, I have made some examples available: https://snippets.serpentsec.1337.cx/matrix-metadata-leaks Admin in the Middle From What a malicious matrix homeserver admin can do : Passive information gathering There’s a lot of passive information gathering a malicious admin can do just by querying the Synapse database and this can happen retroactively. Some of the (meta)data include: Chat history of any unencrypted room (duh!) Information about the...

Preview: ~500 words