Why not XMPP?

Site Development Tool Suggestions
1

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 ?

1 Like
2

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:

4 Likes
3

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
4

It is, maybe it depends on the client though, but Element does have E2EE :

5

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.

6

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

7

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.

8

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.

9

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
10

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.

2 Likes
11

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

12

@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.)

5 Likes
13

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
14

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.

15

Isn’t Kaidan backed by the KDE development team? Also, even with all its flaws and limitations, isn’t this client/XMPP an interesting commendable real time messenger as much as some other options?

Isn’t Kaidan available in other platforms? Including Linux, Windows, macOS, Android, Plasma Mobile and Ubuntu Touch. Notably missing iOS.

Not sure if there are more XMPP clients that deserves a look. There is this AstraChat that seems to be available in multiplatforms.

Edit: I don’t think there are other clients that deserves a look other than Kaidan. Like @SkewedZeppelin mentioned it is the one along with Moxxy client offering the XEP-0420/SCE and Moxxy is Android only.

16

@Cyber-Typhoon because the version of OMEMO that Kaiden uses is not backwards compatible with the one most other clients implement.

1 Like
17

I think this point may not be necessarily that bad, like you mentioned previously:

I mean, it isn’t good but well others clients needs to catch up maybe?

18

@Cyber-Typhoon
it is a very difficult problem and more deployment will fragment the ecosystem

it was already fragmented once during the transition from OTR to OMEMO, going from OMEMO (0.3.x) to OMEMO 2 (0.8.x) will do just the same

if it was easy it would’ve been done already. like you can’t just make a chat OMEMO 2 because everyone and all of their clients need to support it otherwise they’ll lose messages.

furthermore there are more important issues like proper key management which even fewer clients properly implement. going even further it’d be nice to see better authentication or 2fa support or new device notifications.

Conversations is the dominant app on mobile and serves as the basis for forks like Cheogram, Snikket, and Monocles. Kaidan cannot compete with its level of polish, functionality, and reliability right now.

edit: also of note is their (OMEMO 2 / 0.8.x clients) status:

whereas (OMEMO / 0.3.x clients):

another edit just because people are hyperfocused on omemo 2 for whatever reason:

  • moxxy doesn’t support channel binding, conversations does
  • cheogram is the primary client supporting dane/tlsa verification
19

Isn’t the current version the 0.9.2?

Fedora adds a dash in the end, e.g. 0.9.1-4 and 0.9.2-1, maybe a patch?

Anyways, I followed the fragmentation point and I’m still on the fence with this argument. I know that you didn’t said anything along those lines but if Kaidan’s interface may not be that user friendly and have the features that the other clients has for users to communicate then it may become a problem of usability and not sure if it could be the driving factor for not be recommending Kaidan.

1 Like
20

Also regarding conversations:

imo XMPP was never really a “private” protocol, and people have tried to shoehorn things in there hoping it will be good enough. It is never going to be widely used and there is way too much quality disparity between clients.

For that matter I haven’t met someone who uses it in the last 10 years. I think people really need to let XMPP go.

1 Like