Today, an upset internet user complained about our "hilarious" Signal recommendation and "dumb arguments" regarding XMPP in https://infosec-handbook.eu/blog/xmpp-aitm/.
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 https://infosec-handbook.eu/blog/discussion-secure/#sm
@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.
@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.
@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 ...
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.
#Xmpp problem is one of marketing and being tied to a bunch of assumptions accumulated over years.
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!