[Javantea_]

It now is a lot more clear what's going on here. The discoverer of this issue is basing his argument on the fact that when you verify a fingerprint, you are now confident that your end-to-end encryption won't transparently send your encrypted data to someone with a different keypair. The other side of the argument is that if WhatsApp actually did what you expect, data would be lost when a person switched phones in the middle of someone sending them a message. As a person who doesn't switch phones very often, I would prefer an end-to-end encryption to never send data to a different public key than the one I've used before. I would rather lose data than divulge it to a third party who has the ability to spoof the recipient's phone. This would only come up whenever someone switched their phone when I was sending them a message, so it's pretty rare.

To me the trade off is a no brainer, and apparently to Facebook and Whisper Systems the trade off is a no brainer in the opposite direction.

[whyoh]

>if WhatsApp actually did what you expect, data would be lost when a person switched phones in the middle of someone sending them a message

Only temporarily lost. WhatsApp could ask you: "do you want to resend the message(s) to the contact's new phone?". An easy solution and it could be optional, even off by default.

[FabHK]

I like that idea.

OpenWhisperSystem's response was that due to the delay involved the (potentially compromised) server would know who has enabled notifications/blocking and who hasn't.

[whyoh]

>the (potentially compromised) server would know who has enabled notifications/blocking and who hasn't.

How would that be worse than the current situation, where everyone is vulnerable and we all know it?

[FabHK]

From Moxie's response in another thread:

[...] a fact of life is that the majority of users will probably not verify keys. That is our reality. Given that reality, the most important thing is to design your product so that the server has no knowledge of who has verified keys or who has enabled a setting to see key change notifications. That way the server has no knowledge of who it can MITM without getting caught. I've been impressed with the level of care that WhatsApp has given to that requirement. I think we should all remain open to ideas about how we can improve this UX within the limits a mass market product has to operate within, but that's very different from labeling this a "backdoor."

https://news.ycombinator.com/item?id=13394900

[FabHK]

As a counterpoint, though, see the discoverer of the vulnerability:

"As Eike Kühl pretty well describes, this functionality only increases usability in a rare corner case: When you dump your phone in the ocean and you need a month to get a new one. Then everyone who has sent you a message during this period will not need to press an additional "OK" button."

https://tobi.rocks/2017/01/what-is-facebook-going-to-do-a-su...

[silentiumest]

This response is not valid as Tobias Boelter points out in his follow-up blog post: https://tobi.rocks/2017/01/there-is-a-whatsapp-backdoor/

>> Those "blocking" clients could instead retransmit a message of the same length that just contains garbage, i.e. instead of "Login with the password d98y289whcma0", they'd send "0000000000000000000000000000000000000" and this message would just not be displayed by the receiver's phone. By the guarantees of encryption, those two messages are indistinguishable in the encrypted form. Hence, this technique would make identifying users with the additional security enabled on a large scale impossible. <<

[FabHK]

Maybe one should look at it as

WhatsApp: decent security for non-techies, making routine mass surveillance much harder

Signal: even better security for techies