return to table of content

Why can't my mom email me?

Valodim
79 replies
3d19h

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.

kazinator
38 replies
3d18h

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

cdmckay
21 replies
3d17h

Yeah, my mom would totally understand that prompt.

kazinator
17 replies
3d17h

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.

PurestGuava
16 replies
3d15h

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)

twiss
7 replies
3d14h

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

kelnos
3 replies
3d13h

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

twiss
1 replies
3d12h

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

lxgr
0 replies
3d4h

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.

wnoise
0 replies
3d5h

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

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

dmurray
1 replies
3d10h

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.

twiss
0 replies
3d9h

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.

kkoyung
0 replies
2d9h

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.

mcv
2 replies
3d8h

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.

lxgr
0 replies
3d3h

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

PurestGuava
0 replies
2d2h

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.

ComodoHacker
2 replies
3d14h

the sensible default would be to send email unencrypted

That's exactly what anti-encryptionists would want.

lxgr
0 replies
3d4h

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.

kazinator
0 replies
3d7h

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

pard68
0 replies
3d9h

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

PKop
0 replies
3d6h

the sensible default would be to send email unencrypted

Why even use Proton then? What is the point?

eviks
2 replies
3d12h

Anyone can understand this

If unsure, choose "No".
thedanbob
1 replies
3d9h

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.

baobabKoodaa
0 replies
3d8h

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

mcv
7 replies
3d8h

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.

LeifCarrotson
6 replies
3d5h

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.

pxx
3 replies
3d3h

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!

thayne
2 replies
2d19h

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.

pxx
1 replies
2d18h

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.

mcv
0 replies
2d8h

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

thayne
0 replies
2d19h

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

mcv
0 replies
2d23h

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.

jacoblambda
7 replies
3d8h

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.

tristan957
3 replies
3d7h

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

twiss
2 replies
3d7h

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

tristan957
1 replies
3d5h

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

altairprime
0 replies
18h51m

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

twiss
1 replies
3d7h

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.

kkoyung
0 replies
2d10h

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.

floren
0 replies
3d7h

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!

akerl_
29 replies
3d18h

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?

nulbyte
21 replies
3d18h

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?

noahtallen
5 replies
3d18h

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.

aborsy
4 replies
3d17h

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.

jsjohnst
3 replies
3d12h

Encryption is not just for encrypted emails.

Macha
0 replies
2d12h

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.

soraminazuki
0 replies
3d10h

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.

jsnell
5 replies
3d17h

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.

bananskalhalk
3 replies
3d8h

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?

akerl_
2 replies
3d8h

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

akerl_
0 replies
3d5h

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.

Spivak
0 replies
3d8h

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.

franga2000
4 replies
3d16h

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.

layer8
2 replies
3d10h

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

akerl_
1 replies
3d9h

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

twiss
0 replies
3d6h

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.

twiss
0 replies
3d12h

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.

UberFly
1 replies
3d18h

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

layer8
0 replies
3d10h

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.

watwut
0 replies
3d9h

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

kazinator
0 replies
3d18h

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.

Valodim
6 replies
3d14h

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.

twiss
5 replies
3d12h

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.

paulnpace
4 replies
3d10h

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

twiss
3 replies
3d9h

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.

paulnpace
2 replies
3d8h

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.

twiss
1 replies
3d6h

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

paulnpace
0 replies
1d10h

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.

yau8edq12i
7 replies
3d15h

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.

twiss
4 replies
3d14h

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

yau8edq12i
3 replies
3d14h

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?

jmuguy
1 replies
3d5h

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

yau8edq12i
0 replies
2d7h

Read the GP comment...

twiss
0 replies
3d13h

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.

james_in_the_uk
0 replies
2d9h

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.

Valodim
0 replies
3d14h

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

jojobas
1 replies
3d14h

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?

Valodim
0 replies
3d14h

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.

eduction
68 replies
3d18h

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

pflenker
23 replies
3d17h

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

input_sh
12 replies
3d16h

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.

tedunangst
5 replies
3d15h

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

abofh
4 replies
3d15h

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

darkwater
3 replies
3d13h

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

twiss
2 replies
3d11h

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.

darkwater
1 replies
3d8h

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.

abofh
0 replies
1d11h

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.

pflenker
4 replies
3d16h

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.

twiss
1 replies
3d14h

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

MKRhere
0 replies
3d1h

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

input_sh
1 replies
3d15h

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.

lxgr
0 replies
3d5h

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

kelnos
0 replies
3d13h

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.

deely3
9 replies
3d17h

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

franga2000
4 replies
3d16h

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.

