Today, an upset internet user complained about our "hilarious" Signal recommendation and "dumb arguments" regarding XMPP in

And there it is: The next episode of "Signal vs. XMPP". πŸ“Ί

To be brief:

– we actually recommended in the same article to host your own XMPP server (besides using Signal)
– cleartext password logging and extensive server-side tracking can't be detected by XMPP users
– there is no secure messenger, see

#xmpp #signal

@infosechandbook Maybe because your previous article is not honest to say the least. You did take the xmpp server and showed how much data can be extracted while you havent done the same with signal server and instead used argument "They say they dont store so must be true".
If you want to do proper comparison you should install signal stack and see how much data you can harvest. My guess is probably similar as its true with any centralized service.


The article isn't about comparing Signal with XMPP.

It's about debunking the myth of a super privacy-friendly XMPP world, as spread by some XMPP fans.

Instead of being honest and telling people about these problems, offended XMPP people show up and throw mud at such articles.

What could possibly go wrong if unknown server-side parties can log and modify nearly everything? Client-side OMEMO and Tor doesn't change the situation significantly.

@infosechandbook @muppeth Except that it does. I recently made a fork of an XMPP app which only uses OMEMO and Tor. This makes a big difference to the security properties, since it becomes difficult to accidentally transmit anything in cleartext.

Your criticism of XMPP is somewhat valid though. With Conversations and other clients they tend to fall back to unencrypted or TLS-only mode if there is any sort of problem, so it can be relatively easy to accidentally do something non-private even if your intention was otherwise.

Since there is only one Signal server it's a certainty that it's targeted and probably already compromised by multiple letter agencies. With XMPP you can at least distribute this sort of risk.

@bob I agree, having multiple services distributes this sort of risk. Another approach, however, which I would by far prefer would be having a full, strong E2E encryption (including metadata) that makes servers, if any, just transports for messages so no matter whoever can compromise which server has no chance to see or even manipulate content. Given that, we even could rely upon the global scalability of AWS or Google Cloud for reliable, privacy-ready communication.

@infosechandbook @muppeth

@z428 @muppeth @infosechandbook Making servers disposable and only storing encrypted data, like cwtch or cryptpad is a good idea.

The problem for XMPP is that if you put the server on AWS then even if you use OMEMO or OpenPGP they will have the roster which could be privacy sensitive.

@bob To me this seems too much thinking in old boxes, to be honest. Why focus on XMPP? People came up with ActivityPub for federation. There's Matrix as a new protocol, with flaws and strenghts. Wouldn't it be a meaningful effort to, for this purpose, craft a new protocol with the lessons learnt from XMPP right for the purpose of providing a reliable, privacy-aware means of communication on top of potentially "unsecure" infrastructure? My only real issue ...

@infosechandbook @muppeth

@z428 @muppeth @infosechandbook XMPP is something we can use now. Matrix, cwtch and other things will maybe become more practical in future. It is also possible to use Matrix with Synapse on an onion address. ActivityPub was designed for public microblogging and never even specified security mechanisms, which leads to ambiguous implementations.

@bob Agreed. But XMPP makes it unneccessarily more complex by having to deal with a plethora of "old" clients and servers and the idea of being backward-compatible. Maybe it would have been a good idea to build something new on top of XMPP, but explicitely make sure it's *not* XMPP and it's *not* going to work (and not supposed to work) with your 1990s client and server anymore...?

@infosechandbook @muppeth



I think much mindshare is behind the names xmpp & jabber. For success one could deploy a server using a new name & never mention it, rebrand some clients, push that. Like google and Fb did, but for good. Then start opening & whitelist instances that followed somekind of modern certification to ensure proper interop. All xmpp under covers.

problem is one of marketing and being tied to a bunch of assumptions accumulated over years.

@bob @infosechandbook @muppeth

@vascorsd @muppeth @infosechandbook @z428 I think this idea has been mentioned before. Essentially it's what WhatsApp is. The developer of the Conversations app has recently done something like it with Quicksy.
Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!