There are no known security issues with "Siacs OMEMO" / OMEMO v0.3¹ despite of what some very loud Signal fans would like you to believe. It has been audited by a third party² who took a longer look at it than all of the Signal fans combined.

Yes, #OMEMO v0.7+ (or TWOMEMO 😜) is a cleaner spec with more features (most notably Stanza Content Encryption). That’s why we wrote it. I’m a co-author. That doesn’t mean v0.3 is insecure.

¹: https://xmpp.org/extensions/attic/xep-0384-0.3.0.html
²: https://conversations.im/omemo/audit.pdf

#XMPP

@daniel Most of those Signal fans probably refer to a certain blog post by a certain hobby cryptographer. [edit to add: specifically not linked or named because that person doesn't like "evangelists" for messengers-that-aren't-Signal near them. I respect that.]

One argument there holds water, though: OMEMO use is opt-in, and with opportunities to opt-out.

That's different from what Signal offers, and a foot-gun that is way too simple to trigger. (On the down-side, Signal can't opt-out of data being processed in the US. Trade-offs! 🤷)

All the fluff about this-algorithm-or-that or dependency management in Conversations (their solution is dependabot, unvetted-updates-as-a-service. really?!?) is minor compared to that one aspect.

The expectation should be that stuff is E2EE, with carefully (and loudly announced) exceptions where reasonable (when using XMPP as an internal bus protocol, you might be able to get away without it; when running a client on retro gear, you might get better mileage without the crypto overhead, too - but these must be exceptions, not semi-automatic fallbacks)

@patrick@retro.social
Omemo isn't opt in or out.

There are clients that enforce it.
There are clients that don't.
These are client decisions, unrelated to omemo.

Signal only has one Clint and forbits you to use another. And it enforces it, that's all.

@menel It's the old tension of being opinionated or not.

Signal is opinionated about providing E2EE for everybody, XMPP(.org) doesn't care and sees itself as a mere provider of building blocks (all those XEPs!)

Thing is, the building blocks themselves are useless, and in that case, any argument about "XMPP+OMEMO" is moot: that moniker can mean whatever anybody wants it to mean, at any given time.

So is "XMPP+OMEMO" an alternative to Signal? Since nobody (in their right mind) hand-types per OMEMO-encoded XMPP stanzas into a TCP socket: no.

That gives us products: Is Conversation an alternative to Signal? Is Snikket? Depends.

But once you go there, and look at products, with the specific decisions they make around which XEPs they support, and which they _require_, the XMPP crowd will come, pitchforks and torches ready, to point out the interoperability story of XMPP.

That allows to evade any critical assessment because you can move between spec and implementation and claim "not in scope" for everything. A good faith argument looks different in my opinion.

Put up an "XMPP-2025 profile", akin to XEP-0479, that mandates always-on OMEMO-0.7-or-newer (or something like that), then you can come back and say that "XMPP-2025" is an alternative to Signal.

XMPP as a whole provides all the building blocks that _could_ be used to build an alternative, but it isn't an alternative by itself.

Without making some decisions like that, it never will be. Which is fine, but in that case the XMPP community should own that ambiguity.

(XEP-0479, which is still "experimental" btw, with all older versions "obsolete", specifically points out that, as of 2023, E2EE wasn't "ready yet to be required for Compliance". Is it now? If so: where's the XEP?)

@patrick@retro.social
It's important to understsnd that xmpp isn't a product. But a protocol.
Signal is a product.
It doesn't make sense to compare them.

You can compare something like snikket and signal. Both products.

After all xmpp is used for intentional open chatrooms too, or for company rooms where the server wants to see all messages in the clear for storing compliance whatever.

It is used in IOT or as a wakeup call like in Google push etc. It not only made for private chat systems.

I agree with most of your points, I think we agree xmpp isn't an alternative to signal, never was or will be. Because of the reasons I stated above, xmpp will never enforce at the protocol level e2ee. It's scope is just so much bigger then whatsapp-like chat.

Some apps we use, that use xmpp are alternatives, much better ones (depending on individual threat model)