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.
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.
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.
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.
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.
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.
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
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.
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 could also decompile the Whatsapp APK and do the same thing (it's Java after all).
Look no further than the OpenSSL Heartbleed vulnerability
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.
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.
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".