Why can't my mom email me? | Hacker News Reader

Why can't my mom email me?

matduggan.com

279 pointsFiloSottile295 comments

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.

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

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

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.

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

If I didn’t want people to encrypt mail to my pgp key I would simply not upload it to a public pgp key directory.

Honestly, what is the complaint here? If you don’t want people to use certain contact info don’t put it on the open internet.

To get your key in that key server not only do you have to submit it you have to verify it via email. It’s literally… to spread it widely… to anyone who wants it… so they can send you encrypted mail. That’s the entire purpose of the thing.

Like if i put my phone number on a billboard I have no right to complain when I get calls.

Take responsibility for your actions.

“ However long we postpone it, we eventually lie down alone in that notoriously un- comfortable bed, the one we make ourselves. Whether or not we sleep in it depends, of course, on whether or not we respect ourselves.” Joan Didion https://www.vogue.com/article/joan-didion-self-respect-essay...

More charitable is that the user thought it would do X and it ended up doing Y. They may have even been happy with X even, if they knew that was going to happen, because the whole thing would have been less confusing.

> I'm at a little bit of a loss here. I totally understand sending me encrypted emails if I've gone through the steps to set the CNAME that indicates that I want to do that, but it doesn't seem like that's how the service works. As far as I can tell, the act of uploading a OpenPGP-compatible key seems to trigger their service to send it as an end-to-end encrypted message.

A similar example is how Windows changed their OS to require a PIN, which can be a password if you figure how to. It then asks you for this when doing completely unrelated to your OS online stuff sometimes, like some of the weird flows to do with using Teams or whatever, and I am not expecting it was asking me for my PC pin because it before that just asked me for my Online username. It is a UX issue.

I don't know... I thought encrypted emails were cool in like 2002, so I probably have a key on a keyserver. I probably lost the ability to revoke that key, and simply stopped caring after not receiving a single encrypted email in 25 years. So I would be very surprised if someone sent me an encrypted email today.

