[moxie]

> That defense, which happens to be the only defense, is turned off by default in WhatsApp. > You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the connection as if nothing happened...

One thing we've learned over the years is that security warnings should not be displayed to consumers under "normal" (eg. non-critical) circumstances, otherwise it creates a condition of "warning fatigue."

TLS certificate errors are not something that should happen under normal circumstances. When a TLS certificate fails to validate, something is really wrong. As we've gotten better about ensuring those conditions, browsers have made it harder and harder to get past the warnings, because they're not warnings anymore -- they're error conditions.

Key changes in a messenger are totally different. They happen under normal conditions, so putting them in people's faces by default has the potential to do more harm than good. If we can make them workable, systems like CONIKS or Key Transparency might be in our collective future, but if you don't like systems that are fundamentally "advisory" (don't tell you until after the fact), you're not going to like those new systems at all either.

For now, I think a fact of life is that most people will not verify keys whether the warnings are there or not, so I think what's most important is that the server can't tell who is and who isn't.

I'd love to hear other ideas about how to improve the UX of interactions like this, but I think they have to include a basis in the assumption that we can't fundamentally change human behavior and that we can't just teach everyone in the world to be like us.

[xg15]

Why not phase the message differently, e.g. "It looks like (user) is chatting from a new device. Is this correct?"

Warning about unusual account activity seem to be very common these days, so why not using them here.

The way the warnings are presented as part of the chat history (a very good idea) also means they could be used after-the-fact to figure out when an account was overtaken, even if the warning was initially ignore. I figure even non-technical users would like to know that, after one of their contacts tells them their account was hacked.

Additionally, why is an ignored warning worse than a warning that is suppressed to begin with? That seems to me like a landlord that decides not to install smoke alarms because "the tenants could get used to the sound" - when most of the tenants are not even aware of the concept of "fire".

Finally, I don't find the "it's important the server doesn't know" argument not convincing. If you conclude that the vast majority of people doesn't have the warnings enabled and the costs of hitting someone with warnings is low, that would make snooping still a very low-risk activity.

Summing up, I think the very least consequence Facebook should take from this is to make the warnings in-by-default instead of off-by-default.

[stouset]

> Why not phase the message differently, e.g. "It looks like (user) is chatting from a new device. Is this correct?"

Because of exactly what Moxie said in his post. This is a relatively common occurrence in practice. Someone gets a new device. Or uninstalls/reinstalls the WhatsApp app. Or wants to read messages on their laptop, too. And so on.

Warning everyone about this all the time leads to people becoming subconsciously blind to these notifications — even to people who should care about them. The solution taken by WhatsApp is a great compromise in this situation. Not everyone will have it on, but the odds are in favor that someone they might want to intercept messages for will. And if they can't know who has the notifications enabled and who doesn't, they run the risk of tipping their hand that they're doing it at all.

[danenania]

The people who are most likely to be snooped on are also more likely to have the notifications turned on, so I don't think it's such an easy choice for an attacker.

The entities this is designed to thwart are not going to want to risk leaving behind a trail of evidence, even if the risk is small.

It also prevents fishing expeditions, since the risk would quickly add up as more targets were added.

All that said, a one-time prompt to turn on the notifications for users that care about extra-strong security seems like a good idea to me.

[rndgermandude]

The fact of the matter is, that when you disable the only defense against MITM by default, you should not claim your stuff is secure and end to end encrypted, because it is not. It's really easy as that.

Warning fatigue, "most" users not knowing how to do it or doing it wrong etc, are indeed hard problems to solve. There are indeed no easy answers to this, or else somebody would have come up with something already. But just because it's not easy does not mean you're entitled to just lie about the security properties of your system to your users.

>WhatsApp's end-to-end encryption ensures only you and the person you're communicating with can read what is sent, and nobody in between, not even WhatsApp. [...] All of this happens automatically: no need to turn on settings or set up special secret chats to secure your messages.

https://www.whatsapp.com/faq/en/general/28030015

Given that the only defense against a WhatApp MITM is turned off by default, the "not even WhatApp"/"automatically: no need to turn on settings" part is just not true.

[gsylvie]

At one of my jobs the network team uses a thing called "Forcepoint's TLS inspection" (aka Websense) (aka Raytheon). My browser happily let's that network team MITM me all day long without a peep, and logs & archives all my TLS traffic for who knows how long.

The funny thing is a VM I setup from my same laptop tried to make an https:// connection and the browser outright refused, without any possible workaround until I imported the Forcepoint CA cert.

Security people must love us users so bad. Love you, too! xox

(Note: the same network team imaged the laptop in the first place, and it's against my contract to re-image it. Hence the Forcepoint CA cert's presence in my browser's root chain. I prefer to call this LAN-In-The-Middle.)

[oarsinsync]

This is absolutely standard in the UK financial services industry, and ultimately required for compliance with financial regulators.

The alternatives are running agents on your machine that capture everything you do (which most shops I've been at do as well) and removing local administrative rights to prevent users from removing auditing software and deploying workarounds like your VM (also the norm now).

This has absolutely no bearing on the security of HTTPS/TLS as a whole, the chain of trust is working exactly as it's supposed to in this instance. It's distasteful as an end-user (and even more distasteful as one of the network engineers deploying it, wondering why it's not Information Security's job instead), but you can always quit that job and find another one (yep, that's what I did).

[meowface]

Assuming this is a laptop they assigned to you, what's wrong with any of that?

[gurrone]

Having started originally with Threema before I gave in to WhatsApp I kind of like the trust levels they established in the UI. Might be an improvement for the WhatsApp UI to downgrade the trust level visually in case of unexpected key changes.

Beside of that, and thinking through this comment by moxie, I fear he is right. I've a bunch of dead keys listed in my Threema contact list. All from people which are in general quite tech savvy but still were too lazy to transfer their keys on phone changes. And I already had to rescan (the QR code) quite a bunch of people when I meet them maybe once a year. Thats for my modest 20 something Threema contacts. Now think about the not very tech savvy average whatsapp user with his 150+ contacts. Maybe about a third of them will change their phone or MSISDN throughout a year. If you see 50 alerts per year in your chats that something changed, how long will you care to verify those changes that they're valid?

I don't like those defaults choosen by WhatsApp and once I knew about it I changed it. But at the scale of WhatsApp I understand the decision they made. You might also want to add the common argument that in the real world close to nobody will give a shit about the encryption. Since Snowden a few percent more care but it's still a small minority. So to bring at least some security to the majority that do not care is still a win. Everyone else has to make informed decisions about their own configuration.

[Veratyr]

> Key changes in a messenger are totally different. They happen under normal conditions

This doesn't have to be the case. If you stop coupling a key to a device and instead couple a key to a person (generating a key deterministically from a password for example), they can be changed far more rarely.

[mavhc]

Whatsapp became popular because they worked out a way to not have to have people create an account and a password, you're overestimating humans

[Saavedro]

this requires humans to be able to generate and remember passwords with decent entropy

[taneq]

Why are unsigned key changes a 'normal' thing? It'd be trivial to sign the new public key with the old private key, maintaining a chain of trust.

[smartbit]

> It'd be trivial to sign the new public key with the old private key

How would these 'trivial' steps look like if a telephone gets stolen or upgraded? What easy steps did Facebook & Moxie overlook?

[akvadrako]

That is basically how 2FA works with Apple devices. You use an old device to approve new ones. Sure, if you lose your cloud account, laptop and phone all at once you'll need to start from scratch. But under normal circumstances it reduces the amount of blind trust.

[giovannibajo1]

Moxie, what about showing a positive UI for users you have verified keys with? Something like the verified checkmark on twitter. I'm ok with this being client side of course, and possibly even lost if you reinstall the app (better than nothing).

I like to verify keys of my main professional contacts on WhatsApp, but it's hard to remember who you verified keys with, and then whether the key was changed since last time you verified it.

[dbrgn]

Threema offers that. You do a QR code scan, after which a contact is marked as verified (3 green dots). Since Threema has a fixed key per user, these verifications are persistent and most people transfer their keys when switching to a new phone.

[ajb]

It would be good to be able to check how long the present safety number has been in place for. That would allow people who have become concerned about snooping to detect snooping back until that point (hey, when did you last change your phone?).

[cookiecaper]

>TLS certificate errors are not something that should happen under normal circumstances. When a TLS certificate fails to validate, something is really wrong. As we've gotten better about ensuring those conditions, browsers have made it harder and harder to get past the warnings, because they're not warnings anymore -- they're error conditions.

Not paying Verisign your rent? That's an "error condition".

(Here of course referring to the choice of browser vendors to block access to web sites that offer secure end-to-end crypto via TLS, but merely haven't paid a browser-trusted CA to issue a new cert with a future expiration date.)

[oarsinsync]

> Not paying Verisign your rent?

Would have been a fair statement a couple of years ago, but we live in a day when you can get free annual certs manually (Startssl) and free 90 day certs automatically (Letsencrypt).