E2E encryption in closed source automatically updated programs doesn't provide any real assurance: whoever makes the program can subvert your privacy at any time.
Do you trust the author of the program? Then E2E doesn't add much. Do you not trust the author of the program? E2E doesn't help. Either way, what's the point? Sure, I guess E2E provides some kind of additional privacy at the margin or something, but you can't rely on it for anything.
Are you verifying that all your OSS binaries you’re running match a reproducible build hash that’s been validated by multiple trusted sources? If not, you’re already engaging in a level of trust.
The real question is how do you establish trust in the code you run and while OSS provides benefits at the margin or something, you can’t really rely on it for anything.
For an example to illustrate the fallacious reasoning of OSS = trust, consider the malicious compiler that Ken Thompson presented[1].
Not GP, but: although I'm not currently doing this consistently (I don't have the resources to set up build servers and there aren't many build servers for my distro yet) the distro I use does make it pretty straightforward to do this: https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
If I want to do this for any particular package as a one-off, it's two commands.
Reproducible builds are a step up but remember that it requires you to build with the exact same binary-identical toolchain. If that’s already compromised your guix challenge isn’t really doing anything of value.
Again, I’m not saying these aren’t valuable things that make attacks more difficult/expensive but the uncomfortable truth is we haven’t figured out how to truly establish zero-knowledge trust. So on that spectrum, ultimately Guix + OSS is closer to WhatsApp than where we’d like to be.
I mean, sure, we're not there yet. If the Guix folks are able to get a bootstrap path going all the way from something like stage0, though, we'll be in a pretty good place I think: http://bootstrappable.org/projects/mes.html
Maybe the current state is closer to WhatsApp than where we'd really like to be, but that should be a challenge rather than a reason to give up.
Never said anyone should give up but my point is that to my knowledge there's no actual proof of how to solve this. We're just stumbling in the dark trying ideas.
I'm curious if you've actually had a chance to read Ken Thompson's compiler virus hack. The Guix bootstrap path from stage0 still doesn't solve the problem as at the end of the day all compilers eventually self-host from a previous version. So whatever compiler you're using for stage0 can have the virus, inject it into the produced binary, & you'll never find it since the virus is in the binary not in the source. Now obviously this is an extreme example and no one actually has any knowledge of whether or not such attacks are practical or have existence proofs beyond a proof of concept.
My overall point though is that everything boils down to trust & the question is who you choose to trust & where. Ultimately, we're all "careless" on that front as there's just too many dimensions to evaluate on. Beyond just basic malware packaged with the code, is the privacy being respected? Are the security practices good enough to withstand attacks? etc etc. Complaining that WhatsApp is slurping a copy of your messages that you are reporting to them & therefore E2E encryption isn't valuable is a fallacious & misdirected argument IMHO.
>The Guix bootstrap path from stage0 still doesn't solve the problem as at the end of the day all compilers eventually self-host from a previous version. So whatever compiler you're using for stage0 can have the virus, inject it into the produced binary, & you'll never find it since the virus is in the binary not in the source.
The point of stage0 is that it doesn't need to be compiled, only assembled, and that it's small enough to inspect the binary or assemble it by hand if you really wanted to. (Not that you necessarily want to, but if you have to...)
Are you referring to https://github.com/oriansj/stage0? This stage0 gets you a basic C compiler. An impressive achievement for sure. I don’t see how it really solves anything though.
More generally each language would need it’s own path from this basic assembler to a compiler implementing that language in C which doesn’t necessarily exist. While initial versions of the Rust compiler were written in C, more recent versions are self hosted and rely on the previous version. This goes for projects like LLVM too since it requires a c++14 compiler to start with.
A better approach is to figure out how to cross compile stage0 and how to make sure the cross compilation step can be trusted. Going the approach of trying to build a “trusted” path from source is noble but IMO ultimately futile.
This is what I mean when I say this as an unsolved problem. It may be getting better but there are fundamental unsolved challenges to this exploration and very little guarantee the task can be accomplished in the first place (ie no mathematical theory that might present a path to follow rather than just trying to accomplish it through sheer effort). Some small part of the problem might get solved but that’s very different from saying that any package will be verifiable in this way.
>More generally each language would need it’s own path from this basic assembler to a compiler implementing that language in C which doesn’t necessarily exist. While initial versions of the Rust compiler were written in C, more recent versions are self hosted and rely on the previous version. This goes for projects like LLVM too since it requires a c++14 compiler to start with.
...and there's a bootstrap path for the bottom of that graph all the way from Guix's (fairly minimal but not quite stage0 yet) bootstrap binaries. LLVM too; since you mentioned it and I was curious, here's the dependency graph of LLVM 9.0.1 on my system, in GraphViz and PDF formats:
(That's from `guix graph -t bag-with-origins llvm@9.0.1` on my laptop.)
It's my understanding that being bootstrappable in this way is a requirement for being included in upstream Guix, so generally everything that's available in Guix can be bootstrapped like this.
Now, what's not done yet is the path from stage0 to building the bootstrap binaries, but that's the eventual goal. The rest of it? It's not futile, it's done. Not all software is in Guix, but enough of it is that I'm typing this from a laptop running almost exclusively software from Guix.
I’m saying stage0 is a massive incomplete lift. If you notice that Rust chain starts at g++ - can g++ be built from the basic assembler you listed?
Beyond that, as you can tell from your graph there’s an enormous amount of code that’s part of a build from a large amount of projects. Explode that by a factor of 100000x to get the number of lines of code. So even once you’ve proven the source matches the binary, you are still trusting that the source code is of a trustworthy nature in the first place. You can move the trust required around and in some cases reduce it, but ultimately you’re trusting a lot of people and code (heck you’re trusting the good will of general OSS to validate the source itself isn’t malicious).
Like I said, I’m supportive of the effort and guix/nix are great projects and extremely valuable. There’s no theoretical basis though to back the design of solving the trust issue though (the best we have are reputation systems but even that isn’t backed by any mathematical model).
>I’m saying stage0 is a massive incomplete lift. If you notice that Rust chain starts at g++ - can g++ be built from the basic assembler you listed?
Not yet, but gcc can be built starting from Mes and a few bootstrap binaries (xz, bash, tar, etc): https://bootstrappable.org/projects/mes.html - and that initial version of gcc is 2.95.3, which does have C++ support.
...and there's work being done towards building Mes with M2-Planet (another C compiler by the same author as stage0): https://www.gnu.org/software/mes/
(Although I think the Guix project has shifted to an approach that starts with Scheme instead these days; they have a Scheme implementation of most of those bootstrap binaries now in the form of Gash and Gash Core Utils: https://guix.gnu.org/en/blog/2020/guix-further-reduces-boots....)
In any case, if you can connect the two, and it feels like that's very close at this point, you've got a bootstrap path from that basic assembler to gcc, and from there to... well, the rest of the distro.
>Beyond that, as you can tell from your graph there’s an enormous amount of code that’s part of a build from a large amount of projects. Explode that by a factor of 100000x to get the number of lines of code. So even once you’ve proven the source matches the binary, you are still trusting that the source code is of a trustworthy nature in the first place. You can move the trust required around and in some cases reduce it, but ultimately you’re trusting a lot of people and code (heck you’re trusting the good will of general OSS to validate the source itself isn’t malicious).
Of course, yes, this is a problem. At least once you're able to bootstrap entirely from source you can be pretty confident that the source code you're looking at is what's in the binaries on disk. But yes, that doesn't solve the problem of having a ton of code to review if you need to review it.
I agree, but also if you don't trust the recipient you're sunk to.
Perhaps the better way to do this is to ask for permission to screenshot the message.
either way, if there is no way to send info about the messages that are "offending" there is no real way to police the spread of it. (assuming that you've done your encryption properly.)
According to the article, recent messages will be sent to whatsapp on reporting contacts or groups just like we sent messages to other users. There is no mention of E2E encryption implemented by whatsapp and its loopholes.
To achieve truly E2E encryption one must assume the channel they communicate with is not secure and then perform encryption themselves. For example you can exchange keys offline and then send messages encrypted with PGP between each other. You could also convert encrypted messages to text, so that it is less obvious it is encrypted.
Do you trust the author of the program? Then E2E doesn't add much. Do you not trust the author of the program? E2E doesn't help. Either way, what's the point? Sure, I guess E2E provides some kind of additional privacy at the margin or something, but you can't rely on it for anything.