Platforms that rely on trust (in this case, trusting that FB isn't doing bad things) provide very weak guarantees about privacy/security. They could easily include a keylogger in WhatsApp and bypass the e2e encryption, for example, and us regular folk have no way of knowing.
Careful - you're right that WhatsApp is untrustworthy, but laws that force them to add backdoors could well be applied to open-source code as well. Or make possession of non-backdoored software, open or not, illegal. Or compel OS/hardware manufacturers on which the code runs. The law is a dangerous thing to ignore.
Implementing hardware backdoors that are opaque to end users is theoretically possible, but more difficult in practice. You could, for example, build a screen/monitor that just captures everything on the screen and forwards it to some other entity, but in practice it's not so easy because of bandwidth limitations, etc. I suppose it would be much easier to create a physical keyboard that phones home over a mobile network, although it would only give you half the conversation.
*edit: added the word "audited".
You could also decompile the Whatsapp APK and do the same thing (it's Java after all).
Look no further than the OpenSSL Heartbleed vulnerability
https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...
It's one of the reasons the Debian project has worked so hard at reproducible builds: https://wiki.debian.org/ReproducibleBuilds/About
Bugs can certainly occur (like Heartbleed etc) but the alternative (closed source opaque binary blobs) is much worse.
Also, I'm still using one of those original builds on my laptop - upgraded of course...still mad love for my daily driver.
And so they never learned, and so they "can't".
In the same way, I can't use Gentoo or vim or compile either or ski or... :D
Now, to avoid the "Reflections On Trusting Trust" exploit, building the C compiler toolchain from known-good "root" compiler/linker toolchains, and then comparing the output vs. self-compilation is quite a bit harder.
If you have multiple compilers and they all aren't infected in exactly the same way (e.g. one is not infected, or they have different types of infections) then you can detect there's a problem with them.
Where does that leave the rest of society? Having open source software and hardware is not enough, we also need laws that prohibit mass surveillance and support our efforts to uphold human rights.
Laws are probabilistic, whereas math & source code is deterministic. You can verify that computer code does what it says it does. Laws depend on enforcement and complicated judicial systems (based on humans) to interpret and apply the laws, which means they can effectively change over time, and the goalposts are never stationary.
This is why moving the goalposts and further normalizing surveillance is extremely dangerous. The rights that you enjoy today are not universal, and can obviously be eradicated in less than a generation.
[1]: https://www.eff.org/deeplinks/2015/04/remembering-case-estab...
There is no mathematical escape hatch from society. All we have is a messy assortment of technological mitigations that change the cost of surveillance.
These mitigations work best in combination with constitutional rights that limit what the government of the day can do, triggered by the latest outrage in the news.
This is clearly a straw man, no one wants to do this, or is suggesting that we do this. But at some point, even the most hardened OSS advocate has to trust someone (usually the hardware manufacturer). You cannot verify that the device you're on doesn't spy on you, you have to rely on the manufacturer's word that it doesn't. And the manufacturer's suppliers, of course, because the manufacturer is trusting them.
Somewhere along the stack, we all have to draw a line and say "beyond this point, I trust that I am not being spied on". You choose to draw that line at the hardware point. Others choose to draw the line at the software point.
Proper law enforcement (mind the "enforcement" part) can make a neighborhood safe enough so that nobody tries to shoot you and you won't need to wear vests. But in the end of the day, if you are messing with bad people in the bad neighborhood: bulletproof vests are real, laws are not.
And when you are talking about government enforcing the laws that are supposed to forbid uncontrollable government agencies to do what they do: well, government kinda is bad people in the bad neighborhood.
So you still just invest trust in the maintainer or — if you’re lucky — the third party auditing firm who was paid to review the code.
That you can review the code doesn’t mean that anyone does so. At least not in an exhaustive and relevant way.
Closed source or open, the problem is made even worse now that we live in a Package Manager culture where even the simplest applications adopt dozens of dependencies.
I’m not saying that you should trust Facebook and their closed source applications, just that you’re not really all that safer trusting anyone else just because their source code is available.
Correct use of past tense. In the present, e2e encryption is by default.
> Does this new announcement really lessen the security and privacy of the users?
Yes it does, since e2e encryption is enabled by default now. Best I can tell, there’s no way to disable it either.
Hacking into closed source code is much more dangerous (politically) for them and also more difficult.
There's currently a push for reproducible builds which further hardens distros against such attacks.
Not necessarily. Have you ever heard of Ken Thompson's backdoored C compiler?
https://softwareengineering.stackexchange.com/questions/1848...
>Re-write compiler code to contain 2 flaws:
>When compiling its own binary, the compiler must compile these flaws
>When compiling some other preselected code (login function) it must compile some arbitrary backdoor
>Thus, the compiler works normally - when it compiles a login script or similar, it can create a security backdoor, and when it compiles newer versions of itself in the future, it retains the previous flaws - and the flaws will only exist in the compiler binary so are extremely difficult to detect.
It's not necessarily a viable attack method today, but it's the lesson behind it that's important. Anything can be compromised.
As soon as you’re building something written in, say, Javascript, then any semblance of assurance goes out of the window.
JS is an easy target. What about C or C++? You could audit the code but have you also audited your compiler? What if you used Visual Studio?
Code is an easy target. Can you trust the auditors themselves and in the absence of that, your own ability to detect a vulnerability?
The only bulletproof solution is to not use software.
That said, most of us are not as important or recognisable as we believe we are. The layperson won’t have a good reason to isolate their computer and install an airlock between their aluminium-lined office and the rest of their house.
This is just an updated version of the story about the US government scanning your emails for keywords after 9/11. They don’t even need to actually do it, they just need to say they do and most people will monitor their communications.
Many people can compile code from source. Not so many people have the ability to audit code for obscured backdoors. The number of people that are capable to audit and have the time that is necessary to do it is practically nil.
You assume that you actually understand the code well enough to identify the backdoor - e.g. as some sort of function that will bypass authentication when some secret hardwired password is provided (to give a dumb example).
However, to give a real world example of backdoored crypto, it is nothing of the sort. For example, the issue with the potentially backdoored Dual_EC_DRBG pseudorandom number generator has been known since 2004 at least - but the algorithm has been standardized by ISO/NIST and used for years until the potential backdoor issue was widely publicized following the Snowden leaks and the standard was withdrawn.
Good luck finding something like that only by reading code unless you are expert in crypto and mathematics. If you were only auditing code whether or not it matches the published, supposedly correct, standard (or algorithm description), you would never find this. The backdoored code was working completely fine, exactly as intended. But the weak random number generator allowed an adversary with sufficient computing resources to break the encryption.
An improvement in security and privacy isn't limited to "make it impossible, even theoretically, for anything bad to ever happen OR you've accomplished nothing". Most back doors aren't inserted by competent NSA-level actors 20 years in advance. Most are "whenever a message passes through, send a copy to this third party". They are inserted by court order for a specific case due to the government becoming interested late in the game due to a specific case. For example, when terrorists start using some secure email service, the government tries to force the service to allow them to snoop on the relevant conversations. Open sourcing the code would allow you (with the help of the community) to detect these sorts of attempts when the product involves end-to-end encryption.
So while having the source and a community auditing changes to that source doesn't prevent every possible attack against your privacy, it prevents almost every one that is plausibly detectable, which is literally as good as you can do.
That assumes you can get the code. If it's illegal to distribute non-backdoored software, the code might be hard to get, for example Github might be forced to take it down.
The fly in the ointment is the client might have additional functionality to leak the e2e encryption key. That is far harder to find, but if it's use were widespread, it would be found by researchers.
The whole point is moot though - whatsapp is designed to (by default) upload cleartext chat logs to google/apple servers. Since all chats have 2+ recipients, the conversation is only safe from snooping if nobody in the chat has backup enabled, which is unlikely.
They could indeed serve you a different binary from the app-store. "Do you think that's Whatsapp you're using?"
I have much more trust in the former than the latter.
Audits should start with the actual binary. Only if you can ensure that the binary was build from a specific source code and does not contain any other logic in there (i.e. it was build by a trusted compiler), you can happily skip the decompilation process and analyze that source instead.
It's still nice to see this spelled out since I've seen many people claim that WhatsApp being closed source is not that problematic. This is definitive confirmation that it cannot be trusted anymore and it's time to start working on the problem (both from a legislative point and by seeking out and moving to technological alternatives).
Back in the day, it was illegal to export "good" encryption. There was nothing stopping it from happening technically, just like there is nothing stopping you from stealing from a convince store, except for the threat of enforcement.
But the threat of enforcement can have a strong chilling effect.
I suspect most people want to keep their $500k+/year jobs instead of sticking their necks out. My friends who work at FAANG are largely mentally checked out, and just do it to collect their monies and retire ASAP. You can't pay rent with good feelings.
So just keep making the world shittier. Gotta love individualist capitalism.
Raised the standard of living for billions.
If you define the free market as nothing other than anarchy, then yes the free market is rare indeed.
But I don't that know anyone that speaks in such absolutes.
No one quote in particular; just a recurring theme.
"It is not from the benevolence of the butcher, the brewer, or the baker, that we expect our dinner, but from their regard to their own interest"
- The Wealth of Nations
"The natural effort of every individual to better his own condition...is so powerful, that it is alone, and without any assistance, not only capable of carrying on the society to wealth and prosperity, but of surmounting a hundred impertinent obstructions with which the folly of human laws too often encumbers its operations."
- The Wealth of Nations
"The statesman who should attempt to direct private people in what manner they ought to employ their capitals, would...assume an authority which could safely be trusted, not only to no single person, but to no council or senate whatever"
- The Wealth of Nations
"In spite of their natural selfishness and rapacity [capitalists] are led by an invisible hand...and thus without intending it, without knowing it, advance the interest of society"
- The Theory of Moral Sentiments
> Have you read him?
Yes.
"The man of the most perfect virtue, the man whom we naturally love and revere the most, is he who joins, to the most perfect command of his own original and selfish feelings, the most exquisite sensibility both to the original and sympathetic feelings of others."
Self-interest, yes, but in a system regulated just as much by the church and the aristocracy as by the flow of capital. Pure monetary greed without regard for doing what is right is nothing Smith would ever have advocated.
Imagine if 10 or 20 different organizations all had access to the source code and could vouch for the checskum of a each build.
While it would be nice if we could trust FB, Apple, etc., it would be much better if we didn't have to, and could simply trust others who have less to lose from alienating government officials.
This would be quickly detected by anyone looking at the data the WhatsApp app was sending back to the server (this isn't hard to do on a jailbroken device).