(I actually do know where my key material is. It's on a smartcard that nothing that exists today can read. Back in the day laptops had smartcard ports! Crazy.)

The one feature of an HP Elitebook that could perhaps be called ”Elite” is that they come with smart card readers built in. USB-readers also exist.

Not all of them. Some models don't support them at all, others only have it as an option. My EB845G8 has the slot, but there's no reader inside.

I also don't have access to that private key anymore anyway, but I'm still using the same email address.

What is indeed missing is a limited validity period of the key, as a certificate would provide. Then everybody would be clear on how long the key can be used.

OpenPGP Keys do have expiration dates/validity periods: https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....

The good thing about GDPR is that these keyservers must delete your info after some time unless you periodically renew your consent.

Good thing every company and web server on the planet is in the EU! How else would 10 people make lazy GDPR posts on everything vaguely related?

Even if the web servers are not in EU they must use GDPR if they target EU users.

Good look enforcing GDPR in Panama…

if a tree falls in the woods without any geo-ip blocking, does it have to comply with GDPR?

Where in the GDPR do you find this 'some time'?

AFAIK, and I might be wrong here, you do have the right to be forgotten - art 17. But there is no need to periodically renew consent. As long as the period for consent is understood and is relatable for the reason of the consent, it can be basically for ever. In this case, that period seems to be 'until he withdraws his consent' and that seems fine by my reading of the GDPR.

https://gdpr-info.eu/art-17-gdpr/

https://commission.europa.eu/law/law-topic/data-protection/r...

> Your company/organisation should establish time limits to erase or review the data stored.

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...

> In order to ensure that the personal data are not kept longer than necessary, time limits should be established by the controller for erasure or for a periodic review.

Have you not gotten, over the past few years, emails from services you no longer use and probably forgot that you ever setup an account for, informing you that they will delete your account if you don't use it soon? It's because of the GDPR.

"Not longer than necessary" can still mean "permanently" if it's information that remains relevant permanently. And I think that's the case here.

In the same way that any blockchain based system must delete your info after some time...

Hey, smartcards are still a thing ! My company still uses them. I have a 2022 Lenovo laptop whith a smartcard port.

the government still uses them

USB smartcard readers supporting the CCID protocol are cheaply available these days and are natively supported on all major OSes!

I do miss built-in smartcard readers though; carrying a USB reader is just not the same and I usually don't have mine with me when I need it.

That said, I also wish browsers would support the ISO 7816 transport of CTAP2 for WebAuthN using these readers. That would allow me to use a card form factor WebAuthN authenticator not only on my phone (both iOS and Android support CTAP2 over contactless), but also on my computer.

Because PGP keys are used for more than just encrypting email.

I mostly only use mine to sign release tags for software I publish. Having that key uploaded to a public keyserver is a useful thing to do in that case.

But maybe I wanted to use it for other things... perhaps I just want to sign my email, and not encrypt what I send, and allow others to verify the signature. Having the key out on a public keyserver is essential for that.

Honestly I don't know why acting so rudely about this, to the point of pretentiously quoting a famous author/journalist. Not to mention the fact that you haven't thought through all the various reasons why someone might have a key published. Maybe step back from the keyboard and breathe a bit?

Exactly. My key is on there because we have a shared password-store synched in a private git repo encrypted with the keys of select number of colleagues for some work credentials and keys. It is useful to be able to find each other's keys automatically based on the key fingerprint.

I can probably read e-mail encrypted with it just fine as long as I use Thunderbird with my Fastmail inbox (which is most of the time), but not when using K9 Mail on a smartphone or the web UI of Fastmail.

That's not what public keyservers are for. You're free to use it any other way, but it's unreasonable to shame people who used the keys you advertised in a way that matches general expectations.

Besides, it doesn't make sense to upload keys only meant to be shared among a small number of people to a public keyserver. In your case, the keys better belong in the git repo.

I feel like that defeats the purpose of the validation. If you're storing the keys in the same place as the code, it would be very easy if someone gained malicious access to the repo to change the key and sign it with the new key.

I thought the commenter was using the repo for a password store, not executable code? The only consequence of not validating that would be them entering invalid credentials. Even if they’re dealing with code, watching out for new commits that change keys is enough. That’s something that people should be doing when using keyservers too.

Anyway, the point is public keyservers aren’t a good match for the described use case. If the key is meant to be kept private, it should be shared privately.

Signing keys and encryption keys are separate things in PGP. If you don't want people to use your encryption key, don't encourage everyone to use it by uploading it to a keyserver.

> Honestly I don't know why acting so rudely about this, to the point of pretentiously quoting a famous author/journalist. Not to mention the fact that you haven't thought through all the various reasons why someone might have a key published. Maybe step back from the keyboard and breathe a bit?

Yes please, practice what you preach.

> Signing keys and encryption keys are separate things in PGP. If you don't want people to use your encryption key, don't encourage everyone to use it by uploading it to a keyserver.

I think most people don't know that, and/or don't know how to separate the two. At any rate, it's not particularly convenient. Most people will just generate one set of keys to use, regardless of the intended purpose(s).

Regardless, let's again realize that PGP keys can be used for more than just encrypting email. Maybe I'm using it to encrypt, but not for email.

> Yes please, practice what you preach.

Not sure what you mean. Attempting to equate the tone and words of my comment with that of the toplevel commenter seems a bit in bad faith.

No, my comment was made in good faith.

So, the point about rudeness. PGP keyservers exist for the sole purpose of letting you advertise your keys. Shaming people who used keyservers for what they were designed for is what's rude here. Actually, more than rude. It's a trap.

Next, about actually thinking about all the reasons for uploading keys to a keyserver. Can you actually name a use case that you consider legitimate for discovering encryption keys through a public keyserver? Because your point seems to be that people upload them unwillingly.

You shouldn't be quick to accuse people of rudeness and bad faith in those with different perspectives.

Also,

> I think most people don't know that, and/or don't know how to separate the two.

I'm sure people will understand what "sign only" means when GPG prompts the user to choose what kind of keys to create.

If it prompts them (i.e. if they use --full-gen-key) . --quick-gen-key and --gen-key just assume the user wants both

GPG guides tend to use --full-gen-key, maybe because they're picky about key algorithms and key sizes.

So here's how Arch Linux package signing works:

1. You define a PGP key signature in the package metadata.

2. If you are a part of the Arch Linux project, the key will get installed in user's system as part of the archlinux-keyring package.

3. At package installation time, if your key is not already present, it will look it up on a keyserver. It will then prompt the user if they want to trust this key.

4. If it can't look up the key, it will reject package installation.

I see downthread that Debian works similarly, and also I've seen some people rely on this for publishing signed artifacts on github releases also.

I'm aware how package signing works. What does any of that have to do with my comment?

Step 3 is a reason people publish their keys to keyservers.

Step 3 is reason for people to publish signing keys, not encryption keys. That was the whole point of my original comment.

Let's follow a tutorial for GPG (I'll take the Arch one since I've already discussed, but many are similar): https://wiki.archlinux.org/title/GnuPG#Usage

So here's an interface for key creation in gpg

    $ gpg --full-gen-key
    gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    Please select what kind of key you want:
        (1) RSA and RSA
        (2) DSA and Elgamal
        (3) DSA (sign only)
        (4) RSA (sign only)
        (9) ECC (sign and encrypt) *default*
        (10) ECC (sign only)
        (14) Existing key from card

There's also --quick-gen-key which doesn't show this info.

Now put yourself in the boots of a new user: Why would you pick to have a key with less features? Maybe the user thinks they may want to encrypt something in the future. Not to mention, many people did this process years ago, and forgot what they picked.

Then you publish that key with gpg send-keys or the keys.openpgp.org web interface, possibly at a later date, then you just pick the one key ID that you have.

And now you have a key published for signing and encryption, with no intention to use GPG email.

That's irrelevant. The act of publishing has a well-established meaning. Publishing an encryption key, only to shame others who have used your key to send you encrypted data is unreasonable. How is that different from publishing a book and shaming your readers for reading it? "Oh I didn't know that by publishing a book, I was encouraging others to read it!" isn't a good response.

Also, any user of a tool should at least check what the primary purposes of that tool are.

Neither the sender nor the recipient made an active decision that the respective mail should be encrypted with pgp. That’s the issue here.

They uploaded PGP key to open directory and then verified email, what is this as not an active decision?

It's an active decision to make their key available to people who wish to send them encrypted email. It's not a decision to receive all email in encrypted form.

Im not sure that I see logic here..

> It's not a decision to receive all email in encrypted form.

Except, it is. You can’t control of everyone out only some will send you encrypted email.

I mean, sure, if somebody wants to take a guess on whether I have my private key with me (or even still have access to it at all), that's on them.

But if an email provider purportedly bringing email encryption to the non-GPG-trained masses does, it's a different story.

Using Proton for email means it is. Why use Proton otherwise?

Uploading a key does not imply any decision regarding email. I may need it to sign tarballs or commits for example, and the key could very well have been lost to time.

The presence of a key on a key server is in no way or form an explicit opt-in to encrypted email. That's what the CNAME is for.

Exactly. The only way this makes sense is if Google provided a way to import your PGP key into Gmail, which it doesn’t.

Except you explicitly uploaded an encryption key, not a signing key! This action broadcasts to the world the message "you can encrypt communications to this identifier using this key"!

This is seriously like telling somebody that you can be contacted on a particular phone number and then getting upset that you're getting phone calls. "Who uses the phone these days," you complain, despite having set into motion the sequence of events that led to you getting a phone call! Worse, in this analogy, it's not like you even said "only text this number"; you explicitly applied metadata saying that you would be open to a phone call.

In your analogy, the keyserver is a phone book. You can find keys there, and yes you can try to use them, but it's not like telling someone you can be contacted on a particular phone number, but rather like them digging through a phone book and finding your name in there, possibly for an unused landline that you technically own but isn't wired up - who knows.

Telling you to use a particular phone number - say through a business card, a contact page or a profile - is the analogy matching configuration of your domain to publish your intent, similar to how your domain also specify where you mail server is.

That's a good thing? There's like a billion WhatsApp users encrypting all of their messages without realising it because it just works.

GPG will never be that simple to use. Personally, I hate GPG with such passion, but I'm fully aware it's the best thing we have for asynchronous messaging.

Least you can do is document somewhere that you are doing it, and not silently do it. WhatsApp doesn’t keep it a secret, exactly.

I've never tried Proton myself, but I don't understand how you can consider it to be a "secret". It's literally the only thing I know about them: they've established themselves as a "more secure" email provider, and they back that up by abstracting some of the pain points of using GPG, which is a completely unusable protocol for normal people.

If it was some other email provider that did the same, I'd 100% agree. But with Protonmail, GPG is pretty much the entire reason we're all aware of their existence.

What they do for Proton-to-Proton messages is their business, since they own all the fallout from people losing their keys to that, but to just blindly encrypt to a key somebody might or might not still own the private decryption key for is just reckless.

I just tested it myself, and while there is a visual indicator of that automatic key lookup happening, there's zero way to disable it, nor to even verify which key it picked or to display the key hash.

It seems like a terrible solution halfway between convenience/opportunistic encryption and actual security, combining the downsides of either (a high risk of sending messages the recipient won't be able to decrypt and a moderate risk of encrypting to a key other than the expected one).

Yeah, we'll work to improve the documentation on this.

Though.. note that WhatsApp doesn't have any documentation on their key discovery either, because WhatsApp is not a federated system. Achieving automatic end-to-end encryption in a federated system, when it wasn't there before, isn't so easy. So there's bound to be some growing pains, but we're still trying :)

Are you with Proton? Maybe the documentation you need is just a lock on the sent email that says "Used key for <email> from keys.openpgp.org", and the recipient could also have a cleartext message saying "Encrypted with key for <email> from keys.openpgp.org"?

I haven't read as many blog posts where people get encrypted WhatsApp messages and can't decrypt them.

oddly, it's because whatsapp has a well integrated keyserver so there's never an issue of not knowing which key to use. Weird.

It's not weird. It's the point of the original complain.

Part of the difficulty is that email is a federated system, unlike WhatsApp. Adding end-to-end encryption to a federated system, if it wasn't there before, is a lot more difficult than adding it to an ecosystem that you control in its entirety.

I understand and agree with this. That's why you cannot single-handedly add a feature like Protonmail's, without risking of breaking someone's workflow. I probably have myself some GPG key uploaded on some public server, tied to i-dont-even-remember-which email address of mine, and when I did that I surely didn't expect or imagined that some provider would pull it automatically to encrypt every mail in which I'm the recipient sent by their systems.

I understand Protonmail's approach but I also understand - and share - OP point of view.

That's the thing though, you almost certainly at the time expected people to use it, and then a decade passed and nobody showed up. The problem isn't that you did it, the problem isn't that they used the information, it's that you were an early adopter who forgot the passphrase to your bitcoins. You put that key there because you wanted it used, you don't get to pretend that you've stopped wanting to use it and everyone should totally know that because you haven't used it.

You have a sign out saying encrypted email here, and are mad someone finally read it.

Remove the sign, or change it to foo+secrets@mydomain.com

Op is mad he left the sign out saying come in and play when people came in to play way after his party ended.

Right. And PGP doesn't "just work". So it's foolish to blindly assume someone can receive encrypted mail just because you found a key that seems to match on some public keyserver.

Even if I published a public key, I wouldn't keep the private key on every device, and if I have to dig out my yubikey just to find out you're in town for lunch next Tuesday, we're probably not having lunch.

Yes, this is true.

I never felt comfortable having my private key on my phone, so I can't read encrypted email on the go.

I get one or two encrypted emails on a good year, and they are rarely important (or require encryption really).

> I get one or two encrypted emails on a good year, and they are rarely important (or require encryption really).

Well if only "important" things are encrypted, then the existence of an encrypted message is evidence to whomever you may be trying to hide from that something "important" is going on. Ideally everything would be encrypted, important or not; having all current encrypted things being unimportant is actually better than having only important things encrypted. :-)

My point was that those emails can wait until I'm on my desktop and I can decrypt them.

I should have used "urgency" instead.

I also have a fear of having my private key on my phone, but it's a nebulous kind of paranoid fear. I don't know if there's actually any good reason to have this paranoia or what the best practice is. I suppose having the same key in fewer places inherently increases security, but there has to be a line somewhere... Not accessing email on my phone would be a giant productivity killer.

Actually it seems like a feature to me (to be able to exchange encrypted emails so easily between different providers), and a quite nice one actually.

> If I didn’t want people to encrypt mail to my pgp key I would simply not upload it to a public pgp key directory.

I have keys uploaded to PGP directories that I have in the past used for Git commits, and use today for linux package signing.

I've never used encrypted email, so it would be surprising for people to try use it to send email.

My understanding from the article is that correspondents are not encrypting the mail, but that Protonmail is. So unencrypted messages from Fastmail are being encrypted to a key that Protonmail found on a random keyserver when that email hits the Protonmail server.

This is a common feature provided by privacy oriented email providers. The idea is that the provider will only have access to the unencrypted email at entry to the server but not after that. The email of course can't be signed in any meaningful way, but the original unencrypted message wasn't signed either. This strikes me as the sort of thing that you would want the user to specify a particular key for, but I suppose Protonmail is attempting to increase usability by making it as automatic as possible.

The Fastmail article linked my Mr Duggan [0] is also worth a read, they provide a sober and reasonable overview of why they don't offer PGP. Of course, Australia has a quietly privacy-phobic regulatory regime so we can guarantee [1] that Five Eyes countries and possibly others are reading emails sent through Fastmail. Cost of doing business really, I use Fastmail.

Fact is that there isn't a way to use a convenient 3rd party email provider if you want secure emails. Only local clients can provide that feature - which means both sides of the message have to be using trusted local clients, and at some point one side of the conversation will forget their secret and lose access to their email history. It is a tough problem.

[0] https://www.fastmail.com/blog/why-we-dont-offer-pgp/

[1] https://www.bbc.com/news/world-australia-46463029

I also use Fastmail and I am a happy customer. My eyes are open. I make no assumption that my mail is private. I think the email analogy is actually very accurate. It’s as secure as postal mail. Maybe slightly more secure than a post card.

I’m happy to be supporting a slightly smaller provider. I don’t have to admin anything and I still feel like I’m contributing to an open ecosystem. Plus I own my domain so I can always change providers.

I have made peace with the compromise.

I'm in essentially the same place. I do wish their marketing pages didn't make such strong claims of privacy - it's an impossible promise. https://www.fastmail.com/fast-private-email/

“We’re more private than Gmail” doesn’t have the same ring even if it’s true.

That's honestly kinda table stakes for anyone attempting to spin up a new email provider. Being slightly better than the incumbent doesn't make it attractive enough to switch for most people.

Well, it's a lot easier to automatically scan and store emails than postcards (eg, flagging all emails with certain keywords or in certain languages)... I guess nowadays they can use OCR to scan postcards, but that would be of doubtful value to any of the 3 letter agencies.

The USPS literally scans and stores all mail sent through the USPS.

And it's a feature, their Informed Delivery service will send those scans to you in an email.

All they get are equivalent to email headers. They don't know what's in the box or envelope unless you've had to declare it with them for some reason.

I've been running several small email systems for roughly 25 years in the UK.

I generally don't have issues with the big boys and girls. Yes, they send me shit loads of spam and I drop it on the floor. I generally only go as far as SPF and getting A and PTR to match HELO and don't send any spam. I use Exim and rspamd and a few other things.

Google and MS email fettlers are not complete wankers and they seem to be quite reasonable.

I could quite easily add your Mom's mail domain to my non work post office and probably deliver her mail. I already do it for several others. However, sadly, I don't know you, nor you know me, so a trust relationship is out of the question.

Just in case anyone is going to get whizzed up about US vs UK: my company email domain is within .net, which is nominally US based. When we incorporated and eventually sorted out a name, it turned out that the .co.uk domain was "taken", hence why we went for second best.

This article confuses me. What would it even mean for Fastmail to offer PGP? The whole point of PGP is that you don't (need) to trust the people who transmit the message. Relying on them to do the encryption for you defeats the entire purpose.

Some may only want encryption between their key custodian and the recipient or their custodian. Email without encryption cannot guarantee it won't be snooped on by any of the other parties involved in transporting it. In practice big providers may be able to ensure that, but email is federated so it's impractical to do that with every provider unless there's a standard.

The point that Fastmail made in the article, though, is that if Fastmail is handling the encryption, then they know your key. So Fastmail cannot protect you against Fastmail's servers being compromised[0].

And the article linked from their article (hilarious itself) pointed out that this basically comes down to State Actors (Mossad as the example) or Everyone Else. If it's Mossad then there's nothing anyone else can do to protect you (because they can do secret-squirrel things through special security courts and stuff like installing black boxes on undersea cable routers). If Everyone Else, then the normal run-of-the-mill transport encryption is probably good enough, just don't click on any herbal boner-pill adverts.

tldr; If you want to be protected, you have to do PGP at the local machine level yourself.

[0] Given that Fastmail are Aussies, and that our idiotic government have given the spooks full, secret, access to anything they want, then this is a very real prospect for anyone that five-eyes might be interested in.

>this basically comes down to State Actors ... or Everyone Else

This is oversimplification if not misleading. There are also Bad Guys (who aren't state actors), who usually can't reach for your data. But occasionally they can, when rare Planet Parades like Heartbleed or Meltdown make the news. And they are happy to use this one-in-a-lifetime chance to sell access to your data to everyone else.

I guess I don't understand how something like Heartbleed can hit you if you don't click on boner-pill ads, Fastmail's servers don't get hit, and you're not installing random apps from random internet folks?

> won't be snooped on by any of the other parties involved in transporting it.

There was a time, long, long ago, when mail from your email provider to your recipient's provider would often go through other providers in transit. Nowadays (and for the last 20 years) all of the intermediary mail-servers in the Received: headers belong to either the sender's provider or the recipient's provider. They're usually spam-filters, application gateways, secondary servers.

I guess the major exception is people who use gmail or Mailchimp as an outbound relay. But that's deliberate, and entirely under the sender's control.

However, the wide use of MTA-STS is quite recent so downgrade attacks have been possible. In fact, Fastmail seems to currently be messing up MTA-STS, I'm not sure if they are intending to enable it or not.

https://www.mailhardener.com/kb/mta-sts

As I read it, that's their point. They're responding to people who are asking them "why don't you do PGP?" (like Proton does), and their answer is a pretty well-reasoned "because that doesn't make much sense - it doesn't mitigate against any actual threats".

Which kinda begs the question about what Proton thinks they're doing by implementing PGP on behalf of their users...?

We implement OpenPGP client-side, on the user's devices. Their central complaint of

> If it’s running in the browser with code downloaded from our servers, then if we get compromised, we can serve up a version of the PGP code which leaks keys or plaintext.

is well-known but only applicable to the web app, the other clients are less susceptible to this. Even for the web app, we are proposing to solve this problem: https://github.com/twiss/source-code-transparency

thanks for the clarification. I'm a happy Fastmail user, but I appreciate that other people have different ideas

> Of course, Australia has a quietly privacy-phobic regulatory regime so we can guarantee [1] that Five Eyes countries and possibly others are reading emails sent through Fastmail.

That’s a wildly unfair characterisation, and not in the slightest bit supported by your citation. The Assistance and Access Act which that article is talking about (though it doesn’t even name it!), although a dodgy piece of legislation in the opinion of most technologists, is completely irrelevant to Fastmail, because Fastmail doesn’t offer end-to-end encryption. Fastmail was always subject to the Telecommunications Act, which allows Australian police access with warrants, and Fastmail has always made no bones about the fact that it complies with legal warrants. But that’s nothing like what you’re describing.

(Disclosure: I was a Fastmail employee from 2017–2020.)

Email encryption _is_ end-to-end encryption. You just explained why the law doesn't apply to what they did, and the parent explained why they didn't do it because of the law. These two are not in conflict.

I’m not sure what you’re saying. The sentence I quoted is written in the present tense, saying that Fastmail is compromised, not as a hypothetical “if they did PGP, it’d be broken for this reason”.

These are their objections:

1. Search isn’t possible

- It's possible on the client. The total text in an email account is not prohibitively large and can be cached on the client.

2. Previews can’t be calculated

- It can be on the client, then reuploaded encrypted.

3. If you lose your private key, we can’t recover your email

- Of course, this is equivalent to losing your email account password.

4. Spam checking on content isn’t possible

- It is on the client, and on the server based on headers.

5. To access mail on multiple devices, the private key needs to be shared securely between them

- Protonmail solved this, what's the problem?

> It is on the client, and on the server based on headers.

The idea of spam filters is that you don’t get the spam so the client never sees it.

Also running highly specialized spam filters that actually work reliably might be prohibitive for a lot of people.

ProtonMail solved this using email aliases so you never have to give out your real address. If you get spam on one you just redirect it to your spam folder.

Technically all email providers support PGP assuming they support IMAPs. The mobile client is adding it soon if they have not already. I've been using it with Fastmail for some time. Thunderbird makes PGP very easy and happy-clicky. [1] I also just give people my public key out of band and avoid the key servers. Thunderbird also has it's own built in search.

I think most peoples non technical relatives could follow the pictured steps easily but if for some reason they can not then a desktop sharing session should get around helping someones mom set it up. I've had no issue with my non technical friends.

I should add that if Fastmail added PGP in their interface I would not use it. Nobody could convince me that when a mail provider or anyone else adds E2EE in their application that it's anything other than PP Pinky Promise. They can tamper with it to intercept my communications and no app provider could possibly convince me otherwise. There should probably be an RFC for PP.

[1] - https://support.startmail.com/hc/en-us/articles/360014775437...

Related research:

* Why Johnny can't encrypt (1995): https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Ca...

* Why Johnny still can't encrypt (2006): https://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abst...

* Why Johnny still, still can't encrypt (2016): https://arxiv.org/pdf/1510.08555.pdf

At this point I really wonder if e-mail is the best solution for encrypted asynchronous communication. E2E systems like Signal or Whatsapp offer a very functional, intuitive way to protect your texts.

The only issue with WhatsApp (I have no idea about Signal) is that, while it offers seamless encryption, it doesn't allow you to use an alternative client. Therefore, all trust has to be placed in the client and its distribution to ensure it doesn't mess up (intentionally or not). For the average Joe however I totally agree with you and it's a good baseline.

Security folks, especially on HN, are very actively hostile to alternative implementations and clients because in their mind it breaks security. Just see any Apple or Signal topic.

The walled garden lockin in by design for you to be safe.

That's only if Signal and Whatsapp actually took any good lessons from WJCE. Both handle the difficult identity issue with the comparison of huge numbers just like with PGP. Usability studies have shown that this has worked out about as well as one might expect[1]. Worse, both cheerfully allow the use of unauthenticated correspondents without any particular warning to the user. WHCE identified the root issue as a failure to create and impart the required concepts to use the system. Signal/Whatsapp completely fail at this, instead the user is provide with a sense of security that is not warranted.

The PGP using community as least recognised that there was a problem. When has anyone ever organized a Signal/Whatsapp key comparison party?

[1] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...

Matrix.org is promising, in a "might start getting real traction in 10+ years" kind of way.

Stuff like https://techcrunch.com/2024/04/09/wordpress-com-owner-automa... implies that some folks are betting on Matrix having more traction sooner ;)

In summary (quoting OP): "the act of uploading a OpenPGP-compatible key seems to trigger Protonmail service to send end-to-end encrypted message"

I personally think S/MIME is better than PGP. The "key exchange problem" is solved more pragmatically and user-friendly (send an unencrypted but signed email once, your/their client will automatically remember keys for encryption afterwards). And most pre-installed email clients support S/MIME natively (e.g. Apple Mail, Outlook, even the web email apps).

The only annoyance is that it's too difficult to acquire a certificate as an individual, but e.g. Actalis [1] will issue one for free.

[1] https://www.actalis.com/s-mime-certificates.aspx

Apple Mail's implementation was broken for years, it silently failed to encrypt messages (CVE-2023-40440). It also still can't properly sign letters with attachments.

None of these implementations also handle RSA-PSS signatures and the standards basically forbid double-signing that would allow gradual migration to better algorithms. (This issue also exists with PGP/GPG)

Actalis is nice for testing but they unfortunately generate your private key for you instead of accepting your CSR. (Protonmail has the same issue with PGP.)

But it is better in a bunch of other aspects, including tooling, yes.

I have a web form on my website which is used mainly by spammers and my Dad. So when he can't seem to email me, there is always a backup that works. Parents demand highly redundant systems of their techno offspring.

keys.openpgp.org seems to claim that keys aren't searchable by email until the email is verified. Did you ever verify the email with them? If not something is going wrong. Maybe there is a problem in the service or maybe Proton Mail is working off of a dump and ignoring the "is verified" bit.

https://keys.openpgp.org/about/usage#gnupg-upload

Even publishing a key as “searchable by email” should absolutely not be taken as an invitation by any client to encrypt by default, given the somewhat lacking ergonomics of GnuPG.

I have a key published, but if somebody emails me encrypting to it, it would take me days to figure out where my smart card storing the private key is, how to use it on my current OS etc.

I'd probably be more sunk. When I was first learning and playing around with PGP, I published a key. Later, I changed the key for some reason or other but no longer had a way to revoke the old one. I'm pretty any of them out there are expired by now but for a few years it absolutely was possible to send me unreadable mail.

I think they are only using the “email address verified keys” that these “new-style key servers” use, so you’d be able to at least revoke that binding as long as you can receive unencrypted emails to that address.

keys.openpgp.org operator here. It's definitely not a bug, we do not publish email addresses without verification. From our perspective, op verified their email and made the key discoverable.

So that implies that either the OP has forgotten that they did this (because they are quite clear that they did not), or that there is a way to do this without being the owner of the email address.

Both worrying, but one is a lot more worrying than the other.

I don't think they are clear they did not? In fact, they are clear that they did publish their key, because they mention depublishing it to test their hypothesis.

The part they say they didn't opt into was that Proton (or any specific email client) would use the key by default.

Indeed, you are correct, and I was wrong.

On a related topic, I wish someone would implement "user-encrypted-at-rest" to protect me from the provider getting breached.

I don't care so much for the transit, but I'm a bit worried about the fact that I have many years of emails stored in "plaintext" (citation makes because they probably use FDE and maybe other encryptions but they can still read everything) on the providers server.

I'm not worried about a malicious provider, but worries they might at some point make a mistake which allows them to be hacked.

If anyone knows any solutions for this that works in iOS/Mac I'd love to hear.

The only thing I've found on this is some research a few years ago with ideas how to do this; but I haven't seen any implementations of it. I've linked to it here: https://www.cs.columbia.edu/~koh/papers/koh-eurosys19-e3_eas...

Proton does this.

That's actually the Protonmail feature that is causing the problem.

Not really, grandparent is asking about what we call "zero access encryption" [1]: encryption at rest of received and sent emails, without the provider having access to the keys (unlike typical "encryption at rest", which doesn't give you much).

Instead, OP is talking about outgoing end-to-end encryption using public keys from keys.openpgp.org.

[1]: https://proton.me/blog/zero-access-encryption

Download all the emails from the server.

Create a backup dump file from your email client. Encrypt that with any program you like. Upload to eg Google drive.

Verify the backup and then delete all the server-side copies of your emails.

I actually like this behavior ... If you have a key, use it!

The OP doesn't recall generating one. Genuine question: do you also like it when someone else generates a key for you without telling you? Personally I would rather know about it.

The OP did generate one and placed it in a public registry. What they didn't do was indicate that this key should be used to encrypt email sent to them to them.

They published it with an precise link to their email address - what were people supposed to conclude from them publishing it - "never use this pgp key unless you've spoken to me in person?" - that... kinda defeats the whole point of publishing a key _and_ the handle by which it's looked up in the same database. If you didn't want that, you'd associate it with something else that wouldn't expect encrypted email - like a name or a GUID and point people there when they need it.

They wrote in the book "me@foo.com: use key" - and then people did. If he wanted different behaviour, he could have published "someoneelse@foo.com" and then they wouldn't use it to email _him_.

In the current world an "email address" is not solely (or sometimes even primarily) for delivering email, but rather an identity or username for various systems, such as for signing git commits. So a key linked to an identity (email address) does not imply in any way that this key is also used or usable for encrypted communication.

> "never use this pgp key unless you've spoken to me in person?"

Well, yes, actually, that is what I would expect. (Well, not necessarily in person, but via a different communication channel, even by unencrypted email.)

I remember when I was first playing around with PGP more than 20 years ago. The usual convention was to talk to the other party first about encrypting your messages, and not to assume that the recipient could receive and decrypt them in all circumstances.

The original PGP idea was a "web of trust", which meant doing key signing parties and you hopefully ending up with a transitive chain of trust to anybody you might want to contact.

Just blindly downloading keys from a keyserver and hoping they're the real thing was not the idea.

Right, but other than the bug, the feature does seem nice. I do use WKD, and although nobody has ever sent me PGP email, it's nice to know that ProtonMail users would find it convenient to do so.

It’s an absolute no-go.

I do have an OpenPGP key published to the key servers, mostly for toying around with GnuPG cards, but as soon as anyone starts emailing me encrypted messages without any context, I’ll delete it.

I don't understand.

It's not a security risk to read an encrypted message. Why would you delete an encrypted message?

Delete the key off the server, I think, not the message.

Yep, that’s what I meant!

Still strange, but I know what they mean now.

Absolutely not without a flag on the key that indicates “encrypt email to this key by default”, or at least the domain admin having explicitly pointed WKD to the public key servers.

This is such a bizarre take to me. If you don't want people using your key to encrypt email to you, why are you uploading your key to a service designed to help people find it to encrypt email to you?

To play around with it?

> to encrypt email to you

this part is incorrect: keys have other uses. It's not because you sign Debian packages that you encrypt your emails. With the same key. Hence the need to have a way to say "this key is for encrypting emails with such method and such protocol".

Then only upload a signing key. Don't upload encryption keys. PGP is capable of making that distinction.

Yes, but how many other things can you think of other than email which you would share your encryption public keys for? Honestly email would be at the bottom of applications I would think of, even when registering keys with a key server.

If you have a bunch for different use cases (or like, levels of security/secrecy/revoking-this-will-be-a-nightmare), which you've set your one email address as recipient for, which of those is "default"?

The keyserver and protonmail also are entirely separate. I wouldn't expect the two entities to be communicating with each other if I hadn't opted in. It feels weird, like when private companies harvest your data without asking.

> Yes, but how many other things can you think of other than email which you would share your encryption public keys for?

The only non-theoretical use of a PGP encryption key is email.

> (different) levels of security/secrecy/revoking-this-will-be-a-nightmare

Using multiple keys don't offer added security or secrecy.

Also, keys.openpgp.org lets you delete keys as long as you have access to your email.

> It feels weird, like when private companies harvest your data without asking

This is nothing like data harvesting, which may be why you prefixed your statement with "it feels like." Nobody is obtaining private or even semi-private data that can be used against you.

Also,

> private companies

keys.openpgp.org is a open source community project. It's not an evil for-profit data-hoarding entity that's implied by those two words.

I'm curious, what do you think a PGP keyserver is for? You make it sound as if there are no legitimate use for downloading encryption keys from it. Which leads to another question, why upload the keys at all?

> The only non-theoretical use of a PGP encryption key is email.

I use a backup application that encrypts my backups using PGP.

Granted, that certainly doesn't require a published public key. But your assertion is incorrect.

Right, I should've phrased it as PGP encryption keys obtained from a public keyserver.

Backing up keys stored on a GnuPG card (e.g. on a Yubikey) does require that.

It doesn't require that. You have the option of doing so.

You can back up public keys and restore them just like any other file. I don't see why a public key file should require special treatment from any other file requiring backup.

And I don't see why publishing a public key file to a key server should trigger any special semantics regarding email encryption without an explicit "I currently have this key accessible, go ahead and encrypt email to me using it" flag.

Because that's what a public keyserver is for. It's not a private file syncing service. You can use it as one, but don't get mad at others when they use public keyservers as intended.

> Because that's what a public keyserver is for.

Who defined that?

> It's not a private file syncing service.

No, it's a public file syncing service :)

Well, ask the creator of PGP:

> Whatever it is, you don't want your private electronic mail (email) or confidential documents read by anyone else.

https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html

It was designed for private electronic mail.

Or the PGP FAQ linked by the MIT keyserver:

> PGP is a program that gives your electronic mail something that it otherwise doesn't have: Privacy.

https://pgp.mit.edu/info.html

Where did you get your definition from? Because it's the first time I ever heard of it.

From www.openpgp.org:

> Although OpenPGP’s main purpose is end-to-end encrypted email communication, it is also utilized for encrypted messaging and other use cases such as password managers.

Tools and protocols evolve. Just because it was generated with email in mind doesn't mean that that's what people use it for these days.

Yes, but that still doesn't grant you permission to yell at people using it as originally intended. And whatever the "modern" usage for PGP may be, the purpose of keyservers still remain the same: publishing keys for others to use, or discovering them.

> Using multiple keys don't offer added security or secrecy.

Why wouldn't it?

I've got a chinesium grade tablet with some very convenient features, but between self-reenabling background services, the completely bypassed permission system, the device crashing whenever adb is used, it still trying to access wifi networks after deleting them and "resetting" the system, ..., I'm pretty sceptical about the privacy of the data, you can encrypt after it gets synced to their cloud.

I dont have any email accs I care about added to this device, but I can imagine some people wanting to read some emails on other lesser trusted devices.

A simple solution would be giving lesser trusted devices only access to lower security keys.

That's terrible operational security. You shouldn't be using the same email account in that scenario. Entering email credentials into an untrusted device will allow that device to send and receive emails, meaning it can read unencrypted emails. That's a major risk, considering that people might forget to encrypt them. Or they might simply follow other people's advice here and not use your advertised keys. Even granting untrusted devices access to encrypted emails pose a non-zero risk too because there are many ways it can go wrong.

> A simple solution would be giving lesser trusted devices only access to lower security keys.

That puts the burden of the decision of picking the right security level on the sender though, right? I don't see that ever becoming a thing.

> The only non-theoretical use of a PGP encryption key [that would use keys published on a keyserver] is email.

I use this on some repos https://github.com/AGWA/git-crypt

And occasionally to encrypt files, or receive encrypted files.

These are practical things which are non-theoretical.

> Using multiple keys don't offer added security or secrecy.

Depends on how careful you are or want to be, with your private key. My house key isn't the same as my car key isn't the same as my bike key.

> This is nothing like data harvesting

Alright fair, bad example. What I was grumbling about was more the lack of any clear communication that you've been auto-opted-in to a feature on protonmail, with no user interface signal indicating so, leading to confusion for a couple months like in TFA. I definitely wasn't casting shade on the opengpg keyserver, nor protonmail. It's the "hey! I didn't check a box for this, and it's not mentioned anywhere in the protonmail docs" hidden functionality which could do with some clarification.

I'm a forgetful creature. If I intentionally put my key on a keyserver, because I'm playing around and learning about PGP, will I make the connection between it and protonmail a few months down the line if I move my email account to them? Unlikely.

It's a nice automated feature. Protonmail-to-protonmail e2e encryption makes a lot of sense. I just think protonmail-to-non-protonmail e2e needs a tooltip in the UI, and the option to opt out, potentially with the ability to opt out for specific email addresses. I wouldn't at all assume it would be on by default even IF I've been actively using PGP in my email clients, because it's something you usually have to manually set up yourself, very explicitly. That, and 99.9% of emails are plaintext.

Anyhoo, one thing I forgot which kind of negates the "what if I have multiple encryption keys tied to my email" is the fact that the opengpg keyserver does tie 1 email address to 1 key so you can't publish multiple encryption keys, fair enough. Git-crypt and file encryption, I set my associated email address to use +tags eg me+git@email.com, so as far as protonmail etc are concerned there's only one key per logical email address.

> The only non-theoretical use of a PGP encryption key is email.

What an uninformed blanket statement. I use GPG many times per day, at work and otherwise, none of them for email:

Commit signing, SSH key storage (in a GnuPG smart card), deb package verification are only the ones that come to mind.

> Commit signing

You use your encryption key for that? Which PGP implementation does that? I use my signing key.

> SSH key storage

Again, I use my authentication key for that.

> deb package verification

I use the published signing keys. Never had to use any other key type.

> What an uninformed blanket statement.

I'm sorry for my ignorance. Could you at least provide an example that's valid?

Sorry, missed the "PGP encryption key". But still:

- I used to use `pass`, a password manager based on GPG. That needed the encryption key.

- Sharing of confidential data with coworkers at more than one job.

- Future-proofing: Even though I might not be using an encryption key now, creating all three (encryption, signing, authentication) is a common flow when using GnuPG cards, and then I do want to sync all three to the key server for convenience (so that I can use them at a different machine, for example) without broadcasting to the world "hey, email me encrypted stuff to keyid 0xABCD1234!".

None of those use cases should involve a public keyserver if you don't want people to email you encrypted stuff. Keyservers are literally there to "broadcast to the world 'hey, email me encrypted stuff to keyid 0xABCD1234!'."

Well, I use keyservers, and I don't intend to broadcast that fact.

Maybe I'm using them wrong in your view, but I don't see why your view is somehow the canonical one, given all the non-email examples I and other people in this thread have provided.

Because the act of publishing has a well-established meaning. The same reason I can't publish a book and shout at people who read it. "I wrote it for my eyes only, how dare you read it!" is a ridiculous thing to say.

Backing up my signed public keys, for example.

GnuPG card doesn’t store anything other than the private key, so there’s a risk of losing access.

I’m not sure if that protocol Protonmail is using would pick up such keys without email verification, though.

If you don't mean to publish your keys, you'd be better off backing them along with your other files rather than uploading it to a public keyserver.

I don't mind publishing my keys at all, and in fact for some of my applications it makes GPG much more ergonomic to use.

I do mind software or services taking that as an implicit statement of "go ahead, encrypt email to me using this" when it can clearly cause confusion and irrecoverable messages in many cases.

That said, we don't actually know if Protonmail really does search all keyservers (including the "old-style" ones, i.e. the ones where anybody could publish anything in an unverified manner and the "web of trust" is used to figure out which key is in fact trusted), or only the new ones that perform email verification.

If it's the latter, I think performing email verification could be considered a bit more of an opt-in statement to receiving encrypted mail.

Where do the docs on that page indicate that? Don't assume all users who are interested in privacy are experts on how keys work.

https://keys.openpgp.org/upload

Why should a service for publishing keys host manuals for GPG? The manuals are available at www.gnupg.org, where they belong.

https://www.gnupg.org/documentation/index.html

Also, why would that be grounds for shaming people who use published keys in a way it was designed for? I don't get your point.

The specific point is that there's nothing on the directory site to indicate that uploading a key to the directory will cause people to start encrypting your emails. From the description it sounds like a directory of pgp keys, nothing more and nothing less.

The more general point is that this is why people don't use these systems. There's very little thought given to UX. It's barely usable for average developers, let alone laypeople. Instead there's gatekeeping and stubborn pointing at ideals.

What do you think a public directory of PGP keys exist for? To publish them so that other people can use them without asking you for one in person. Why would it need a oh-this-is-not-actually-meant-to-be-public-it's-a-trap-for-shaming-people-who-reasonably-assumed-otherwise flag? Would that flag also need another this-flag-should-not-be-respected flag?

Yes, there are UX problems with PGP. No, that's not relevant to this particular case.

> To publish them so that can use them without asking you for one in person

without asking you for it, but not without asking you what to use it for.

Just like how people purchasing books from a bookstore have to ask each author what they're going to use the books for? I think not. The act of publishing a book clearly indicates that the author wants the book to be read. It's the same thing with public keyservers and PGP encryption keys.

Another example. When you put your email address in a contacts page in your blog, is the message "don't email me, ever" unless you add another "yes, you can use this for email purposes" disclaimer? If that's the case, shouldn't that disclaimer need another "yes, this disclaimer is what you think it means" disclaimer? And shouldn't that disclaimer also ... you get the idea.

Some actions, such as publishing something, has well-established meanings. You can't yell at people for thinking "publish" meant publish.

Your comparisons don't help, they are just verbose ways for you to (re-)state that you think publishing a key on keys.openpgp.org obviously means "you can email me encrypted" and that others may be a bit stupid to think otherwise (a bit like your "You can't yell at people for thinking "publish" meant publish" sentence, honestly, cut the bullshit)

I don't believe this to be the case. It's fine that we don't agree on this. Do you have sources? Because that would settle the discussion for good. Happy to be wrong. I'm not an expert on this stuff anyway.

Now, I also believe that it's not a big deal, if you unexpectedly receive an encrypted mail you can still decrypt it using your private key and if you don't know how to do this, you can always send your recipient "Hey, sorry, you sent me an encrypted mail that I can't decrypt, can you send me one without encryption?".

Unless, of course, your recipient's provider doesn't let them do this.

Maybe Proton doing this will push the ecosystem toward a more seamless support for encrypted mail, so it might even be a good thing. I don't know.

I mean encrypting email was what PGP was created for. It's my understanding that uploading keys was a sign that you wanted your emails to be encrypted as much as possible. Not a mere "I'll accept encrypted emails, even if begrudgingly."

Here's a snippet from the PGP FAQ last updated in 1998:

> Public Key Servers exist for the purpose of making your public key available in a common database where everybody can have access to it for the purpose of encrypting messages to you. Anyone who wants to write you a message, or to check a signature on a message from you, can get your key from the keyserver, so he doesn't have to bother you with it.

https://www.pgp.net/pgp-faq/faq.html#8.1

Of course, the writing was on the wall for PGP in email when I created my first keys a decade ago. But it was still touted as a tool for encrypting emails even then during the height of the Snowden disclosures. The complete loss of interest in using it for email is a relatively new phenomenon.

For every single use case a key can be used for? Automatically? Maybe even for use cases that didn't exist when the key was added? (Email did exist)

Someone generated a public key and caused it to be held by a keyserver by validating it. One would think the onus is on them to limit the validity of what they want the key used for, not a presupposition that only certain unknown bits of data can be used with this otherwise public and published key.

I publish a key associated with abofh@ycombinator.com - I would expect things that identify me as such would use it. If it identifies me as a phone number, I wouldn't expect it to use it. If it identifies me by my mastadon handle, I wouldn't expect it to use it. This isn't complicated - the author published "use this public key for me@foo.com" - people did (via automated means), and the author found out he wasn't properly equipped to handle that mail. So he withdrew the publication and everything worked normally.

Nothing in here is anything more than "I did something 10 years ago that bit me in the ass today" - which to be fair, happens to all of us, but don't blame the technology for doing _exactly_ what the user asked for even if they forgot they asked.

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

The post includes the above statement that this person never took the steps required for following the standard Proton states they are following. This communicates to me that Proton is not following any standard. This is something publicly visible and on a grander level fairly simple to discover compared to other issues related to E2E encryption. I don't trust Proton or really any organization to manage E2E for email, and among the biggest issues is that email just seems like the wrong tool for the job.

Another issue I have with encrypted email is what to do about spam. If the server can't inspect the contents of the message, the probability of a "success" on the part of the spammer is significantly higher. Public keys can be published for addresses that have very high limitations (e.g., 1KB size limit, strict mail policy standards enforcement, whitelists, etc.). How Proton plans to deal with this an average person, I have no idea, but I imagine a lot of people will be scammed in their discovery process.

Hate to badmouth them: but they are definitely broken recently (one full month at least). I get long term contacts fine from things like AWS, but multiple new people i have not contacted before just do not get anything, complete silent failure (with @proton.me) with no indication that my contact received nothing. I created an alias using @protonmail.com and that worked to new people

That doesn't sound right. Have you opened a support ticket with us so that we can look into what's happening? You can do it here: https://proton.me/support/troubleshooting?product=mail

Silent failures are about as bad as it gets, but it's probably related to overlooked edge-cases during the simplelogin integration.

If you file a bug report, there should be a probably highly stressed, overworked and slightly paniced team ready to get a fix out by yesterday.

The current email protocols can’t be easily encrypted. There are multiple providers and clients that are not compatible, you often have to put people in copy that don’t have public keys, or get replies in plaintext, you may want the content accessible to different people for documentation or legal purposes, some functionality will be broken or become hard to use, it’s asynchronous, and there is simply little demand for privacy from the providers.

The use cases are currently niche, in places like dark web.

In short, “if you have nothing to hide, you have nothing to fear.” I disagree. Privacy is a fundamental human right essential to a functioning democracy.

these kinds of stories are such a joke, why can i not just give someone my public key and that should be enough to communicate with him forever? how is that not user friendly? because he can lose the key? you just give it again. you just use some decentralized protocol with a DHT or something and the only step the user ever has to do is get the public key of the person he wants to add. net result is far better off than nonsense like email, dns, and x509. and i had this exact same rant 15-20 years ago too, it's amazing how everyone is still chasing the same carrot.

Older generations tend to use Messengers like whatsapp. E-Mail has some Henry barriers often to high for them. Would be great to have an email app as simple as whatsapp

If there is one thing I absolutely want to keep out of the big techs and governments surveillance data lakes its conversations with my mother. What will become of the world if we can’t even talk with our mothers without it being taken as a chance by some extrafamilial power to exert some behavioral modification.

I was very fortunate to have set up Mom with video chat just before the pandemic. Maybe try that?

Video chat... in an age where algorithms exist to transpose faces and voices in real time.

I admire the idea but I doubt it solves the problem: trusting that the communication is both private and authentic.

It's commonly claimed to be end-to-end encrypted. Maybe you can find software you trust more than mainstream providers, though?

What does one have to do with the other? Algorithms to generate and imitate email text exist as well.

If you want to be able to trust the content, you need to encrypt and authenticate that, no matter the channel.

And many VoIP/video conferencing systems these days are end-to-end encrypted! It’s arguably easier than email, since communication is synchronous and there isn’t any expectation of being able to view past conversations, both of which are not true for email.

This is a good point. While faces and voices can be faked, text cannot

I think maybe the point is rather than faces and voices can be indexed like text now too. For a brief time this was probably computationally infeasible and so it offered privacy, but now a government or company could theoretically automatically analyze all video chats.

PGP+email still makes indexing this content computationally infeasible though.

> PGP+email still makes indexing this content computationally infeasible though.

This makes sense because the only thing you can encrypt is text and not video

Let me know what platform you use for encrypted video calls that isn’t based on trusting a third party with the private keys.

That is usually the requirement to get a UX people will use with their non technical family, but people accepted it, I think in part because it didn’t seem practical to index it all. It definitely is practical now though.

Not the GP, but I'd at least imagine that a self-hosted XMPP could get the job done. You'd probably also need your own STUN and TURN servers, but it should definitely be doable.

Hell, might even be doable with public XMPP and OMEMO, but I don't know if that works with the video call stuff.

It's sadly a lot of effort, but I feel that for stuff like family privacy stuff, it might just be worth it.

I self host prosody (an XMPP server) with a TURN server in my living room. With Guix System this is largely declarative, aside from the DNS records and initial user account registration (which I do on the command line).

We're using it for messaging, sharing files, video calls across continents, etc. Re video calls: the XMPP and TURN servers are only used for negotiating the connection, so you don't need a very powerful machine for any of this.

I have a little Rockpro64 for this purpose.

Signal?

https://support.signal.org/hc/en-us/articles/360007060492-Vo...

Signal is what we use

Use signal.

as soon as it stops requiring phone number as identifier

they did that already. you can sign up with just an account name now, i ditched my phone number from my account after it rolled out around a month ago.

I'm quite sure you still need a phone number to sign up? Afrer that you can hide it but not get rid of it.

Still the fact that you can use it without disclosing your phone number to anyone except signal is indeed useful and a improvement from before.

https://support.signal.org/hc/en-us/articles/6712070553754-P...

Serious question: what should they, or some idealized privacy-first messaging service, use for as a account-id + authentication? I will need some reasonably cost-effective defense against mass abuse.

They could offer usernames tied to a one-time minimum donation, for example, let existing users vouch for new ones etc.

Yes, all more difficult than using phone numbers and outsourcing the proof-of-humanity problem to telcos all over the world, but in my opinion it would be worth it.

Last I checked, Signal doesn't support email...

So if I understand correctly:

- Proton uses WKD for keys outside its own domain

- OP didn't activate WKD for their own key (there is no CNAME)

- But Proton still assumed that it was activated, that their key was on keys.openpgp.org and that it was valid

It is hard for me to see how this is not a fault with Proton and Proton only. If the user didn't opt-in, don't opt-in for them !

Don't upload your key to a public keyserver with an email address you have to verify you don't want to receive encrypted things with. That is the opt-in!

Usually the problem is the exact opposite, it's really annoying to find someone's public key even if they have given you the key ID or mentioned they can receive such mail.

That a key exist on a random keyserver means nothing. There is a spec that explicitely says "if you want to use my key here it is" and Proton doesn't respect it. what does it mean that you found the key on some third-party domain ? There are 0 safeguards, I don't know what they're going to do with it, there is no obligation from any side. A key in keys.openpgp.org means nothing.

It means someone uploaded it there and verified the address in the identity (or subidentity). A keyserver is exactly for "here's my key, use it".

Don't publish your keys if you don't want them used. It's not that difficult.

>It is hard for me to see how this is not a fault with Proton and Proton only. If the user didn't opt-in, don't opt-in for them !

The counter argument is that they opted-in by publishing an encryption key to a public key server.

No, the opt-in is by actually following the spec, not uploading to a random server op has 0 control over.

>not uploading to a random server op has 0 control over.

OP has full control over uploading their key, activating their key, and deactivating their key on the "random server".

By the way, the "random server" is.... The OpenPGP server.

Yes, but that's not a protocol. That's uploading a key to a server. The protocol is WKD and Proton doesn't respect it.

Me opening an account on GMail doesn't mean I want people to contact me on GMail. If our protocol, ie you asking me what is my email and I don't give you my email then I don't want you to contact via my GMail account.

No, Proton didn't assume WKD was activated, and WKD doesn't have much to do with what's going on. What happened is:

- The user, or their software, uploaded a public key to keys.openpgp.org

- Proton looked up their email address on keys.openpgp.org, and sent them an encrypted email

- They didn't have the private key anymore, and couldn't read the email

The fix is to remove the key from keys.openpgp.org, or remove the email address from the key, or remove the encryption subkey.

Alternatively, setting up WKD would actually work as well, since then Proton uses that instead. I.e. if there's no key on WKD, we don't send encrypted emails.

Why does proton look up keys.openpgp.org? Is keys.openpgp.org assumed to be The One Directory for everyone ? Who said so ?

There is no reason to consider it as the centre of the world if you deon't use it. That's exactly what wkd is about: specifically saying that there is a key to talk to you, and where it is.

If I publish a key in my Myspace profile that doesn't mean it's valid. The author never signalled any key to be usable, the key being on that specific directory means nothing.

It's not the first time you take liberties with protocols and specs under the premise of "simplification", and again ano again things break because you don't respect anything. How can you be taken as a peer of value if you keep screwing up and accusing users for not holding it right ?

keys.openpgp.org is the semi-canonical key server for OpenPGP. Certainly there are other key servers, but it makes more sense for us to look up keys on a keyserver hosted under openpgp.org than one hosted by Ubuntu or any other single entity. KOO is a community-led and -governed project. It now even has elections and a board (which we joined): https://keys.openpgp.org/about/news#2023-04-28-governance

WKD is great, but can't be used by people with email addresses under domains that don't support it. So KOO fills that gap.

Yes, KOO is a good intermediary, but it still matters: there are no agreed-upon mechanism saying it should be used in all cases. You took this liberty. Why not even ask the receivers, aka those who know, if they're ok using that key ?

We can't easily ask them that. KOO could ask, though, since that's what the user's interacting with when they're uploading the key. And, I do agree that the signalling could be improved, there, so I'll discuss it with them.

Reply on news.ycombinator.com