Hacker News Reader

Comment by Valodim | Hacker News Reader

keys.openpgp.org operator here. He uploaded his key and verified his address, it's discoverable, and people use it to send encrypted email. As far as we're concerned, that's not a bug, that's a feature.

Now, it is debatable whether the ecosystem is ready to be doing this at (some) scale by default. I agree it's not, dealing with e2e encrypted email is a less convenient experience than plaintext for most users. But not all - case on point, with Proton it's fine.

It's a valid question how opt in our out should work, with lots of implications and stakeholders involved. For better or worse, the status quo is that there is no signaling mechanism in openpgp (or keys.openpgp.org) at the moment to specify how a key should be used, so publishing a key is just a yes or no situation.

If op wants to offer encrypted email as a possible means of communication, but explicitly on an opt in basis, I would recommend a separate email address (or a tag, e.g. +encrypt) for that purpose.

View on HN

> people use it

Protonmail is not a person.

If the allegation is true, it looks like Protonmail decided to munge e-mails without anyone opting into it.

Spontaneously doing anything unusual with e-mails is a bad idea, until it becomes a standard behavior that everyone else does.

How about a prompt?

  Your recipient foo@example.com has registered a public key with openpgp.org.
  Would you like to encrypt this mail with they public key?
  If you know that the recipient is prepared for encrypted e-mails, say Yes.
  If unsure, choose "No".

  [ Yes ]    [ No ]      [ ] Don't ask again for this recipient

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"

How did OP not opt in? If they uploaded a key for their email address, then doesn't that mean they opted in?

I'm not familiar with any of this at all, but this sounds to me exactly how it should work: upload and verify the key, so people know they can use that key to send you encrypted email.

The thing protonmail might consider is to put an unencrypted standard message in the body that the message is encrypted because the recipient has published a key, so the recipient understands that it's encrypted and why it's encrypted.

They uploaded a key to a third-party website for their own reasons. They didn't upload it to Protonmail. Protonmail chose to interpret participation in that third-party website as participation in their E2E encrypted email format.

Baffling. This really is like buying a billboard with your phone number on it, along with text that reads "contact me!!" and then getting upset that you're getting phone calls.

The whole point of associating an encryption key with your email address on a public keyserver is so that you get encrypted mail!

Many keyservers don't verify you own the email address. Someone else could have uploaded a PGP key for your email. You shouldn't trust the value in the keyserver without additional confirmation via another channel (like giving someone the fingerprint in person).

And PGP/GPG keys are used for more than just email, so just because you have a key on a keyserver doesn't necessarily mean you want your emails encrypted with it.

1. This keyserver does.

2. Keys have types. These keys were marked for use for encryption. You can upload keys for signing only if you wanted to.

I just wanted to say that clearly keyservers needed to add this (both verification and specifying the purpose of the key), but clearly they have already done so.

I'm not surprised; these people think a lot more about these sort of things than I do.

One possible addition might be that maybe you could specify whether people should use the key to encrypt whenever possible, or only when security is absolutely vital. That's a setting that could pass the decision to encrypt to the sender (if clients support this).

Why would they have to upload it to protonmail? OP is not a protonmail user, is he? It would be ridiculous if encrypted communication would require explicitly uploading your key to each system from which someone might conceivably try to message you.

You opt in by having an email address and by having a published key associated with that email address.

"their own reasons" could very well be any of the following:

- It is necessary to upload a gpg public key to a keyserver in order to publish packages in some public repositories, such as maven central, or one of several linux distribution repositories

- They needed it in order to send or receive email from an entity that required using PGP, but don't use it normally.

- They tried using PGP for email, found out how painful it was to use, then decided it wasn't worth the effort and stopped.

> If the allegation is true, it looks like Protonmail decided to munge e-mails without anyone opting into it.

As an active protonmail user, unfortunately they have a long history of this. My major gripe is that they manipulate emails that I've sent over the desktop bridge. If you sign your emails locally, this of course completely breaks the signature. And if you are sending emails to mailing lists, their internal email header fuckery has a history of eating things like reply-to headers that they can't find a local copy of in your mailbox.

