141–150 of 437 posts
Why is moxie doing PR for WhatsApp?
>Even though we are the creators of the encryption protocol supposedly "backdoored" by WhatsApp, we were not asked for comment. It's only a small step from criticism of WhatsApp crypto to criticism of Signal crypto. Why wouldn't moxie be interested?
Earlier quoted context omitted.
You can demonstrate the presence of a vulnerability in closed source software but there's no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities.
> no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities I'd say that's hard for open source software to do as well.
Introducing backdoors into open source source is also more difficult.
Earlier quoted context omitted.
He does address this: Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. That means a user is able to verify visually that the end-to-end is working. "users might not notice" doesn't seem to me as a strong argument to state this as a backdoor. This would imply not noticing that you don't have a green padlock on chrome is a backdoor too, and it clearly is not.
The "green padlock" was not considered enough because users would not be able to differentiate it from a big lock symbol within the page. Thus we got HSTS. (There was a time when browsers would color the entire URL bar yellow to indicate https, but that went out of favor many years ago.) Moxie deserves respect for the web vulnerabilities he discovered and raised awareness about years ago, and for his general competen…
I believe we got Signal end-to-end encryption in all of these messengers just barely, even as "compromised" as you may think it is. Google and Facebook (Messenger) didn't even enable it by default because they thought it was "too much" encryption.
So if it was even more difficult to use, it may have never been adopted by these services.
At the same time, I don't think we should allow all sorts of modifications to the protocol and to how this encryption system works just to cover a few niche use cases that would slightly increase those users' convenience.
Sending undelivered messages when the recipient is switching SIM cards instead of just telling the sender that those messages can't be sent then is one of those niche use cases and compromises that shouldn't happen, especially if enabling such features could be turned into defacto "legal intercept".
I guess Moxie is saying here that this wouldn't be a defacto legal intercept, but I'm not so sure that's true, and the researcher that found the bug doesn't seem to agree either. I think, unlike others here, it's very likely that people wouldn't notice that the messages don't have a double check mark anymore.
Earlier quoted context omitted.
There's "no way in principle"? How is this whole story not evidence to the contrary? The person who found this didn't use WhatsApp source code. Why do you feel that there's no way to verify closed-source software?
Whichever story you are talking about, this one or the guardian one, it doesn't address the closed-source point. There is theoretically a way to verify WhatsApp even though it's closed source, but it's practically impossible. It's hard enough to verify software even when the source is open, you built it yourself and the whole platform and toolchain is trusted. A bunch of the potential NSA crypto backdoors were totall…
Color me still-unconvinced. This retort does not address the fundamental point made in the Guardian piece: > “[Some] might say that this vulnerability could only be abused to snoop on ‘single’ targeted messages, not entire conversations. This is not true if you consider that the WhatsApp server can just forward messages without sending the ‘message was received by recipient’ notification (or the double tick), which u…
Unconvinced of what exactly?
Earlier quoted context omitted.
You can demonstrate the presence of a vulnerability in closed source software but there's no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities.
> no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities I'd say that's hard for open source software to do as well.
EDIT: WTF people? Why is every response to this comment being downvoted into oblivion? The sibling comment to this one (https://news.ycombinator.com/item?id=13395657) was killed in a matter of minutes despite being (IMHO) a perfectly reasonable and constructive response.
Earlier quoted context omitted.
He does address this: Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. That means a user is able to verify visually that the end-to-end is working. "users might not notice" doesn't seem to me as a strong argument to state this as a backdoor. This would imply not noticing that you don't have a green padlock on chrome is a backdoor too, and it clearly is not.
The "green padlock" was not considered enough because users would not be able to differentiate it from a big lock symbol within the page. Thus we got HSTS. (There was a time when browsers would color the entire URL bar yellow to indicate https, but that went out of favor many years ago.) Moxie deserves respect for the web vulnerabilities he discovered and raised awareness about years ago, and for his general competen…
Earlier quoted context omitted.
> This is true for basically all software that you use. And hardware too.
And that's why we have 2FA on separate devices or even hardware tokens. They allow some security even if the computer isn't trusted, like protection against replay attacks at a minimum.