3 ms·
I think the argument is that when you load a webpage, you download the code everytime you want to run it, from servers owned by the company building the service
by palata 7mo ago
I think the argument is that when you load a webpage, you download the code everytime you want to run it, from servers owned by the company building the service. So they can choose to serve you different software (e.g. with a backdoor), just this one time and just for you, and you won't know (not that it would be impossible, but it is generally impossible in practice).
When you download a program on Linux through the distro package manager, you download it once and run this, every time. You know very well when it gets updated. You can compare the hash of your program/package with the one distributed by the distro, and the distro is not the developer of the program (so there is another layer there). You can audit that code (if open source), and at the very least you can compare with others to see if they receive the same code. And again, the program is served by the distro, not by the developer. The backdoor situation would require asking the developer to implement a backdoor, and then asking the distro to server you a different executable, and then hoping that you never, ever check the hash of that program that you own offline. It's a lot harder.
In a way, for ProtonMail (in your browser) to be "end-to-end encrypted", you have to trust Proton. But that kind of defeats the purpose of end-to-end encryption.
Same applies to e.g. WhatsApp Web, which is an interesting example because there exists a browser extension allowing you to "validate" that you run the code Meta expects you to run. Though you still have to trust Meta: the extension only helps making sure that nobody other than Meta is abusing you. The WhatsApp mobile app doesn't have that problem, as it is distributed as an archive by a third party (Play Store).
- IAmBroom 7mo ago> In a way, for ProtonMail (in your browser) to be "end-to-end encrypted", you have to trust Proton. But that kind of defeats the purpose of end-to-end encryption. Yes, and every VPN in the world (that isn't self-hosted) relies on trust that they won't share your info, not even your fingerprint - which defeats the purpose of VPNs. It's very hard to have perfect security. OK, impossible.
- palata 7mo agoSure, it's always a tradeoff. There is no "perfect" security, but there is "better" and "worse" for the threat model. My point here is that when you run a webapp from a browser, you have to trust the server. When you run a program that you download on your system, it's easier to check that it doesn't change and to make sure that others get the same one.
- mapontosevenths 7mo agoExactly, as with all security you have to ask what the threat model you're defending against is and what you're willing to pay. If it's "Google knows too much and I want an alternative" Proton is great, cheap, and convienent. If it' "my own government might kill me" then it might be time to think about self hosting.
- palata 7mo ago> "Google knows too much and I want an alternative" Proton is great, cheap, and convienent. I think that Proton does a good job with the suite (docs, sheets, calendar, password manager), and I believe they have a good VPN (for what we may expect from a VPN). Interestingly, Proton started with ProtonMail, and I find it's the least convincing of their products: 1. As an individual, writing from your ProtonMail account to (probably) someone on GMail doesn't change anything. 2. As a company, writing from Proton to Proton is a good idea, but there is no need for end-to-end encryption: just choose a mail provider you trust, I guess? 3. The ProtonMail end-to-end encryption in the web browser defeats the purpose of E2EE: you have to trust Proton anyway, because they serve the code every time your employees load the page.