A good starting point would be more balanced articles also talking about downsides or not-so-secure/-private defaults; not only in case of XMPP but in case of any instant messaging protocol or ecosystem.
Instead of claiming, "XYZ is secure because it supports TLS," articles should also mention what this means in terms of limitations (e.g., TLS protects data in transit, so server-side parties can still access the data) or defaults (e.g., only a subset of servers/clients support certain security features). While such things might be obvious to tech-savvy users, non-technical people don't understand this. They only read, "secure" and "private" and then assume, "Oh, it's secure and private, so I migrate to XYZ." In reality, "secure" and "private" aren't fixed states that you can identify by looking at some features.
Not in detail as the OP linked to another article. We commented on OP's other article, not on your joinjabber.org security FAQ.
> we were tired of FUD spread by articles like yours
Where is the FUD? Your security FAQ mentions most, if not all, of our findings in the same or similar way.
> Reality is more complex than a binary "is it secure?"
Indeed. Unfortunately, the vast majority of people assume security is binary. Back to OP's article where they look at some isolated properties to then declare a protocol secure.
Yes, but there is no fearmongering involved. I'm part of the people who appreciated your article for the technical arguments, but i strongly dislike the fearmongering vibe (unless we do the same with every other protocol which could be fun). I actually started to write that FAQ precisely because i was tired of the script kiddies on both sides claiming XMPP is either the best or the worst and this or that solution is so perfect.
> Back to OP's article where they look at some isolated properties to then declare a protocol secure.
Yes, that's a problem. Let's try to promote more informative resources. We joinjabber.org people appreciate all feedback and criticism to turn into docs. You're always welcome by xmpp:[email protected]?join chatroom if you have more info and/or would like to run more experiments in regards to privacy and security in the XMPP ecosystem.
Unfortunately, this seems to be the starting point of most discussions on XMPP. Somebody claims that XMPP solves all problems, and is secure and private. Or they present a highly-customized, non-default XMPP setup and compare this with an out-of-the-box competitor to show the superiority of their setup. We rarely see posts like your FAQ on the internet.
> ... or the worst
In case you refer to our article, we don't claim this. We recommend to self-host your XMPP server (if you can), or to migrate to alternatives instead of blindly trusting unknown entities on the internet. We are also not the police on the internet. People can choose what they want, including WhatsApp, Telegram, XMPP-based messengers, Signal, or whatever messenger they use.
> Let's try to promote more informative resources.
We will link to your FAQ. Thanks for providing more balanced content.
Briar mitigates[1] these risks by using p2p messaging over Onion Services.
[1] mitigates: it's well known that even Tor cannot protect from correlation attack from a global observer but mounting such attack requires billions (see PRISM). Correlating traffic from/to an XMPP server is trivially easy for any person that has access to logs from a network device or can run a tcpdump on an hypervisor.
Some research has been done into communication networks that are resistant to traffic analysis, such as Vuvuzela[3]. Unfortunately most such solutions requires permanent connectivity and bandwidth utilization, which makes them impractical for battery-powered mobile devices.
I'm firmly of the belief that no communication tool is suitable for all use-cases, but that we need to build open interoperable ecosystems that fulfil a range of needs, and help educate people about them.
[1]: https://nusenu.medium.com/the-growing-problem-of-malicious-r...
[2]: https://code.briarproject.org/briar/briar/-/wikis/FAQ#does-b...
[3]: https://vuvuzela.io/
If your alternative is to use a centralized platform (which potentially requires a phone number to sign on) that's a trade-off i'm not willing to make. I'm personally very happy with my not-so-insecure pseudonymous communications (but always interested in constructive criticism).