It’s actually fairly simple: if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.
They use PGP, and they have implemented this feature in a way that it’s completely transparent to the user to make it mainstream. So they chose building dedicated tools (bridge, web client), rather than letting users use their own tools, because the PGP tooling sucks hard and it’s extremely inaccessible for the general population.
This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee. Instead of using enigmail or other PGP plugins/tools, they built the bridge.
if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.
Proton stores your keys, and you have the decryption password. How do you think they handle password-based logins? Only the user should ever generate and store the private key. All they need now is your decryption password & they can read your messages. This is reason #1 not to trust Proton.
They use PGP, and they have implemented this feature in a way that it’s completely transparent to the user to make it mainstream.
It isn’t transparent, because most users aren’t running their own frontend locally and tracking all the source code changes. They’ve already violated the first rule of PGP privacy by having your private key. Now you’re merely trusting them to not send you a custom JS payload to have your decryption password sent to the server. How many users are actually utilizing their hidden API to ensure that decryption/encryption is only done client-side? If they have your private key, how many users do you think are using long enough passwords to make cracking their password more challenging? This is reason #2 to not trust Proton.
PGP tooling sucks hard and it’s extremely inaccessible for the general population.
This is just entirely inaccurate and you’ve failed to provide any "proof’ for your generalizations here.
This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee.
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. Furthermore, the other apps by Proton like Proton Pass, Calendar, etc… all use undocumented APIs that they have yet to implement in their bridge using standard protocols like CalDav/CardDav/JSON or whatever else in order to be able to integrate with local tools. 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.
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.
It doesn’t matter that your private key is stored on their servers encrypted/hased or whatever. If you were simply storing it there, that would not be an issue. The problem is that you’re also logging in and relying on whatever JS is sent to you to only happen client-side.
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.
Most users aren’t sending emails from their Proton to other Proton users either. Furthermore, the users that want encryption seek it out. They don’t need to use Proton for encryption, especially when it would be easy for them to get an unknowing users decryption password.
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.
Yes, you have to trust source code somewhere, but with Thunderbird or other mail clients that is open source and their apps are signed or you can reproducibily build from source. However, once that is built it doesn’t change. With Proton, everytime you visit their site you don’t know for sure that it hasn’t changed unless you’re monitoring the traffic. A government is much more likely to convince Proton to send a single user a custom JS payload, than to modify the source code of Thunderbird in a way that would create an exploit that bypasses firewalls, system sandboxing, etc.
I mean, their clients are open-source and have also been audited?
You mean their PWA/WebView clients that can still send custom JS at anytime, or their bridge?
Care to share any practical example/link, and how exactly this means not having a fat client that does the encryption/decryption for you?
First, explain what you mean by a fat client? GnuPG is not a fat client.
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.
Being able to export things is a lot different than being able to use Thunderbird for Calendars, or a different Contacts app on your phone. DAV is as secure as the server you run it on and the certificate you use for transport.
It doesn’t matter that your private key is stored on their servers encrypted/hased or whatever. If you were simply storing it there, that would not be an issue. The problem is that you’re also logging in and relying on whatever JS is sent to you to only happen client-side.
I feel like I covered this point? They make the client tool you are using, there is 0 need for them to steal your password to decrypt your key. Of course you are trusting them, you are seeing your unencrypted email in their webpage, where they can run arbitrary code. They do have their clients opensourced, but this doesn’t mean much. You are always exposed to a supply-chain risk for your client software.
Most users aren’t sending emails from their Proton to other Proton users either.
So…? The point is, if they do, encryption happen without them having to do anything, hence transparently. That was the point of my argument: my mom can make a proton account and send me an email and benefit from PGP without even knowing what PGP is.
Furthermore, the users that want encryption seek it out.
And that’s the whole point of the conversation: these users are techies and a super tiny minority. This way, they made a product that allow mainstream users to have encryption.
Thunderbird or other mail clients that is open source and their apps are signed or you can reproducibily build from source.
And this control is worth zilch if they get compromised. This is a control against a MiTM who intercepts your download, it’s not a control if “the maker of Thunderbird” decides to screw you over in the same way that Proton would do by serving malicious JS code.
If the threat actor you are considering is a malicious software supplier, you have exactly the same issue. There can be pressures from government agencies, the vendor might decide to go bananas or might get compromised.
However, once that is built it doesn’t change. With Proton, everytime you visit their site you don’t know for sure that it hasn’t changed unless you’re monitoring the traffic.
Yes, this is true and it’s the real only difference.
I consider it a corner case and something that only affects the time needed to compromise your emails, not the feasibility, but it’s true. I am counting on the other hand on a company who has business interests in not letting that happen and a security team to support that work.
A government is much more likely to convince Proton to send a single user a custom JS payload, than to modify the source code of Thunderbird in a way that would create an exploit that bypasses firewalls, system sandboxing, etc.
Maybe…? If government actors are in your threat model, you shouldn’t use email in the first place. Metadata are unencrypted and cannot be encrypted, and there are better tools. That said, government agencies have the resources to target the supply chain for individuals and simply “encourage” software distributors to distribute patched versions of the software. This is also a much better strategy because it’s likely they can just get access to the whole endpoint and maintain easy persistence (while with JS you are in the browser sandbox and potentially system sandbox), potentially allowing to compromise even other tools (say, Signal). So yeah, the likelihood might be higher with JS-based software, but the impact is smaller. Everyone has their own risk appetite and can decide what they are comfortable with, but again, if you are considering the NSA (or equivalent) as your adversaries, don’t use emails.
You mean their PWA/WebView clients that can still send custom JS at anytime, or their bridge?
Yes.
First, explain what you mean by a fat client? GnuPG is not a fat client.
In computer networking, a rich client (also called heavy, fat or thick client) is a computer (a “client” in client–server network architecture) that typically provides rich functionality independent of the central server.
What I mean is this: a client that implements quite some functionality besides what the server would require to work. In this case, the client handles key management, encryption, decryption, signature verification etc. all functionalities that the server doesn’t even know they exist.
This is normal, because the encryption is done on top of regular email protocols, so they require a lot of logic in the client side.
Being able to export things is a lot different than being able to use Thunderbird for Calendars, or a different Contacts app on your phone.
For sure it’s different, I didn’t say it’s the same thing. I am saying that you can migrate away easily if your needs change and you’d rather have interoperability.
DAV is as secure as the server you run it on and the certificate you use for transport.
Exactly. Which is why in the very comment you quoted I said:
There is a security benefit, and the benefit is trusting the client software more than a server, especially if shared.
Are you trusting your Nextcloud instance (yours of hosted by someone else) not getting pwned/the server being seized/accessed physically/etc. more than you trust Proton not to get pwnd? Then *Dav tools might be for you.
All good points. It seems like we mostly agree on the same concepts. I don’t disagree that people using Proton may have better privacy overall than other services, but I do disagree on the way they implemented it and find their design decisions and approach to be questionable. It screams that they are profit-hungry and admire Apple’s walled garden.
It’s actually fairly simple: if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.
They use PGP, and they have implemented this feature in a way that it’s completely transparent to the user to make it mainstream. So they chose building dedicated tools (bridge, web client), rather than letting users use their own tools, because the PGP tooling sucks hard and it’s extremely inaccessible for the general population.
This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee. Instead of using enigmail or other PGP plugins/tools, they built the bridge.
Proton stores your keys, and you have the decryption password. How do you think they handle password-based logins? Only the user should ever generate and store the private key. All they need now is your decryption password & they can read your messages. This is reason #1 not to trust Proton.
It isn’t transparent, because most users aren’t running their own frontend locally and tracking all the source code changes. They’ve already violated the first rule of PGP privacy by having your private key. Now you’re merely trusting them to not send you a custom JS payload to have your decryption password sent to the server. How many users are actually utilizing their hidden API to ensure that decryption/encryption is only done client-side? If they have your private key, how many users do you think are using long enough passwords to make cracking their password more challenging? This is reason #2 to not trust Proton.
This is just entirely inaccurate and you’ve failed to provide any "proof’ for your generalizations here.
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. Furthermore, the other apps by Proton like Proton Pass, Calendar, etc… all use undocumented APIs that they have yet to implement in their bridge using standard protocols like CalDav/CardDav/JSON or whatever else in order to be able to integrate with local tools. 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.
Proton stores an encrypted blob.
“All they need now is your private key”. It’s literally a secret, they use
bcryptand 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…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.
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.
I mean, their clients are open-source and have also been audited?
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.See other post.
Care to share any practical example/link, and how exactly this means not having a fat client that does the encryption/decryption for you?
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.
You are awesome!
It doesn’t matter that your private key is stored on their servers encrypted/hased or whatever. If you were simply storing it there, that would not be an issue. The problem is that you’re also logging in and relying on whatever JS is sent to you to only happen client-side.
Most users aren’t sending emails from their Proton to other Proton users either. Furthermore, the users that want encryption seek it out. They don’t need to use Proton for encryption, especially when it would be easy for them to get an unknowing users decryption password.
Yes, you have to trust source code somewhere, but with Thunderbird or other mail clients that is open source and their apps are signed or you can reproducibily build from source. However, once that is built it doesn’t change. With Proton, everytime you visit their site you don’t know for sure that it hasn’t changed unless you’re monitoring the traffic. A government is much more likely to convince Proton to send a single user a custom JS payload, than to modify the source code of Thunderbird in a way that would create an exploit that bypasses firewalls, system sandboxing, etc.
You mean their PWA/WebView clients that can still send custom JS at anytime, or their bridge?
First, explain what you mean by a fat client? GnuPG is not a fat client.
Being able to export things is a lot different than being able to use Thunderbird for Calendars, or a different Contacts app on your phone. DAV is as secure as the server you run it on and the certificate you use for transport.
I feel like I covered this point? They make the client tool you are using, there is 0 need for them to steal your password to decrypt your key. Of course you are trusting them, you are seeing your unencrypted email in their webpage, where they can run arbitrary code. They do have their clients opensourced, but this doesn’t mean much. You are always exposed to a supply-chain risk for your client software.
So…? The point is, if they do, encryption happen without them having to do anything, hence transparently. That was the point of my argument: my mom can make a proton account and send me an email and benefit from PGP without even knowing what PGP is.
And that’s the whole point of the conversation: these users are techies and a super tiny minority. This way, they made a product that allow mainstream users to have encryption.
And this control is worth zilch if they get compromised. This is a control against a MiTM who intercepts your download, it’s not a control if “the maker of Thunderbird” decides to screw you over in the same way that Proton would do by serving malicious JS code. If the threat actor you are considering is a malicious software supplier, you have exactly the same issue. There can be pressures from government agencies, the vendor might decide to go bananas or might get compromised.
Yes, this is true and it’s the real only difference. I consider it a corner case and something that only affects the time needed to compromise your emails, not the feasibility, but it’s true. I am counting on the other hand on a company who has business interests in not letting that happen and a security team to support that work.
Maybe…? If government actors are in your threat model, you shouldn’t use email in the first place. Metadata are unencrypted and cannot be encrypted, and there are better tools. That said, government agencies have the resources to target the supply chain for individuals and simply “encourage” software distributors to distribute patched versions of the software. This is also a much better strategy because it’s likely they can just get access to the whole endpoint and maintain easy persistence (while with JS you are in the browser sandbox and potentially system sandbox), potentially allowing to compromise even other tools (say, Signal). So yeah, the likelihood might be higher with JS-based software, but the impact is smaller. Everyone has their own risk appetite and can decide what they are comfortable with, but again, if you are considering the NSA (or equivalent) as your adversaries, don’t use emails.
Yes.
What I mean is this: a client that implements quite some functionality besides what the server would require to work. In this case, the client handles key management, encryption, decryption, signature verification etc. all functionalities that the server doesn’t even know they exist. This is normal, because the encryption is done on top of regular email protocols, so they require a lot of logic in the client side.
For sure it’s different, I didn’t say it’s the same thing. I am saying that you can migrate away easily if your needs change and you’d rather have interoperability.
Exactly. Which is why in the very comment you quoted I said:
Are you trusting your Nextcloud instance (yours of hosted by someone else) not getting pwned/the server being seized/accessed physically/etc. more than you trust Proton not to get pwnd? Then *Dav tools might be for you.
All good points. It seems like we mostly agree on the same concepts. I don’t disagree that people using Proton may have better privacy overall than other services, but I do disagree on the way they implemented it and find their design decisions and approach to be questionable. It screams that they are profit-hungry and admire Apple’s walled garden.
some people want to be swindled.