I would place Signal in the same tier as WhatsApp here (Tier 2). They both upload your contacts to an intermediate server that gives you their public key, which you can optionally verify afterwards.

This means a malicious server could both store away your contacts and try to MITM you, risking detection if you do verify your fingerprint with the other party.

A messenger that really did "all possible tradeoffs in favor of security" would force you to verify the recipient, either in person or via a web of trust. I think not doing that is a perfectly acceptable tradeoff to protect 1 billion users from passive mass surveillance.

These are all UI issues though, the Signal protocol seems solid, and I'll be glad to see it used everywhere. Hopefully we will get clients that you could recommend to a journalist or lawyer and have confidence that they will be able to use it for secure authenticated communication.

That's something that's at least somewhat true of OTR and PGP too, in their normal use, and in all three cases if you're serious about OPSEC you can completely mitigate the problem. So in my evaluation, Signal's a tier 1 option, and WhatsApp is tier 2.

Reasonable people can disagree, of course.

I hope it's obvious that, since OTR is in tier 1, these tiers aren't an analysis of how much I like different messengers. :)

> That's something that's at least somewhat true of OTR and PGP too

Well, OTR is just the protocol, implementations vary in how well they make you authenticate your conversation partner. And PGP will whine at you a lot if you haven't marked a key as trusted. But somewhat agreed. A bad UI can ruin the security of otherwise solid crypto.

I just don't see how the security of Signal and WhatsApp are different. Assuming for a moment (very optimistically) that the user verifies the fingerprint and enables the alert for changed keys, they are using the same protocol with the same guarantees.

Are you factoring in some level of trust in their ability to write a secure client or run secure servers?

Its probably only a half-step up, but signal's client (and server?) are open source. You could compile your own to avoid problems with the binary blob being different. Maybe you could run your own server to dish out keys, but that may be a stretch.

> I would place Signal in the same tier as WhatsApp here (Tier 2). They both upload your contacts to an intermediate server that gives you their public key, which you can optionally verify afterwards.

The last time this came up, inspired by a post by pbsd, I submitted a detailed write-up of a protocol Signal could use to avoid requiring users to submit their contact information: https://news.ycombinator.com/item?id=11289223

It's a solved problem.

> A messenger that really did "all possible tradeoffs in favor of security" would force you to verify the recipient, either in person or via a web of trust. I think not doing that is a perfectly acceptable tradeoff to protect 1 billion users from passive mass surveillance.

Except it introduces another point of security failure. I would prefer to use a system like SDSI/SPKI's friend-of-a-friend naming, with a contact-sharing mechanism so that I could, say, know that I was talking to 'Sheila's Dad' or 'My Boss's Jim's Phone' (presented in a somewhat more user-friendly way, maybe 'My Boss → Jim → Phone' or something).

Does signal still rely on Google's marketplace and services being installed?

Yes

Don't forget Ricochet†, it only does synchronous communication but it does solve the problem of leaking meta-data. All the other clients except Pond leak meta-data.

† https://ricochet.im/

Ricochet appears to rely on Tor's encryption, with an additional custom RSA handshake. That's two added levels of "nope" for me, but other people might feel differently.

I can see that but I think the self authenticating nature of Tor Onion Services and therefore bypassing bgp, dns and CA weaknesses is worth something†.

Maybe in the future when prop224†† is implemented the encryption will be more solid.

† https://media.ccc.de/v/32c3-7322-tor_onion_services_more_use...

†† https://gitweb.torproject.org/user/asn/torspec.git/tree/prop...

Stipulate that Tor's encryption is modernized and drastically improved. I still don't think it's a good idea to build a messaging application directly on top of that, for some of the same reasons that it isn't a good idea to simply run a messaging application on top of TLS or Nacl. The service model and security requirements for a simple transport are different from those of a messenger.

That's what's so exciting about the WhatsApp announcement. WhatsApp is by all accounts a pretty great messaging application, and it doesn't just have decent encryption now; it has best in class encryption specifically designed to protect a messaging application, designed by experts who thought about this problem for a long time.

(I've updated the parent about bypassing bgp/dns etc. before I saw your reply)

The nice thing about using the onion address (transport layer) is that you have mandatory e2e authentication with only one id that solves multiple real world problems with bgp/dns/tls.

How would you propose to go further from current state-of-the-art WhatsApp to stop leaking meta-data? I know Ricochet is open to use a stronger encryption layer on top of Tor †.

† https://github.com/ricochet-im/ricochet/issues/72

> - Redacted to avoid flamewars.

Aww... shucks.

My Twitter mentions are noisy enough already this week. :)

I'm assuming Telegram.

Signal is pretty simple. Even my relatively technologically illiterate mother uses Signal.

What are WhatsApp's tradeoffs in favor of adoption and usability, compared to Signal?