Hacker News Reader

Comment by twiss | Hacker News Reader

Hi! Proton crypto team lead here. Our motto is "Privacy by default". We're aiming to fulfill that mission as much as is practically possible. In this case, looking up keys on keys.openpgp.org caused an issue for this user because they didn't know they have a key there. We'll try to make that more clear in the received (encrypted) emails - and we might look into opting out somehow.

However, we don't want to make it opt-in if we can avoid it, even if that's what would make sense for Linux, Windows and Apple; it's not what would make sense for Proton. You can't change the world by copying someone else :)

View on HN

"Privacy by default" is a good motto when the mechanisms used to ensure privacy actually work most of the time. I'm sure that between ProtonMail users, it does indeed work most (if not all) of the time.

But once you leave the ProtonMail ecosystem, I expect you'll find that enabling PGP automatically doesn't work most or all of the time. It likely only works occasionally or even rarely.

> You can't change the world by copying someone else :)

Please take this as gently as I intend it: ProtonMail is unlikely to change the world on user privacy, at least when it comes to email. Larger providers are too entrenched, and most people won't care enough about privacy to change their email address (and very few people have a custom email domain to move between providers).

At any rate, it seems like you're copying Facebook: "move fast and break things". Not great when we're talking about messaging. You're breaking email for some people, and some of those people are your users. OP may not be one of your users, but OP's mom is, and you have broken her ability to send her son email with this misguided policy.

Obviously, rolling out end-to-end encryption in a federated system is difficult. We need to start somewhere, but obviously the outcome for OP was not ideal. That being said, we haven't actually had that many complaints about rolling this out. We'll still work to improve it further, obviously, and reduce failure cases like this. And, we'll take the feedback on board about moving more carefully and communicating such changes better.

> most people won't care enough about privacy to change their email address

Note that with this change, you don't need to change providers to get end-to-end encrypted email: you can let your email client or a browser plugin (like FlowCrypt or Mailvelope) handle OpenPGP for you, and (let it) upload your key to keys.openpgp.org, and we'll send you encrypted email. Obviously, signing up for Proton is still easier, but email is a federated system, and so I think it's important to invest in the feasibility of federated E2EE as well :)

Are you aware of any ergonomic solution for iOS, or for people that don't want to risk giving a browser extension full access to their webmail?

Otherwise, it seems like you're fine with breaking email delivery to everybody using that ever having published an OpenPGP key (and verified their email address) to the public keyserver.

> when the mechanisms used to ensure privacy actually work most of the time.

Privacy was indeed preserved -- at the cost of communication.

> We'll try to make that more clear in the received (encrypted) emails

This seems like the ideal. If the message could look like

> This message from mom@protonmail.com was encrypted by PGP using the public key for foo@gmail.com retrieved from www.keys.openpgp.org

> -- BEGIN PGP MESSAGE -- ...

Would that leak anything the email provider and every forwarding server couldn't already have known? Not sure if clients support this kind of mix of plaintext and PGP: of course you could put the metadata in the headers, but clients won't show random new headers by default and Google isn't going to help you encrypt messages they would prefer to read.

All of this is public information, so it shouldn't leak anything. So indeed we'll look into whether we can make this information show up in an interoperable way.

I suggest Proton to stick with the WKD procedure. Having CNAME record pointing to wkd.keys.openpgp.org or serving the public key on openpgpkey.example.org subdomain can be indicators showing that the receiver is willing to received email encrypted with the public key served via WKD. Otherwise, no need to fetch the key from public keyservers.

Reply on news.ycombinator.com