This posts is a list of all the suspicious things Matrix/New Vector and Element (which is run by Matrix employees) have done.
Crossposted to c/opensource from c/privacy.
I want to start a civil discussion on this topic, if anyone has improvement ideas for the list or wants to debate one of the bullet points for removal, I’m all ears.
Matrix leaks lots of metadata, in many cases not fixed to date. The homeserver can and does store lots of metadata.
Even if you run your own instance, it still sends data to the main homeserver.
The Cloudflare Situation
All research on the Cloudflare situation is done by me.
If you check the SSL Certificate for https://element.io you’ll see it’s by Cloudflare.
Cloudflare has MANY privacy issues, and just wanting to centralize the web.
The Element client is the most used client, with many users using the default instance, because it’s easy or they want to simply join their friends or a community on Matrix easily. This comes as worrying because Cloudflare decrypts TLS traffic and this is even more worrying because Cloudflare is a honeypot.
Even if Cloudflare cannot decrypt anything because of the Matrix protocol encrypting them beforehand, lots of metadata in the message itself is send over plaintext like who you’re talking with, channel name etc. (and this is excluding the metadata leaks that Matrix has to the main homeserver and in general). Of course, this could be mitigated by using Element on another instance that isn’t behind Cloudflare, but the average user will not know to do that or even understand the concept of federation and decentralization.
Cloudflare’s CDN can be used without using their SSL certificate which just backdoors your site, so why is Element using it? Element is run by the same people that are behind matrix.org (mostly), so they know how to do basic privacy features.
Even if we assume there’s no ill intent here, Cloudflare just wants to centralize the web (~30% of SSL traffic goes through Cloudflare, ~80% of CDN traffic goes through Cloudflare), which is obviously against Matrix’s mission of decentralized communication.
Through Cloudflare, an adversary with ill intention could target a Matrix user and be susceptible to metadata collection.
I’ve took this argument in the official Matrix channels, and no one has been able to properly respond to the arguments presented. Though, they were only members, no admins were involved.
If anyone wants to bring these issues forth to the official Matrix admins, I’d be more than glad to help. Thanks for reading!
The metadata leaking is a problem with every federated system, xmpp included. You could even call the metadata leaking a feature, not a bug, since its what makes federation possible.
The problem is not mainly the leaking metadata, but that the Matrix protocol is designed to indefinitely store and freely share this metadata with every home-server joining (which even gets a full copy of everything retro-actively). XMPP does not do this.
XMPP only does this on the single server the room resides on and does not share this info with other participating servers except for the bare minimum needed to show the users nick names.
I recommend you hosting your own Matrix home server and after joining a few federated rooms look at your database what kind of historical metadata ends up on your new server. It’s honestly appalling from a privacy point of view.
Yes this is needed for room persistence across multiple servers, but IMHO that is a solution looking for a problem and also a highly over-engineered one.
Yes this is needed for room persistence across multiple servers, but IMHO that is a solution looking for a problem and also a highly over-engineered one.
Without this solution the transition to p2p would be much more complicated, would it not?
The problem is not mainly the leaking metadata, but that the Matrix protocol is designed to indefinitely store and freely share this metadata with every home-server joining (which even gets a full copy of everything retro-actively). XMPP does not do this.
How does xmpp not store information about federated users joining a room?
XMPP only does this on the single server the room resides on and does not share this info with other participating servers except for the bare minimum needed to show the users nick names.
I recommend you hosting your own Matrix home server and after joining a few federated rooms look at your database what kind of historical metadata ends up on your new server. It’s honestly appalling from a privacy point of view.
Yes this is needed for room persistence across multiple servers, but IMHO that is a solution looking for a problem and also a highly over-engineered one.
There’s ongoing work to encrypt much of the metadata. https://github.com/matrix-org/matrix-doc/pull/3414
Without this solution the transition to p2p would be much more complicated, would it not?