They say the reason for needing their bridge is the encryption at rest, but I feel like the better way to handle wanting to push email privacy forward would be to publish (or better yet coordinate with other groups on drafting) a public standard that both clients and competing email servers could adopt for an email syncing protocol for that sort of zero-access encryption that requires users give their client a key file. A bridge would be easier to swallow as a fallback option until there’s wider client support rather than as the only way.
A similar standard for server-to-server communication, like for automatic pgp key negotiation, would be nice too.
Still, Proton has a easy to access data export that doesn’t require a bridge client or subscription or anything. I think that’s required by GDPR. It’s manual enough to not be an effective way to keep up-to-date backups in case you ever abruptly lose access but it’s good enough to handle wanting to migrate to another provider.
What Proton is doing to e-mail is about the same that WhatsApp, Messenger and others did to messaging - instead of just using an open protocol like XMPP they opted for their closed thing in order to lock people into their apps.
PGP is not closed. What proton has done is make a really cool JS library for PGP as part of their Web UI (openpgpjs.org) which other projects, even those unrelated to Proton have used, like Mailvelope. They’re also pushing the PGP standard itself to support stuff like post-quantum encryption. So this is really odd to hear as Proton is, without a doubt, the most open and interoperable of all the properly encrypted providers.
Lavabit
With Lavabit, you were simply trusting them mostly blindly on their claims. Yeah it worked out that one time but could have gone very wrong.
Yes, they have it because GDPR does require it.
They’ve had it since far before GDPR took affect. They’ve also had bridge which has always allowed external backups and is in fact real time. They now also support forwarding mails, which should also suffice for your use case.
Open sourcing the server software is desired ofc, but would it really mean a lot for security? Not really. All the relevant bits are already open source. And none of it is really non-standard. But i do still wish for that for the sake of transparency. And yeah i wish they would move away from this almost source-available model.
Regarding SMTP, yeah i agree. But they do provide that through bridge and also for business users based on a per-request basis.
There are definitely a few artificial limitations and stuff that really pisses me off, like the limit on aliases in custom domains and SMTP for normal paid users, but a lot of the talk I’m hearing on lemmy about proton is just FUD.
They can’t do traditional IMAP/SMTP simply because they always do client-side auth rather than tradition server-side auth, which inherently makes them more trustworthy than every other provider that does offer IMAP/SMTP-based provider to whom you always send your passwords in plaintext. This has the added benefit of having at least your own mailbox always be zero access encrypted.
The bridge does the decryption using credentials you give it locally. Sorry for mentioning “auth”. I should have mentioned encryption instead.
Regarding the rest, it comes down to the zero access mailbox encryption’s implementation details. In all described scenarios, you’re not really using your master password as the “key” for your mailbox. But in proton’s and similar services’ case like Tuta, this is true. Any “zero access” service provider offering IMAP access without a bridge is simply lying to you as IMAP (the protocol itself) requires server-side decryption of the content, even if SMTP doesn’t. (Btw, SMTP is really an artificial limitation. Just not IMAP. If they give you smtp access, it wouldn’t send encrypted mails unless specifically configured to do so but would otherwise be the same.)
What you described is encryption at rest, but not zero access encryption (which is what Purelymail does btw).
Whether all this is needed and all depends on your threat model. I think most tech-savvy folks would be happy with something like Purelymail or Migadu tbh…
I’m not sure if this is required. Any decent e-mail server uses TLS to communicate these days, so everything in transit is already encrypted.
In transit, yes, but not end-to-end.
One feature that Proton advertises: when you send an email from one Proton mail account to another Proton address, the message is automatically encrypted such that (assuming you trust their client-side code for webmail/bridge) Proton’s servers never have access to the message contents for even a moment. When incoming mail hits Proton’s SMTP server, Proton technically could (but claims not to) log the unencrypted message contents before encrypting it with the recipient’s public key and storing it. That undermines Proton’s promise of Proton not having access to your emails. If both parties involved in an email conversation agree to use PGP encryption then they could avoid that risk, and no mail server on either end would have access to anything more than metadata and the initial exchange of public keys, but most humans won’t bother doing that key exchange and almost no automated mailers would.
Some standard way of automatically asking a mail server “Does user@proton.me have a PGP public key?” would help on this front as long as the server doesn’t reject senders who ignore this feature and send SMTP/TLS as normal without PGP. This still requires trusting that the server doesn’t give an incorrect public key but any suspicious behavior on this front would be very noticeable in a way that server-side logging would not be. Users who deem that unacceptable can still use a separate set of PGP keys.
I had assumed their reasoning for not taking that approach might be related to metadata at rest, but it seems they don’t use “zero access” encryption for metadata even at rest so I have no idea what technical justification they could have for not supporting IMAP with PGP handled by the email client. The fact that they restrict bridge access to paying subscribers only doesn’t help them avoid lock-in impressions either.
Iirc, all the emails are stored locally so I guess if proton goes down, you can still access the emails on your phone. Same with cakendar, contacts in proton, and hopefully notes
Edit: nevermind, the emails are only stored if you accessed them before.
Removed by mod
Huh? This is not true. Proton have an app that exports all your emails for reimport into the platform of your choice.
Removed by mod
They say the reason for needing their bridge is the encryption at rest, but I feel like the better way to handle wanting to push email privacy forward would be to publish (or better yet coordinate with other groups on drafting) a public standard that both clients and competing email servers could adopt for an email syncing protocol for that sort of zero-access encryption that requires users give their client a key file. A bridge would be easier to swallow as a fallback option until there’s wider client support rather than as the only way.
A similar standard for server-to-server communication, like for automatic pgp key negotiation, would be nice too.
Still, Proton has a easy to access data export that doesn’t require a bridge client or subscription or anything. I think that’s required by GDPR. It’s manual enough to not be an effective way to keep up-to-date backups in case you ever abruptly lose access but it’s good enough to handle wanting to migrate to another provider.
Removed by mod
Do you have a privacy oriented email provider alternative to proton?
I have my domain name, but I don’t want to manage an email server on my server.
Removed by mod
Thanks I will read the links.
Please don’t use privacytools.io anymore. Use privacyguides.org instead
Removed by mod
https://www.privacyguides.org/en/about/privacytools/
Removed by mod
What’s wrong with Privacy Tools?
https://www.privacyguides.org/en/about/privacytools/
Good to know, thanks.
PGP is not closed. What proton has done is make a really cool JS library for PGP as part of their Web UI (openpgpjs.org) which other projects, even those unrelated to Proton have used, like Mailvelope. They’re also pushing the PGP standard itself to support stuff like post-quantum encryption. So this is really odd to hear as Proton is, without a doubt, the most open and interoperable of all the properly encrypted providers.
With Lavabit, you were simply trusting them mostly blindly on their claims. Yeah it worked out that one time but could have gone very wrong.
They’ve had it since far before GDPR took affect. They’ve also had bridge which has always allowed external backups and is in fact real time. They now also support forwarding mails, which should also suffice for your use case.
Open sourcing the server software is desired ofc, but would it really mean a lot for security? Not really. All the relevant bits are already open source. And none of it is really non-standard. But i do still wish for that for the sake of transparency. And yeah i wish they would move away from this almost source-available model.
Regarding SMTP, yeah i agree. But they do provide that through bridge and also for business users based on a per-request basis.
There are definitely a few artificial limitations and stuff that really pisses me off, like the limit on aliases in custom domains and SMTP for normal paid users, but a lot of the talk I’m hearing on lemmy about proton is just FUD.
Removed by mod
They can’t do traditional IMAP/SMTP simply because they always do client-side auth rather than tradition server-side auth, which inherently makes them more trustworthy than every other provider that does offer IMAP/SMTP-based provider to whom you always send your passwords in plaintext. This has the added benefit of having at least your own mailbox always be zero access encrypted.
Removed by mod
The bridge does the decryption using credentials you give it locally. Sorry for mentioning “auth”. I should have mentioned encryption instead.
Regarding the rest, it comes down to the zero access mailbox encryption’s implementation details. In all described scenarios, you’re not really using your master password as the “key” for your mailbox. But in proton’s and similar services’ case like Tuta, this is true. Any “zero access” service provider offering IMAP access without a bridge is simply lying to you as IMAP (the protocol itself) requires server-side decryption of the content, even if SMTP doesn’t. (Btw, SMTP is really an artificial limitation. Just not IMAP. If they give you smtp access, it wouldn’t send encrypted mails unless specifically configured to do so but would otherwise be the same.)
What you described is encryption at rest, but not zero access encryption (which is what Purelymail does btw).
Whether all this is needed and all depends on your threat model. I think most tech-savvy folks would be happy with something like Purelymail or Migadu tbh…
Removed by mod
In transit, yes, but not end-to-end.
One feature that Proton advertises: when you send an email from one Proton mail account to another Proton address, the message is automatically encrypted such that (assuming you trust their client-side code for webmail/bridge) Proton’s servers never have access to the message contents for even a moment. When incoming mail hits Proton’s SMTP server, Proton technically could (but claims not to) log the unencrypted message contents before encrypting it with the recipient’s public key and storing it. That undermines Proton’s promise of Proton not having access to your emails. If both parties involved in an email conversation agree to use PGP encryption then they could avoid that risk, and no mail server on either end would have access to anything more than metadata and the initial exchange of public keys, but most humans won’t bother doing that key exchange and almost no automated mailers would.
Some standard way of automatically asking a mail server “Does
user@proton.mehave a PGP public key?” would help on this front as long as the server doesn’t reject senders who ignore this feature and send SMTP/TLS as normal without PGP. This still requires trusting that the server doesn’t give an incorrect public key but any suspicious behavior on this front would be very noticeable in a way that server-side logging would not be. Users who deem that unacceptable can still use a separate set of PGP keys.Removed by mod
I had assumed their reasoning for not taking that approach might be related to metadata at rest, but it seems they don’t use “zero access” encryption for metadata even at rest so I have no idea what technical justification they could have for not supporting IMAP with PGP handled by the email client. The fact that they restrict bridge access to paying subscribers only doesn’t help them avoid lock-in impressions either.
Removed by mod
I think proton bridge is open source as well. I have all my emails locally on thunderbird
https://github.com/ProtonMail/proton-bridge
Removed by mod
Iirc, all the emails are stored locally so I guess if proton goes down, you can still access the emails on your phone. Same with cakendar, contacts in proton, and hopefully notes
Edit: nevermind, the emails are only stored if you accessed them before.
Removed by mod