But you can get secure email if you’re the sender (you can choose to encrypt) or it’s coming from someone else at Proton.
But yeah, there should be a secure alternative, perhaps an amendment to SMTP where only the “to” address is available. If I have the public key of the receiver (negotiation of that could be part of the protocol), I can encrypt everything else and my email could still be routed properly.
Yeah, this is one of the things that I quite like about Proton. It provides a migration path. You start sending and receiving plain-text mail (then encrypted before saving) but now you can use an open standard protocol to start communicating securely and Proton can slowly lose the ability to read much of your email.
IDK if the other “easy encrypted” providers just use standard PGP.
AFAIK, Proton’s standard is PGP, they just manage the keys for you (I’m guessing keys are AES encrypted and decrypted on the client) (source):
Proton Mail’s end-to-end encryption is based on an open-source version of PGP.
Tuta doesn’t use PGP, but it uses open encryption standards for it. So it’s a wash IMO since both are only used for internal emails (within their respective platforms).
For messages to external email addresses, they use pretty much the same thing: password-protected access through their platform (i.e. you click a link to Proton or Tuta and enter the password to decrypt).
I don’t know about other email services, but those two both seem pretty good, regardless of whether PGP or GPG is used internally. I haven’t reviewed the source code of either, but both have open clients so maybe I’ll get around to it at some point.
Yes, agreeing in general, just with some clarifications. I think clarifications are important when talking about a product focused on privacy and security.
I was responding to this part:
IDK if the other “easy encrypted” providers just use standard PGP.
All Proton Mail data at rest and in transit is encrypted. However, subject lines in Proton Mail are not end-to-end encrypted, which means if served with a valid Swiss court order, we do have the ability to turn over the subjects of your messages. Your message content and attachments are end-to-end encrypted.
Depending on your threat model, this may or may not be an issue.
At least one other provider (Tuta in my example) doesn’t use PGP internally because using SMTP internally w/ PGP for the body leaks the subject line and other metadata. Neither have released the source to their backend, and I haven’t read the client code, so I don’t know if there are any other concerns.
That I think Proton is absolutely fantastic, and I used it for a few years with absolutely no issue. I do think it’s important to be accurate, though, since others may not like the tradeoffs. Proton has a bunch of other benefits as well over alternatives, such as:
IMAP bridge - you can use whatever email client you want and back up emails yourself - this does decrypt your email though, so you’d need to account for that
automatic forwarding - seems to just work as expected
other bundled services - I’ve used their VPN, and they have a few other things other providers don’t (e.g. encrypted storage)
Proton… standard protocol
Yeah, any email provider will use standard SMTP, otherwise it’s not email. The differences are whatever happens after it reaches Proton’s servers.
But you can get secure email if you’re the sender (you can choose to encrypt) or it’s coming from someone else at Proton.
But yeah, there should be a secure alternative, perhaps an amendment to SMTP where only the “to” address is available. If I have the public key of the receiver (negotiation of that could be part of the protocol), I can encrypt everything else and my email could still be routed properly.
Yeah, this is one of the things that I quite like about Proton. It provides a migration path. You start sending and receiving plain-text mail (then encrypted before saving) but now you can use an open standard protocol to start communicating securely and Proton can slowly lose the ability to read much of your email.
IDK if the other “easy encrypted” providers just use standard PGP.
AFAIK, Proton’s standard is PGP, they just manage the keys for you (I’m guessing keys are AES encrypted and decrypted on the client) (source):
Tuta doesn’t use PGP, but it uses open encryption standards for it. So it’s a wash IMO since both are only used for internal emails (within their respective platforms).
For messages to external email addresses, they use pretty much the same thing: password-protected access through their platform (i.e. you click a link to Proton or Tuta and enter the password to decrypt).
I don’t know about other email services, but those two both seem pretty good, regardless of whether PGP or GPG is used internally. I haven’t reviewed the source code of either, but both have open clients so maybe I’ll get around to it at some point.
I think you are agreeing with me. I like Proton because it uses a standard protocol and it provides a migration path from unencrypted to encrypted.
PGP and GPG are effectively synonyms in this context. (GPG is just an implementation of PGP)
Yes, agreeing in general, just with some clarifications. I think clarifications are important when talking about a product focused on privacy and security.
I was responding to this part:
Proton uses standard PGP AFAIK (and yes, PGP vs GPG is irrelevant), so your subject line and attachment names are not end-to-end encrypted:
Depending on your threat model, this may or may not be an issue.
At least one other provider (Tuta in my example) doesn’t use PGP internally because using SMTP internally w/ PGP for the body leaks the subject line and other metadata. Neither have released the source to their backend, and I haven’t read the client code, so I don’t know if there are any other concerns.
That I think Proton is absolutely fantastic, and I used it for a few years with absolutely no issue. I do think it’s important to be accurate, though, since others may not like the tradeoffs. Proton has a bunch of other benefits as well over alternatives, such as:
Yeah, any email provider will use standard SMTP, otherwise it’s not email. The differences are whatever happens after it reaches Proton’s servers.