Hacker News Reader

Comment by cdmckay | Hacker News Reader

Yeah, my mom would totally understand that prompt.

1. Given that Mom doesn't understand the bulk of the prompt, should we take away the prompt and encrypt the e-mail; i.e. treat the e-mail in a way she doesn't understand? (Maybe! After all sending an e-mail over TCP/IP and SMTP, and adding various headers and whatnot also treats it in ways Mom doesn't understand, and those have to be done. Or maybe not. Encryption literally obliterates the content, making it unreadable without the key.)

2. Your mom would likely understand "If unsure, answer No", and end up sending a normal e-mail. That text should be in bold, probably. Some of the verbiage could be behind some "learn more" link, where there is space and scope for a better explanation.

It is probably better if the switch is on the receiver's side, as some kind of Boolean field in the key registration record.

Given that mom isn't going to understand any of the prompt, and presumably has no pressing care or need for encrypting an email, the sensible default would be to send email unencrypted unless she expressly asks otherwise.

It is pretty interesting seeing the various different design philosophies for computer UIs compete in this thread:

the typical Linux approach (ask the user a convoluted question, expect them to understand it and expect an informed response - if/when the user selects wrong, tough shit)

the Windows approach (ask a convoluted question but give an out for the 99% of people who don't understand it - if the user still selects wrong, tough shit)

the Apple approach (don't ask the question at all and choose a sensible default, because 99% won't care - 99% of users get the exact result they wanted to begin with)

>the sensible default would be to send email unencrypted

That's exactly what anti-encryptionists would want.

That's the same sort of argument form as "everything encrypted is what the terrorists and child pornographers would want". Just sayin'.

Or realists that think that encryption-by-default needs to be designed very differently from PGP, and that forcing people into something brittle will not win any sympathy.

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 :)

"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.

"Mom" implicitly signed up for encrypted email when she decided to use Proton as her mail provider. It's what they're all about.

Why make unencrypted the default? For https, encrypted has become the default. Users don't need to understand certificates at all, but it works. We should have the same for email.

But that does require all clients to make this easy for the user.

HTTPS is transport-level encryption. If that's your benchmark, email is encrypted by default today – in that most SMTP connections are TLS-encrypted.

We should have the same for email.

But we don't. And while we don't, users have a reasonable expectation that they can send an email and the other person can read it.

>the sensible default would be to send email unencrypted

Why even use Proton then? What is the point?

Anyone can understand this

> If unsure, choose "No".

Unfortunately, when presented with a prompt they don't understand a lot of people stop reading entirely and just click "yes" to make it go away.

Those people will click the most brightly colored button, which in this case would be "no"

Reply on news.ycombinator.com