I love their web interface and I am a big advocate of their other features but I am begging Protonmail to just give users the option to send their emails without interference through the desktop bridge.

I just want an opt-in IMAP and SMTP endpoint that actually works. I've debated moving to Fastmail so many times.

Unfortunately, we can't easily offer direct IMAP access, because no external email client offers support for everything we need and use in OpenPGP (such as for automatic forwarding, which is currently just a draft [1], but we hope will become an RFC in the future).

That's why Proton Bridge exists: to be able to decrypt all emails, including internally forwarded ones, and present them to the email client unencrypted - and vice versa when sending. Obviously this involves some muching of the emails, for better or worse.

[1] https://datatracker.ietf.org/doc/html/draft-wussler-openpgp-...

If the Bridge always has to exist, it would be great if Proton gave it more love. We don't have any WebDAV support right now, which means I can't see my calendars in GNOME Calendar or my contacts in GNOME Contacts. JMAP would be a great addition. Adding support for various IMAP RFCs would be great too. As it is right now, the IMAP is pretty much unusable in my email client of choice. I'm pretty much forced to use Thunderbird due to the RFCs that just aren't supported by the Bridge (gluon). Even going to the gluon repo, the last commit was 2 months ago :(. I don't understand how I as a power user who sends plain text emails is supposed to survive on Proton Mail. I can't use it for mailing list development, at all.

Fastmail just seems to be blowing Proton Mail out of the water in terms of IMAP/SMTP/JMAP. They are actively working on the protocols. Proton doesn't seem to be.

Link: https://github.com/ProtonMail/gluon/issues/378

What is your email client of choice? What specific IMAP features are missing from Proton Bridge that you need in order to use it?

> My major gripe is that they manipulate emails that I've sent over the desktop bridge. If you sign your emails locally, this of course completely breaks the signature.

Aha, another sufferer! There must be dozens of us, DOZENS I say!

Here's some background on what Proton Bridge does and why: https://news.ycombinator.com/item?id=36643124.

The recommended way to send signed emails is to let Bridge do it for you; you can enable this with a setting in Proton Mail called "Sign external messages".

Our goal is to make it easy to send and receive signed and encrypted emails. That's what Proton Mail is for. If you want to set up PGP signing and/or encryption yourself, a different service may be more suitable.

I understand Proton's motto is "Privacy by default". But, is it possible to have an alternative option to make Proton Bridge act as a standard IMAP and SMTP server? It could be turned off by default, and requires users to turn it on by themselves.

> For better or worse, the status quo is that there is no signaling mechanism in openpgp (or keys.openpgp.org) at the moment to specify how a key should be used, so publishing a key is just a yes or no situation.

Given that, why would it make sense for a service to assume that publishing a key signals that they should use it by default for a given communication channel?

> Given that, why would it make sense for a service to assume that publishing a key signals that they should use it by default for a given communication channel?

Why else would one publish a key and make it discoverable, if not that it be used?

I think the point is that it isn't an opt-in process as it should be. The default shouldn't be "if it exists use it".

And yet that’s how browers use TLS. If you enter an HTTP address, they switch it to HTTPS when available, without asking the user “do you want to encrypt your access to this website?” each time.

For example, so that they could sign documents with the private key and have people be able to validate them.

Another situation might be that, yes, the user wants encrypted mails, but are debugging their setup, part of which activity is uploading their key to openpgp.org. Until they get their stuff working, they don't want encrypted mails from the wild.

A related situation might be that something breaks in the setup of a user who receives encrypted mails. They'd like to pause them and get regular mails, without the hassle of deleting the key.

It’s used for more than just email. For example, you can sign packages on for Pacman on Arch Linux with GPG (https://wiki.archlinux.org/title/Pacman/Package_signing), and they have you configure public key servers, which includes openpgp. Now, if I had set that up for package signing and other personal uses (like SSH keys, git commit signing, etc), that doesn’t mean I have my email set up to be encrypted.

You should 100% be able to set a flag on the key server what you are set up to automatically receive using the key.

There is a key for encryption, signing, authentication and certification in OpenPGP. The flags are C, E, S, A. The use cases are separate.

Perhaps another flag for automatic vs non automatic would help.

Encryption is not just for encrypted emails.

In theory. In practice, published PGP encryption subkeys has only seen adoption in emails.

Besides, is the criticism that people are using published keys for email? It seems people are outraged that they received encrypted data using keys that they themselves advertised. The specific medium for data transfer doesn’t seem to matter here.

There are separate flags for communications (like email) and storage (like files).

https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....

Great, but while the encryption vs signing choice is presented by common software (albeit in a way that does not make this consequence clear), it completely does not present the encrypt for communication and encrypt for storage options.

There are multiple uses for keys.

I've published a key so that people can verify the signatures on some software releases. I don't expect anyone to try sending me an email encrypted with that key. And I really wouldn't expect such an email to work.

Yep, same. I find it funny that I'm apparently un-emailable by anyone on Proton. Good thing no one actually uses email for communication.

And that is why there is different types of subkeys, which you are told about when generating the keys, and every "getting started" guide I've found. If you don't want to receive encrypted emails, don't share a subkey for encrypting email?

What's the subtype that's for encrypting emails? Last I looked, there's a subtype for encryption, with no specificity for what medium.

Not for email specifically, but there is a flag for encrypted communications and another for signing.

https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....

I believe separate keys for encryption and signing is the default in most implementations.

Sure, but there are things for encryption other than email. Publishing an encryption key does not imply that emails sent to me should be encrypted to that key.

So people in situations with a specific need for extra security can use them. When publishing it, this meant anyone who 1) explicitly joined the PGP ecosystem and has some understanding of it and 2) explicitly enabled encryption for this specific email or recipient. Neither are the case with what Proton is doing.

