I see almost everywhere XMPP is good, secure, etc. And I personally love how it works.
But it’s not recommended on PrivacyGuides. Is it because it’s not easy for beginners or is there a security flaw I missed ?
The main reason is there is a massive differing in quality of clients, and what XEPs they support. Many actions are not E2EE, and it really depends on what client you’d be using.
The protocol itself was never really designed for privacy, and a lot of those features have been shoehorned in afterwards, https://web.archive.org/web/20211215132539/https://infosec-handbook.eu/articles/xmpp-aitm/
This was our previous reasoning:
3 Likes
To be honest, I don’t quite understand why Matrix passes this hurdle and XMPP does not.
Matrix is just as little designed for privacy as XMPP. Metadata is also generated, is also not E2EE (as far as I know) and is also distributed further by federation than in XMPP. The quality of the clients is also very differing.
I also see the advantages of Matrix and use it myself, but I find it quite interesting how an extra category was recently created to keep Matrix in the recommendations, although it does not support PFS, while XMPP was removed for reasons that also apply to Matrix to a large extent.
2 Likes
It is, maybe it depends on the client though, but Element does have E2EE :
I know that Element and many other Matrix clients support E2EE for messages, but not for metadata as far as I know. XMPP also has many clients that support E2EE for messages, but the criticism here was that metadata is not E2EE.
It is E2EE as long as you enable encryption on the room. With regards to the PFS issue see this: So... can PFS be enabled in Matrix at all? - #4 by exaCORE
Profile pictures, reactions, and nicknames are not encrypted.
Group voice and video calls are not E2EE, and use Jitsi […]
This is from the PrivacyGuides recommendations. I run a Synapse server myself and can retrieve a large amount of unencrypted metadata about users.
The call thing is correct for the time being, native Matrix E2EE calls are coming very soon (i think it’s implemented in Element X currently…). Regarding the metadata, that is true, hence why people should use trusted homeservers.
coming very soon
The same could be said about features for XMPP, many things are being developed (i think “coming soon” is an XMPP trademark since 2000). However, in my opinion, the current state of these two protocols is assessed differently here.
trusted homeservers
With XMPP, a trusted server can actually protect more than with Matrix, since Matrix distributes the metadata much more generously to all other servers involved. In both cases, however, these are federated systems and the own server is not the only one to be considered with regard to metadata.
1 Like
The main reason with XMPP is that direct messages aren’t necessarily encrypted, it depends on the client.
In regard to metadata they’re both in terms of federated data.
There is also quite a variety of XEPs that implement encryption in some places and not in others, and it’s really a mixed bag of what your client actually is.
We can recommend element, and know that DMs will be E2EE as will VOIP calls, in 1:1.
1 Like
There is also quite a variety of XEPs that implement encryption in some places and not in others, and it’s really a mixed bag of what your client actually is.
Why not recommend just a client like Conversations then? I think it ticks all the boxes, except for an audit
@anonymous159
Conversations can do OMEMO for message content, sent images/files, and can negotiate the DTLS-SRTP encryption for calls over that same OMEMO channel, but everything else is not encrypted.
The only client right now doing additional encryption for things like typing state and read marker events (via XEP-0420/SCE) right now is Kaidan, and that is very WIP.
Additionally and not necessarily that bad is that very few clients right now even implement the latest version of OMEMO because there is no interop/migration between the newer and older implementation of it.
The following is all not encrypted:
- user vcards
- user nicknames
- user profile pictures
- user rosters
- MUC names
- MUC descriptions
- MUC profile pictures
- MUC member list
- MUC member affiliations
- etc.
Also not all clients give sent files random names even when encrypted, which can allow the server to infer what it is.
(That being said I do still believe that XMPP does a lot of things really well, but my decade+ using it biases me to it.)
2 Likes
Also we don’t really want to be recommending a protocol based on the fact there might only be one mature client out there, especially over Matrix which as far as privacy goes negligible differences.
To put it another way, if Matrix only had Element on Android, we probably wouldn’t recommend that either. If Conversations was available on other platforms with equal maturity then the inclusion would have more relevance.
2 Likes
Thank you for your answer. The argument that Element is available for all platforms in almost the same quality makes sense.
I wrongly assumed that Matrix would be recommended. With that in mind, the exclusion of XMPP (clients) makes more sense to me than the sources linked at the beginning of the thread.