- cross-posted to:
- matrix@lemmy.ml
- cross-posted to:
- matrix@lemmy.ml
Some interesting notes on the Matrix protocol, its limitations and comparison with IRC.
A few crucial quotes, as the article itself is voluminous (but very exhaustive!):
Compare this to Matrix: when you send a message to a Matrix homeserver, that server first stores it in its internal SQL database. Then it will transmit that message to all clients connected to that server and room, and to all other servers that have clients connected to that room. Those remote servers, in turn, will keep a copy of that message and all its metadata in their own database, by default forever. On encrypted rooms those messages are encrypted, but not their metadata.
In a federated network, one has to wonder whether GDPR enforcement is even possible at all. But in Matrix in particular, if you want to enforce your right to be forgotten in a given room, you would have to:
- Enumerate all the users that ever joined the room while you were there
- Discover all their home servers
- Start a GDPR procedure against all those servers
Overall, privacy protections in Matrix mostly concern message contents, not metadata. In other words, who’s talking with who, when and from where is not well protected. Compared to a tool like Signal, which goes through great lengths to anonymize that data with features like private contact discovery, disappearing messages, sealed senders, and private groups, Matrix is definitely behind.
This is a known issue (opened in 2019) in Synapse, but this is not just an implementation issue, it’s a flaw in the protocol itself. Home servers keep join/leave of all rooms, which gives clear text information about who is talking to. Synapse logs may also contain privately identifiable information that home server admins might not be aware of in the first place. Those log rotation policies are separate from the server-level retention policy, which may be confusing for a novice sysadmin.
Combine this with the federation: even if you trust your home server to do the right thing, the second you join a public room with third-party home servers, those ideas kind of get thrown out because those servers can do whatever they want with that information. Again, a problem that is hard to solve in any federation.
So while you can workaround a home server going down at the room level, there’s no such thing at the home server level, for user identities. So if you want those identities to be stable in the long term, you need to think about high availability. One limitation is that the domain name (e.g. matrix.example.com) must never change in the future, as renaming home servers is not supported.
As a developer, I find Matrix kind of intimidating. The specification is huge. The official specification itself looks somewhat digestable: it’s only 6 APIs so that looks, at first, kind of reasonable. But whenever you start asking complicated questions about Matrix, you quickly fall into the Matrix Spec Change specification (which, yes, is a separate specification). And there are literally hundreds of MSCs flying around. It’s hard to tell what’s been adopted and what hasn’t, and even harder to figure out if your specific client has implemented it.
Just taking the latest weekly Matrix report, you find that three new MSCs proposed, just last week! There’s even a graph that shows the number of MSCs is progressing steadily, at 600+ proposals total, with the majority (300+) “new”. I would guess the “merged” ones are at about 150.
I’m also worried that we are repeating the errors of the past. The history of federated services is really fascinating:. IRC, FTP, HTTP, and SMTP were all created in the early days of the internet, and are all still around (except, arguably, FTP, which was removed from major browsers recently). All of them had to face serious challenges in growing their federation.
IRC had numerous conflicts and forks, both at the technical level but also at the political level. The history of IRC is really something that anyone working on a federated system should study in detail, because they are bound to make the same mistakes if they are not familiar with it.
This is not true. In a federated network like XMPP your server anonymizes a lot of metadata that is generated by you connecting to the server, but not passed further on to other servers. Of course more meta data is shared than in a system that doesn’t talk to other servers at all, but it is definitely less than in a system that relies on direct p2p connections or multiple relays.
If a server is hosting our data, albeit in encrypted form, there is always the risk of the server being compromised. You know the history of PGP and why OpenPGP was created, don’t you?
One of the options, where every user device is a server, is a blockchain. But I think you’ll also agree that this scheme doesn’t give complete privacy.
The issue of privacy in this case is a convenience issue. To me, federated is not a checkbox type property: it’s either there or it’s not. To me, it’s a spectrum: some protocol is more federated, some less so. We could design a fully privacy-aware protocol and service that can only partially be considered as federated. You may disagree with me, but I haven’t seen a clear definition with a complete list of federated protocol properties 😉
I think ultimately it is a trust issue. There is no such thing as trust-less communication and you need to carefully consider who you trust with relaying your communication data.
In the classical federation model that XMPP uses you need to put a fairly high amount of trust on the server you have an account on, but then that server can shield you from most of the privacy violations and you can interact fairly privately using a pseudonym that can not be easily linked to your real identity by anyone other than that trusted server.
If you move to more p2p or relay based models, then you directly share a lot more metadata with more 3rd parties and those 3rd parties are usually completely in-transparent about why and how they participate in the network. If you are a info-sec expert, you can in theory optimize such networks to get a high level of privacy, but it is full of hidden footguns that can easily make you more vulnerable to privacy invasive tracking of metadata like IP addresses that can be easily linked to your real identity.
On the other end of the spectrum you have centralized services like Signal, that (if you trust them) can also offer a high level of privacy, but due to their centralisation they have a large target painted on their back and there are a lot of hidden incentives/forces for such centralized service providers to compromise your privacy often without you even realizing it.
Sounds reasonable! 👍