Seriously Proton, just add a god damn prompt! And while you're at it, submit an RFC for a "please use by default" field in certs. Bonus points for a "this key is on a yubikey in a safe so if you use it you better have RCE in production to report" field as well or, hell, just a "key description" text field that clients can show the sender before using the key.

Our goal is to make email encryption more usable and less niche, and not only for "situations with a specific need for extra security" - because people shouldn't have to think about which of their emails are and aren't security- or privacy-sensitive.

Could you imagine if individual users had to opt-in to using TLS? Nobody would use it. The large push for using TLS everywhere has helped internet security a lot. Enabling the use of OpenPGP everywhere would also help much more than serving the use case of "this key is on a yubikey in a safe", because almost nobody is going to do that anyway.

Would you also make TLS opt-in for each website?

TLS is opt-in for each website. If a web server doesn't specifically listen with a TLS certificate, users don't connect with one.

Browsers will often attempt that connection, and then tell the user ~"Hey we tried to connect with HTTPS, but the server didn't respond. Do you want to try an unencrypted connection"

But there's no case where Chrome will look and see "oh look, akerl has published a cert on this other site, we're going to just send traffic encrypted to that cert when we connect to his website".

KOO is opt-in for each recipient. The recipient has to upload a key to KOO.

Obviously, OpenPGP works differently from TLS, and TLS does not have a concept of key servers - but key servers are absolutely not a new invention for OpenPGP, and it shouldn't be surprising that if you upload your key to one, you might get an encrypted email.

Usually by random action completely unrelated to emails they forgot about a few years ago.

I dunno, you'll have to ask Proton about that. Presumably they think it is what their users want, and they may or may not then be right about that. This feature has also been active for a few months only, so it might also change with further insight.

Indeed, our mission is to make it as convenient as possible to send and receive secure emails. Of course, this outcome (unexpectedly receiving blank emails) was not intended, and we'll see if we can improve the experience.

Rolling out end-to-end encryption in a federated system where it wasn't there before, is hard :) But we're trying to do so, anyway.

I'm just kind of wondering how this wasn't discovered or why it wasn't fixed in testing?

Well - note that OP uploaded a key to keys.openpgp.org, and then seemingly forgot about it and lost the private key (or at least they couldn't decrypt encrypted emails, and their email client - not Proton's - showed them as being blank). So it's not a scenario that we explicitly tested for, and not something we can unilaterally fix completely - although we can try to make it clearer for the recipient why the message was encrypted and with what key, of course.

