[gaff33]

> Use WhatsApp to talk to normal people. Use Signal for nerds.

This has been my go-to advice for a while now too! The key driving point is that amazing crypto is 100% useless if the person you're talking to doesn't use it, or uses it incorrectly.

The only sticking point with the above advice is the nerds who think they understand crypto but don't and insist on you using some crazy app :/

[lrvick]

Consider that security you can't possibly verify is just marketing.

Maybe try listening to those nerds and try out some open alternatives with security that is possible to verify.

You might be surprised to find both tools are pretty low on the list in respect to security and privacy compared to tools with smaller marketing budgets.

[lvh]

Could you elaborate how WhatsApp and Signal are not doing well from a security/privacy perspective? Can you name an alternative that does better under those criteria? I was under the impression that Signal precipitated most modern messaging protocol design and verification. But what do I know: I'm just a relapsed cryptographer :)

[saurik]

Signal's stubborn insistence upon using Google Cloud Messaging (which is mostly notable due to their attempts to shut down third-party clients that remove this requirement) combined with its reliance upon phone numbers for identity is itself a serious problem, but when you combine this with the fact that their servers know "this phone number sent a message to this phone number at this time" (information that is even stored, at least temporarily, on their servers in order to implement rate limiting) we really should not give Signal as much default credit as it gets :/.

[lvh]

> "this phone number sent a message to this phone number at this time" (information that is even stored, at least temporarily, on their servers in order to implement rate limiting)

This claim appears to be unsupported by both Signal's privacy policy and public evidence. Unless I misunderstand, they've claimed to use IP addresses for rate limiting. Messages only necessarily contain the recipient's identifier for delayed delivery but certainly does not imply they have a store of (src_phone, dst_phone, hires_timestamp) triples. When subpoenaed for user data[0], they claimed to have no responsive records of IP data, let alone src, dst _and_ hi-res timestamps altogether. Are you saying that has changed, they're lying in their response to the subpoena, they were lying in their privacy policy, or something else?

The issue of long-term identifiers for offline delivery is well-understood (e.g. Rottermanner05) but also not actually a Signal problem. In that light: what do you propose we do instead? (You can probably see the response coming already: let's just say metadata protection is, ahem, complicated.)

[0]: https://signal.org/bigbrother/eastern-virginia-grand-jury/

[saurik]

You do realize that their code is open source, right? Here's the line of code that does exactly what I "claim": their message rate limiter implementation uses string keys that are constructed using the source and destination phone numbers.

https://github.com/signalapp/Signal-Server/blob/e26e383bd7a6...

Frankly, the fact that people like you believe so strongly that Signal doesn't do this should be damning for Signal, as it goes to show just how deceptive they are being about this issue: the reality is that Signal is quite careless with metadata :/.

(As for what you do instead, there are tons of trivial ways of making a secure messaging system that are better about metadata than Signal, and even ways that allow you to implement various forms of rate limiting. Signal is just being lazy here.)

[lvh]

Well, shit: you're right.

I do realize that Signal is open source, yes (and I'm guessing from your phrasing you know I know that), but I don't feel a moral imperative to source dive every time someone says something weird. Putting that burden on the claimant seems pretty reasonable. This set of threads alone was exhausting enough without having links to GitHub with every message :-)

In particular: I interpreted your "stored (at least temporarily)" claim as in like, a logfile that's rotated daily or something. I think we can both agree that would be much worse than a 60 second leaky bucket and hence I interpreted that as more outlandish than what you intended.

But regardless, you're right: that's not how it works today, I read that code an extremely long time ago (when it was really just sender ID limited), and having both sender and receiver in plaintext is clearly worse than having just one, and having a leaky bucket with a timer is clearly a much higher resolution timestamp than the day previously claimed. I'm guessing the distinction is between what's stored and what's not? But I'm definitely uncomfortable and will make a note to follow up. In particular, now I would like to know under what circumstances that Redis cluster will attempt to persist. I think the answer is "never--it only has caches and the directory", but you've definitely shaken my confidence in that answer :)

[jplayer01]

It's always been possible to get a non-GCM version of Signal if you really wanted. And there are plenty of reasons to shut down third party clients that have nothing to do with the Signal team wanting to keep backdoors open.

[gaff33]

Given the amount of noise that politicians and law enforcement are making about WhatsApp - there's very good circumstantial evidence that their EndToEnd encryption works.

I am a nerd - I went through a phase of trying to get people to use PGP and then XMPP. Both are technical masterpieces but a complete disaster for actual users.

Here's the crux: I'd rather have all my conversations encrypted than just the ones I have with other nerds. In this respect WhatsApp has been the best thing that's happened to messaging since the invention of the internet.

[lvh]

What good messenger is better than Signal but just has a smaller _marketing budget_?