Proton stores your keys

Proton stores an encrypted blob.

All they need now is your decryption password & they can read your messages

“All they need now is your private key”. It’s literally a secret, they use bcrypt and then encrypt it. Also, “they” are not generally in the threat model. “They” can serve you JS that simply exfiltrates your email, because the emails are displayed in their web-app, they have no need to steal your password to decrypt your key and read your email…

It isn’t transparent, because most users aren’t running their own frontend locally and tracking all the source code changes.

Probably we misunderstand what “transparent” means in this context. What I mean is that the average user will not do any PGP operation, in general. Encryption happens transparently for them, which is the whole thing about Proton: make encryption easy and default.

Now you’re merely trusting them to not send you a custom JS payload to have your decryption password sent to the server.

Again, as I said before, they control the JS, they can get the decrypted data without getting the password…? You always trust your client tooling. There is always a point where I trust someone, be it the “enigmail” maintainers, Thunderbird maintainers (it has access to messages post-decryption!), the CLI tool of choice etc.

How many users are actually utilizing their hidden API to ensure that decryption/encryption is only done client-side?

I mean, their clients are open-source and have also been audited?

If they have your private key, how many users do you think are using long enough passwords to make cracking their password more challenging?

I don’t know. But here we are talking about a different risk: someone compromising Proton, getting your encrypted private key, and starting bruteforcing bcrypt-hashed-and-salted passwords. I find that risk acceptable.

This is just entirely inaccurate and you’ve failed to provide any "proof’ for your generalizations here.

See other post.

If you actually understood PGP you’d know you can generate and use local-only keys with IMAPS and have support to use any IMAP client.

Care to share any practical example/link, and how exactly this means not having a fat client that does the encryption/decryption for you?

There is no security benefit in their implementation other than to lock you into a walled garden and give you a false sense of security.

Right, because *DAV protocol are so secure. They all support e2ee, right…? There is a security benefit, and the benefit is trusting the client software more than a server, especially if shared. You can export data and migrate when you want easily, so it’s really a matter of preference.

some people want to be swindled.

Why would anyone be interested in efforts on a platform with a closed-source backend and that is not developer focused?

Because most people don’t care about those particular things. Almost all the world uses completely proprietary tools (Gmail) that also violate your privacy.

Not to mention, entirely unnecessary why you should have to use a bridge gateway in the first place with IMAPS & PGP/GPG, CalDav & CardDav. Like I said, Proton is engaged in some questionable practices.

It’s not unnecessary, it’s the result of a technical choice. A winning technical choice actually. PGP has a negligible user-base, while Proton has already 100 million accounts. I would be surprised if there were 10 million people actually using PGP. They sacrificed the flexibility and composability of tools (which results almost always in complexity) and made an opinionated solution that works well enough for the mainstream population, who has no interest in picking their tools and simply expects a Gmail-like experience.

And if you really have stringent requirements, they anyway provided the bridge, so that you can have that flexibility if it’s really important for you.

IMAPS & PGP/GPG, CalDav & CardDav

• IMAPs is just IMAP on TLS, so it does not have anything to do with e2ee in this context.
• PGP/GPG is what they use. They just made a tool that is opinionated and just works, rather than one which is more flexible but also more complex. Good choice? Bad choice? It’s a choice.
• *DAV clients expect cleartext data on the server. If you encrypt the data, you need to build all this logic into the clients, and you are not following the standard anymore, which means you will anyway be bound to your client only (and those which implement compatibility). Proton decided that they want to implement e2ee calendar, and they decided to roll their own thing. It’s up to everyone to decide whether e2ee is a more important feature than interoperability with other tools. I don’t care about interoperability, for example, and I’d take e2ee over that.