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.
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.
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.
So yeah, it is actually kind of like rocket science, and I guarantee you that Moxie has spent orders of magnitude more time thinking with, dealing with, and collecting data on this kind of problem than you or I combined.
Furthermore, this is an argument via authority[1]. Of course there are experts, but even an expert should explain and discuss his rationale in the interest of sharing knowledge (which moxie is doing here) - otherwise problems like this will stay "hard" for a long time.
And Moxie has explained his rationale in this thread. Argument to authority isn't always wrong — particularly in the case where the other side has no data or theory to back up their claims. For instance, I personally only know little about the actual mechanisms behind anthropogenic climate change. What I do supports the notion. But I'd be lying if I didn't acknowledge that the most compelling argument is the absolute agreement by 99.9%+ of the actual experts in the matter.
Likewise, in the absence of any obviously compelling evidence validating GP's approach, combined with Moxie's explanation above and my own experience as a security engineer, I'm going to go with the guy with literally decades of both theoretical an operational experience here.
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.
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.
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.)
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).
"In Europe, there is technically no uniform body of “European law” that directly applies between employers and employees"
"Courts and scholars increasingly reference EU law, usually without clarifying whether the existence of a particular civil right protection in the EU Charter actually changed the legal situation as a matter of law, rather than as a matter of public policy."
There's a lot of fuzziness around implementation of a very loosely worded human rights clause, combined with prior national laws. Mostly aimed at protection from Government. Previous tests have mostly been cases where the individual did not consent or some such thing.
More directly, EC data protection directive hinges on: 1) contractual obligation; 2) consent; 3) statutory obligations; 4) balancing test. It seems highly likely that most business can legally MITM me if I sign the contract they want me to sign.
Most - but not all - of the private sector examples given (including Germany and France) hinge on the employer not following the correct process: either not notifying the employees, not gaining consent, or opting to allow private communications at work which are strictly forbidden from being monitored (in some countries).
That said, there is also:
"A number of EC member states, including Germany, Italy, the Netherlands, Spain, and the United Kingdom, strictly prohibit ongoing monitoring of employee communications and permit electronic monitoring only in very limited circumstances (e.g., where an employer already has concrete suspicions of wrong-doing against particular employees),265 subject to significant restrictions with respect to the duration, mode, and subjects of the monitoring activities"
It's not immediately clear if the applies to specific, targeted monitoring. The footnote says gives an example where informing the employee of valid reasons for investigating is sufficient.
The pages I gave are specific case studies of the law in Germany & France. You are right that there is not too much overarching EU level legislation about these things, it's generally in national legislation and up to each country.
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.
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.
For some reasons everybody uses an address book, many people let browsers remember passwords but almost everybody resists the idea of using a password manager and end up with low entropy passwords.
How would these 'trivial' steps look like if a telephone gets stolen or upgraded? What easy steps did Facebook & Moxie overlook?
Just as 'trivial' as it is Facebook to swap your key at the request of a government. You should have to start from a blank slate (zero trust) in that situation.
Getting your phone stolen is an extraordinary event that warrants requesting some attention from your contacts, even if only to inform them of the old identity being compromised. And then you might as well have them verify a new key.
Buying a new phone and switching to it Reinstalling your phone OS because "it's slow" Reinstalling WhatsApp because "it crashes" or "it's slow" Swapping a phone because the screen is broke or I dropped into the toilet
I think it's romantic to think that 1 billion of WhatsApp users can be taught about the risks of MITM attacks and how to do a key check.
This is what I do: I have the warnings turn on. When the key change warning appears, and if I care enough about the person and the discussions we have, I try to match the warning with a real world event, so either I already know that something happened, or I try to remember to ask somehow if the person repaired or changed the phone. If I can match the warning with such an event, I feel satisfied. Otherwise, i ask for a key check when I meet that person in real life.
It would help if WhatsApp provided a UI to show whether I have verified the current key of each user (something like a green check-mark next to the name) because it's hard to remember.
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.
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.)
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).
LetsEncrypt just barely left beta (also this summer) and I'll admit that I haven't investigated it thoroughly, but it appears that some widespread devices are still incompatible (also consider the versions that accept LetsEncrypt; some of those are fairly recent, like CM 10). [1]
While some noble souls like LetsEncrypt have sought to remedy this rent-seeking behavior, it remains the fact that in most cases, a traditional CA is going to be required for a couple more years at least.
[0]https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...
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...