nkrisc
1 replies
3d11h

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.

lxgr
0 replies
3d5h

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.

deely3
0 replies
3d16h

Im not sure that I see logic here..

PKop
0 replies
3d6h

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

arghwhat
3 replies
3d15h

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.

pxx
1 replies
3d3h

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.

arghwhat
0 replies
2d10h

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.

gcr
0 replies
3d11h

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

jrockway
17 replies
3d17h

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

yau8edq12i
8 replies
3d15h

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

TylerE
3 replies
3d15h

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?

0x073
2 replies
3d15h

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

rrr_oh_man
0 replies
3d14h

Good look enforcing GDPR in Panama…

jazzyjackson
0 replies
3d8h

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

hyperman1
2 replies
3d10h

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/

yau8edq12i
1 replies
3d9h

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.

mcv
0 replies
3d8h

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

upofadown
0 replies
3d7h

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

stingraycharles
2 replies
3d15h

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

layer8
1 replies
3d10h

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.

olabyne
1 replies
3d14h

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

graywh
0 replies
3d5h

the government still uses them

napoleongl
1 replies
3d17h

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.

vladvasiliu
0 replies
3d14h

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.

lxgr
0 replies
3d8h

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.

kelnos
16 replies
3d17h

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?

soraminazuki
11 replies
3d13h

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.

Macha
5 replies
3d12h

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.

soraminazuki
4 replies
3d11h

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

Macha
3 replies
3d10h

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

soraminazuki
2 replies
3d9h

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

Macha
1 replies
3d8h

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.

soraminazuki
0 replies
3d7h

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.

kelnos
4 replies
3d13h

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.

soraminazuki
3 replies
3d12h

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.

soraminazuki
2 replies
2d17h

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.

Macha
1 replies
2d12h

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

soraminazuki
0 replies
2d9h

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

Freak_NL
3 replies
3d16h

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.

soraminazuki
2 replies
3d12h

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.

caddy
1 replies
3d11h

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.

soraminazuki
0 replies
3d11h

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.

tedunangst
4 replies
3d15h

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.

reidrac
3 replies
3d15h

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

gwd
1 replies
3d15h

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

reidrac
0 replies
3d11h

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.

Andrex
0 replies
3d5h

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.

worddepress
0 replies
3d18h

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.

upofadown
0 replies
3d7h

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.

dimask
0 replies
3d15h

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.

Macha
0 replies
3d12h

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.

smoyer
52 replies
3d21h

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

lxgr
37 replies
3d19h

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.

nulbyte
36 replies
3d18h

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?

jraph
34 replies
3d17h

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

soraminazuki
33 replies
3d16h

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

erinaceousjones
24 replies
3d15h

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.

soraminazuki
20 replies
3d14h

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?

kelnos
9 replies
3d13h

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.

soraminazuki
8 replies
3d12h

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

lxgr
7 replies
3d9h

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

soraminazuki
6 replies
3d9h

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.

lxgr
5 replies
3d8h

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.

soraminazuki
4 replies
3d7h

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.

lxgr
3 replies
3d6h

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

soraminazuki
2 replies
3d5h

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.

lxgr
1 replies
3d4h

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.

soraminazuki
0 replies
3d3h

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.

lxgr
5 replies
3d9h

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.

soraminazuki
4 replies
3d9h

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?

lxgr
3 replies
3d8h

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

soraminazuki
2 replies
3d6h

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

lxgr
1 replies
3d6h

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.

soraminazuki
0 replies
3d5h

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.

DeepSeaTortoise
2 replies
3d12h

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.

soraminazuki
0 replies
3d12h

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.

lxgr
0 replies
3d3h

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.

erinaceousjones
0 replies
3d10h

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.

lxgr
2 replies
3d9h

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.

soraminazuki
1 replies
3d9h

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.

lxgr
0 replies
3d8h

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.

smallerfish
7 replies
3d12h

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

soraminazuki
6 replies
3d11h

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.

smallerfish
5 replies
3d10h

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.

soraminazuki
4 replies
3d9h

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.

jraph
3 replies
2d16h

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.

soraminazuki
2 replies
2d14h

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.

jraph
1 replies
2d10h

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.

soraminazuki
0 replies
2d7h

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.

cl3misch
0 replies
3d17h

To play around with it?

kiwijamo
11 replies
3d21h

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.

Arnavion
5 replies
3d21h

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.

lxgr
4 replies
3d19h

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.

unethical_ban
3 replies
3d18h

I don't understand.

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

mkl
2 replies
3d18h

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

unethical_ban
0 replies
3d

Still strange, but I know what they mean now.

