[vader1]

Fair enough, but this is kind of inherent for anything based on open standards. Was your email encrypted? It depends on whether the sending and receiving mailserver support TLS. Is your website visit perfect-forward-secret? Depends on whether your browser and the webserver support modern cipher suites. Is your DNS request encrypted? Only if your OS and your DNS server support DNSSEC or DoH.

These are valid challenges, but moving to propietary and centralized solutions instead is throwing away the baby with the bathwater. Was your WhatsApp conversation encrypted? You honestly can't know, and even if it is right now, Facebook could disable Whatsapp's e2e encryption at any time without you even noticing.

FWIW, OMEMO has been the (only) de facto encryption mechanism for modern XMPP clients in the last couple of years, and most clients that support it clearly distinguish encrypted and non-encrypted messages.

[lvh]

How do I know my XMPP client is actually doing what it says? Are you saying the provenance for my XMPP client is fundamentally better than that of the WhatsApp app?

[arendtio]

Well, there are different ways. If you want to know what your client is sending and you use your own server, then your server might be able to show you what it receives. ejabberd for example, lets admins inspect the stored offline messages. That way it is very easy to see if a message is encrypted or not. But you could also run a MitM proxy.

Another option is trusting audits or the developers. Last but not least you can inspect the source code of open source apps. So I don't know how deep you want to go with this, but for XMPP there are plenty of options to make sure the client does what it advertises.

Btw. I do not think that OMEMO is fundamentally better than WhatsApp does, as they are implementing the same protocol (Double Ratchet). The main differences are that one is an experimental public standard while the other is a proprietary protocol extension.

[seba_dos1]

OMEMO and its implementation in Conversations has been security audited by an independent entity.

Other than that, sure, you have no guarantees, yet it's still desirable for such critical security components to be free, or at least "open source".

[lvh]

That's all fine but not responsive to my point. GP post said "but what if whatsapp silently hamstrings e2e overnight" -- my point is: what if my XMPP client/server does?

EDIT: I previously said "turns off E2E", which I didn't say in my original referred-to post, and that's more misleading than "hamstrings", which is how the actual attack works.

[vader1]

The difference of course being that WhatsApp is closed source, and they can push any kind of change without anyone noticing.

If the client is open source, you can verify exactly what it does. Compile the app yourself or download it from F-Droid and you can be sure that the binary you get matches those sources.

Sure you can argue this all the way down to "Trusting Trust", but that doesn't really make sense when comparing two apps/ecosystems that operate in the same real world's constraints.

[lvh]

As I've mentioned elsewhere: you do not need the source code to verify what something does, that's not generally how you'd audit this. Audits may be source-assisted, but you'd still bang at it from the actual binary. If you're more comfortable reading source and compiling from scratch then fine, do that: but we should not pretend that Conversations on the Play Store is generally more trustworthy than anything else because the source code is publicly available.

The random update bit is real! But also real for Conversations or whatever, and more real for small developers less likely to have their opsec in check. For the vast vast majority of people in this fashion WhatsApp is identical to Conversations and Signal.

[vader1]

I didn't say that Conversations from the Play Store is significantly more trustworthy in this regard than WhatsApp from the Play Store. I said that an app - such as Conversations - that you can build from source or download from F-Droid is more trustworthy than the Play Store version.

WhatsApp is a proprietary app and as such it's only available on the Play Store. Conversations is open source so you can download it from the Play Store, or from F-Droid, or compile it from source. So if you care, you can be significantly more sure that your version of Conversations "does what it says" than you can be of WhatsApp.

[seba_dos1]

If your server does, your client will notice. If your client does, the other party's client will notice.

[lvh]

Neither server nor peer will notice if you perform the serious attack: exfiltrate the plaintexts or key material and keep the OMEMO/Signal dance around as kabuki theater :-)

[Boulth]

For paranoid users there is also an option of running their own servers and clients (both Prosody and Conversations are open source). XMPP at least provides that option and if you choose it you can still communicate with the rest of the ecosystem.

No such luck for Whatsapp and Signal. And although they may be fair now I think putting all eggs in one company's basket is a bad idea in general (see e.g.: Google).

[CiPHPerCoder]

> it's still desirable for such critical security components to be free, or at least "open source".

Why the scare quotes?

What about software's source code being available makes it more desirable for your non-technical users who will never modify their software?

[seba_dos1]

Even though I'm not a "non-technical" user, I don't review crypto of my XMPP client. And that's fine, I know a few people that did and I trust them enough. This way I don't have to trust an entity that may benefit from being able to access my messages.

Also, this is a fallacy. Just because "typical user" won't care or won't be able to do something doesn't mean we shouldn't strive to build and popularize platforms that do right things. Of course it also has to be good at what users actually do care for to have any chance of taking off, but that's not the point.

[CiPHPerCoder]

> Also, this is a fallacy.

What is a fallacy? I asked a question.

Non-technical users will never modify their software. The act of doing so would recategorize them as "technical". I don't see any fallacy here?

The most likely interpretation of your comment is, you're assuming an argument that I am not making.

> Just because "typical user" won't care or won't be able to do something doesn't mean we shouldn't strive to build and popularize platforms that do right things.

That's a disagreement with an argument I did not make.

> Of course it also has to be good at what users actually do care for to have any chance of taking off, but that's not the point.

What is the point, even?

I just asked how something being "open source" (to borrow the scare quotes) is more desirable to users who do not read/write software code? What is their incentive supposed to be to prioritize open source over proprietary software?

That's not an argument. It's certainly not a fallacious one.

> Even though I'm not a "non-technical" user, I don't review crypto of my XMPP client.

Little bit of background: I'm the sort of person who would review the crypto of an XMPP client.

> And that's fine, I know a few people that did and I trust them enough. This way I don't have to trust an entity that may benefit from being able to access my messages.

Cool, let's ask an trustworthy expert then. I can think of no finer expert to chime in on this discussion than JP Aumasson, one of the co-authors of SipHash and BLAKE2, who wrote the book Serious Cryptography and conducted many cryptography audits in his career.

https://research.kudelskisecurity.com/2018/10/02/open-source...

Oh.

[CiPHPerCoder]

> Is your DNS request encrypted? Only if your OS and your DNS server support DNSSEC or DoH.

DNSSEC doesn't encrypt, it only signs.