151–160 of 437 posts
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.
> The choice to make these notifications "blocking" would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM transparently and who it couldn't; something that WhatsApp considered very carefully. could not this be saved only localy ?
If resending undelivered messages to new keys waited for confirmation of the new key when safety number change notifications are enabled, then users without those notifications enabled would continue to immediately resend undelivered messages to new keys while users with the notifications enabled would not resend until the user manually OKed the change. The WhatsApp servers know (or can know) whether users have outst…
Earlier quoted context omitted.
Certainly it's possible to remedy this situation simply by having the app author sign a checksum of binaries in the app store. Why this is not currently an option (to my knowledge) is a mystery to me.
What would a checksum add over the app binary being signed by the author (which is currently the case for both stores)?
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.
That's identically true of open-source software. To put it in the theoretical terms you're probably most comfortable with: the programming language used to represent a computer program has nothing fundamentally to do with whether it can be verified. Obviously some languages are easier to verify programs in than others, but the gap between assembly and C in ordinary compiled programs is surprisingly small. Open vs. cl…
That's not true. The design of a language can make it easier to verify with respect to certain properties. For example, it is much easier to verify that a typical Python program does not dereference dangling pointers than a typical C program.
It is true that open source does not help as much as some of its adherents like to think. But that doesn't mean that it doesn't help at all, and it is certainly not true that it cannot help substantially in principle even if it does not help much in current practice.
Earlier quoted context omitted.
That's identically true of open-source software. To put it in the theoretical terms you're probably most comfortable with: the programming language used to represent a computer program has nothing fundamentally to do with whether it can be verified. Obviously some languages are easier to verify programs in than others, but the gap between assembly and C in ordinary compiled programs is surprisingly small. Open vs. cl…
> the programming language used to represent a computer program has nothing fundamentally to do with whether it can be verified That's not true. The design of a language can make it easier to verify with respect to certain properties. For example, it is much easier to verify that a typical Python program does not dereference dangling pointers than a typical C program. It is true that open source does not help as much…
Earlier quoted context omitted.
> 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.
Sure, but so what? Hard != impossible. 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.
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.
If you do not trust your hardware, 2FA is of no use. All communication and display can be MITMed on the untrusted computer. It gives the appearance of a normal login, but the behavior of the trusted site or system is emulated. The real username, password and 2FA authentication token is only send to the target machine by the attacker.
More advanced tokens also do more. My bank uses a hardware token for signing transfers and other actions which can include a human readable message or part of the target account number, making MITM much harder.
We need to spread technology companies. Everything but a bunch of things comes from this law.
And what starts in another country, magicaly gets bought or dismissed. Take Symbian as an example...
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.
Earlier quoted context omitted.
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…
I'm sorry, but this simply isn't true. Software of far, far greater complexity than WhatsApp has been reverse engineered comprehensively by hobbyists and amateurs. Meanwhile, professionals have pretty sophisticated tools for doing this work at scale.
When you only have decompiled assembly, obfuscation is much easier.