lxgr
0 replies
3d9h

Yep, that’s what I meant!

int_19h
4 replies
3d21h

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.

abofh
3 replies
3d16h

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

lxgr
0 replies
3d5h

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.

kelnos
0 replies
3d13h

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

PeterisP
0 replies
3d14h

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.

pmontra
1 replies
3d16h

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)

abofh
0 replies
3d16h

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.

roenxi
26 replies
3d21h

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

andai
9 replies
3d18h

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.

paulryanrogers
5 replies
3d17h

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.

marcus_holmes
2 replies
3d17h

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.

ComodoHacker
1 replies
3d14h

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.

marcus_holmes
0 replies
3d7h

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?

denton-scratch
1 replies
3d11h

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.

joveian
0 replies
3d10h

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

marcus_holmes
2 replies
3d17h

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

twiss
1 replies
3d12h

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

marcus_holmes
0 replies
3d7h

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

mulmen
7 replies
3d20h

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.

prussia
3 replies
3d18h

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.

mulmen
2 replies
3d14h

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

tristan957
0 replies
3d7h

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.

kayodelycaon
0 replies
3d7h

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

greyface-
2 replies
3d20h

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/

mulmen
1 replies
3d19h

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

Andrex
0 replies
3d5h

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.

chrismorgan
2 replies
3d17h

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

abofh
1 replies
3d16h

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.

chrismorgan
0 replies
3d12h

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

WithinReason
2 replies
3d10h

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?

akdev1l
1 replies
3d7h

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.

WithinReason
0 replies
3d6h

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.

gerdesj
0 replies
3d20h

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.

LinuxBender
0 replies
3d9h

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

totetsu
12 replies
3d20h

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.

skybrian
11 replies
3d20h

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

inetknght
10 replies
3d20h

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.

jrflowers
7 replies
3d19h

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

mattnewton
6 replies
3d19h

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.

jrflowers
5 replies
3d18h

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

mattnewton
4 replies
3d18h

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.

totetsu
0 replies
3d17h

Signal is what we use

sham1
1 replies
3d18h

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.

rekado
0 replies
3d15h

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.

skybrian
0 replies
3d19h

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

lxgr
0 replies
3d19h

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.

rakoo
12 replies
3d8h

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 !

twiss
4 replies
3d6h

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.

rakoo
3 replies
3d5h

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 ?

twiss
2 replies
3d3h

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.

rakoo
1 replies
2d14h

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 ?

twiss
0 replies
2d10h

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.

ziddoap
3 replies
3d6h

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.

rakoo
2 replies
3d5h

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

ziddoap
1 replies
3d5h

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.

rakoo
0 replies
2d14h

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.

Avamander
2 replies
3d6h

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.

rakoo
1 replies
3d5h

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.

Avamander
0 replies
3d3h

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.

kevincox
7 replies
3d21h

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

Valodim
3 replies
3d19h

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.

PaulDavisThe1st
2 replies
3d19h

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.

Valodim
1 replies
3d18h

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.

PaulDavisThe1st
0 replies
3d18h

Indeed, you are correct, and I was wrong.

lxgr
2 replies
3d19h

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.

brewdad
1 replies
3d18h

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.

lxgr
0 replies
3d9h

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.

jms703
6 replies
3d19h

Use signal.

NooneAtAll3
4 replies
3d18h

as soon as it stops requiring phone number as identifier

spaceguillotine
3 replies
3d17h

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.

em500
1 replies
3d13h

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.

lxgr
0 replies
3d5h

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.

gnyman
0 replies
3d17h

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

upofadown
0 replies
3d7h

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

plopilop
5 replies
3d13h

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.

outime
1 replies
3d13h

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.

izacus
0 replies
3d8h

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.

Andrex
1 replies
3d4h

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

upofadown
0 replies
3d7h

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

gnyman
4 replies
3d16h

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

upofadown
1 replies
3d7h

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

twiss
0 replies
3d6h

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

kjhcvkek77
0 replies
3d6h

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.

bartbutler
0 replies
3d13h

Proton does this.

beefnugs
2 replies
3d16h

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

DeepSeaTortoise
0 replies
3d13h

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.

felixfbecker
1 replies
3d19h

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

Avamander
0 replies
3d6h

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.

aborsy
1 replies
3d13h

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.

soraminazuki
0 replies
3d10h

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.

ulrischa
0 replies
3d14h

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

uconnectlol
0 replies
3d6h

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.

softgrow
0 replies
3d20h

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.

rvnx
0 replies
3d21h

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

paulnpace
0 replies
3d10h

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.