> Well - note that OP uploaded a key to keys.openpgp.org, and then seemingly forgot about it and lost the private key (or at least they couldn't decrypt encrypted emails, and their email client - not Proton's - showed them as being blank). So it's not a scenario that we explicitly tested for, and not something we can unilaterally fix completely - although we can try to make it clearer for the recipient why the message was encrypted and with what key, of course.

OP claims to have no memory of having gone through the steps in the published draft standard. The steps involved are at least somewhat more rigorous than merely submitting a key and address to a database, so I'm leaning toward believing OP and questioning the database, especially since the project appears only to have been started in 2019 so completely forgetting having ever gone through such a process seems less plausible than questioning the database.

Further suspect may be the standard, itself (hence "draft"). Why it doesn't require a domain to publish a policy per address for the domain or at least publish that the domain approves usage of the policy seems a rather large oversight* given how it can break email, so this still leads me to be suspicious of Proton as draft standards should be considered "beta", and passively be explicit opt-in (no prompts - user must dig somewhere into the settings to enable).

* I've only briefly skimmed it, so maybe I missed the part covering this.

It's possible that some software did it on their behalf; I believe GPGTools submits keys to keys.openpgp.org, for example. (However, I don't know what the UI flow looks like, it's possible that it could be made clearer what.)

Also, the WKD draft has nothing to do with what's going on here. KOO is not the same thing as WKD, and is not in beta. It's a key server, and the concept of key servers has been around for ages. (WKD has been quite widely adopted as well, despite being only a draft, but that's an orthogonal discussion. It would definitely be better if it became an RFC.)

Somehow, I think either we are reading different articles or one of us has a severe reading comprehension problem. I reviewed what the author wrote and the links and read through the Proton document, and I can't figure out where I have a conceptual error, because the document states WKD, which means the published protocol must have been used or the protocol violated, which what you are describing would be out of spec from the protocol.

The author mentioned WKD but was mistaken. The culprit was keys.openpgp.org, not WKD.

>It outlines an enrollment process by which I would signal to a WKD service that I have a key that I want to enroll into the process. The only problem is I never did that, or at least certainly can't remember doing that. I'm certainly not hosting a page with any key verification stuff.

Now, at least one statement is incorrect. Can you verify your key in your sleep?

They never set up WKD, is what that paragraph is saying. But you'll find below in the post that they did verify their key on keys.openpgp.org, otherwise they wouldn't have been able to delete it via the mentioned management interface to test their hypothesis.

Is this page really the entirety of your privacy policy? https://keys.openpgp.org/about/privacy Because it's missing a ton of information, like who you actually are, how long you intend to keep the data, etc. I'm sorry to say, but this is really concerning.

We keep the data around for exactly as long as required to fulfill the purposes stated in the policy. If we kept it around longer, the policy would say so.

This is not a "cover your corporate ass" legalese privacy policy, it's intended to be clear and understandable. We also did check it with a lawyer specialized on privacy.

Of course if you don't like it, you're free to not use our community service :)

Just to check, are you looking at a translated (non-English) version of the page? It seems like those are outdated, unfortunately. The English version does specify a log retention period of 30 days. (The version you're served depends depends on the Accept-Language setting in your browser.)

Yes, I'm looking at a translated version. I didn't see any link to the English version, nor any indication that the version I looked at was obsolete. I guess non English speakers can just go f themselves.

Log retention is only part of the equation. How long does the project keep the email addresses?

Email addresses are typically stored in the User ID in OpenPGP keys, so as long as the OpenPGP key is on keys.openpgp.org, the email address will be there as well. They can be deleted by the owner whenever, of course.

Well - where are you looking at the translated version? Because the version at the link you provided is in english.

Read the GP comment...

A lot of the bases are covered. It would need a bit more to be fully compliant. The trade-off between simplicity and comprehensiveness is hotly debated in privacy circles.

Reply on news.ycombinator.com