[8organicbits]

> FWIW, private keys are stored encrypted on the server, we don't have access to them.

I'm always bothered by statements like this because it appears to be skimming over if the provider can perform cryptography with the key. My understanding is that those keys are only decrypted in the users apps/web browser, not server-side. Is that right?

You need to trust that the provider doesn't perform additional operations along side legitimate user triggered actions, which I believe PM handles.

https://proton.me/blog/encrypted-email

[twleo]

Even if all the decryption resides in the app/web browser side, they can just silently change the code and inject some scripts to hijack the encryption routine.

Although they are open-source and can be scrutinized by anybody, it does not means that's what is run on the server side.

(Just say they have the capability; no accusation)

So at the end of the day, the question is whether you trust Proton or not. Encryption might not help in that case.

[twiss]

Yeah. For web, I've been advocating for something like "Source Code Transparency" (somewhat analogous to Certificate Transparency) in the WebAppSec WG at the W3C. The idea would be that if you could verify that the source code you're getting is the same as what everyone else is getting for a given version of the web app (and has been published in an append-only log of sorts), it would be much more difficult for us to try to compromise any given user without detection.

On mobile, to do such an attack we'd have to collaborate with Apple or Google to do it, which IMHO seems infeasible - but nevertheless also there a "Binary Transparency" feature of sorts might be valuable.

[8organicbits]

> I've been advocating for something like "Source Code Transparency"

Thank you for moving the web forward. Proton mail does a lot of things well, and there's more to do. I was auditing DANE support and PM was one of the few I found with support.

[twiss]

Correct, private keys can only be decrypted client-side, the server doesn't have access to the password that they're encrypted with. Otherwise it wouldn't be end-to-end encryption, IMO :)

[e12e]

But you distribute the js that accepts the passphrase - so you could trivially exfiltrate the password - and so access the private key.

"Don't have access" is a little too strongly worded IMNHO.

(I understand the reasoning - and I don't necessarily think it's bad - I just think it overpromises a bit)

[twiss]

Sure, fair enough. I've edited it to "the server doesn't have access". Also, see https://news.ycombinator.com/item?id=36643922.

[cuteboy19]

The app ultimately shows you your decrypted email. If client side code is compromised then I don't think this is the thing you worry about

[e12e]

Sending signed and encrypted emails is worse than just reading.