Proton mail has some extra (security?) feature, or they just lack smtp support, and you cannot directly use it on thunderbird. They offer a “bridge” app which allows you to do it, I just use that.
Proton’s whole thing is it’s meant to be secure, private, encrypted, etc. To achieve that, it requires the Proton app or website as an endpoint, so your email never leaves Proton’s environment. As long as your reading your email in the Proton app/site, they can guarantee its privacy and security.
Once it sends your emails to Thunderbird or another client, it’s leaving the Proton environment, and they can no longer control it. You’re sacrificing the inherent privacy/security of Proton when you use Thunderbird (they claim).
All of that being said, it’s an absolutely bullshit excuse. Tutanota does this same shit, only they don’t even provide the bridge like Proton does.
It’s true it’s technically more secure for those emails to stay in the Proton environment, but they’re still your god damn emails, and they should operate like every other email service by giving the user the option to export those emails in whatever way they damn well please, for free.
It’s just more platform lock-in garbage. Your emails are trapped on their server, so they’ll be no moving away to a different provider easily.
It’s more that they claim they cannot decrypt your data, so how do they send it to Thunderbird? The bridge does the decryption. Theoretically Thunderbird could add support for it.
Corps have used that BS excuse for ages. The whole “your phone is more secure when we control it” is a garbage BS line. Make it open source, give developers the tools & they’ll make any app more secure than some bureaucracy that is constantly influenced by the national security agencies.
None of those actually document their API nor provide source for the backend server code. Other than building hydroxide from PRs for CalDav, are there even any other open source implementations of CardDav/CalDav for Proton? I can’t find a single implementation of Proton Pass that allows you to sync your passwords locally and be used in a different app. There is no shortage of people complaining about this:
Why would anyone be interested in efforts on a platform with a closed-source backend and that is not developer focused? 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.
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.
IMAPs is just IMAP on TLS, so it does not have anything to do with e2ee in this context.
If you use GnuPG or one of the GUI implementations it does.
You do realize e2ee merely means that two users share public keys when they communicate in order to decrypt the messages they receive, right?
*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).
You’re talking about people paying for cloud services that manage everything for them. Nothing to stop you from hosting your own on an encrypted drive. EteSync does E2E already, and there is already a plethora of apps supporting PGP on Android and Desktop to encrypt/decrypt messages.
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.
I never really understood the need for such apps when mail clients such as Thunderbird exist.
Proton mail has some extra (security?) feature, or they just lack smtp support, and you cannot directly use it on thunderbird. They offer a “bridge” app which allows you to do it, I just use that.
Proton’s whole thing is it’s meant to be secure, private, encrypted, etc. To achieve that, it requires the Proton app or website as an endpoint, so your email never leaves Proton’s environment. As long as your reading your email in the Proton app/site, they can guarantee its privacy and security.
Once it sends your emails to Thunderbird or another client, it’s leaving the Proton environment, and they can no longer control it. You’re sacrificing the inherent privacy/security of Proton when you use Thunderbird (they claim).
All of that being said, it’s an absolutely bullshit excuse. Tutanota does this same shit, only they don’t even provide the bridge like Proton does.
It’s true it’s technically more secure for those emails to stay in the Proton environment, but they’re still your god damn emails, and they should operate like every other email service by giving the user the option to export those emails in whatever way they damn well please, for free.
It’s just more platform lock-in garbage. Your emails are trapped on their server, so they’ll be no moving away to a different provider easily.
It’s more that they claim they cannot decrypt your data, so how do they send it to Thunderbird? The bridge does the decryption. Theoretically Thunderbird could add support for it.
Corps have used that BS excuse for ages. The whole “your phone is more secure when we control it” is a garbage BS line. Make it open source, give developers the tools & they’ll make any app more secure than some bureaucracy that is constantly influenced by the national security agencies.
https://github.com/ProtonMail
glhf
None of those actually document their API nor provide source for the backend server code. Other than building hydroxide from PRs for CalDav, are there even any other open source implementations of CardDav/CalDav for Proton? I can’t find a single implementation of Proton Pass that allows you to sync your passwords locally and be used in a different app. There is no shortage of people complaining about this:
https://protonmail.uservoice.com/forums/932842-proton-calendar/suggestions/8985673-cardav-caldav-support https://brainbaking.com/post/2023/01/goodbye-protonmail/ https://minutestomidnight.co.uk/blog/email-migration-from-proton-to-mailbox/
Why would anyone be interested in efforts on a platform with a closed-source backend and that is not developer focused? 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.
Because most people don’t care about those particular things. Almost all the world uses completely proprietary tools (Gmail) that also violate your privacy.
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.
If you use GnuPG or one of the GUI implementations it does.
You do realize e2ee merely means that two users share public keys when they communicate in order to decrypt the messages they receive, right?
You’re talking about people paying for cloud services that manage everything for them. Nothing to stop you from hosting your own on an encrypted drive. EteSync does E2E already, and there is already a plethora of apps supporting PGP on Android and Desktop to encrypt/decrypt messages.
Proton forces you to pay for a bridge to use Thunderbird.
Tutanota doesn’t even provide that.
These “privacy respecting” email services don’t respect the user enough to let them use third party email clients easily if the user chooses to.
They cannot decrypt your data while sitting, so IMAP cannot work.
Go ahead and explain what you mean. I don’t believe you & think you’re just parroting their corpo speak.
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.
some people want to be swindled.