9 ms·

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 conc

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.

akerl_ 3y ago
> 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 3y ago
  > 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?
  - UberFly 3y ago
    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 3y ago
      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.
  - kazinator 3y ago
    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.
  - noahtallen 3y ago
    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 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 3y ago
      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 3y ago
        Encryption is not just for encrypted emails.
        soraminazuki 3y ago
        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.
        nulbyte 3y ago
        There are separate flags for communications (like email) and storage (like files). https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21 https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....
        Macha 3y ago
        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.
  - jsnell 3y ago
    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.
    - Spivak 3y ago
      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.
    - bananskalhalk 3y ago
      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_ 3y ago
        What's the subtype that's for encrypting emails? Last I looked, there's a subtype for encryption, with no specificity for what medium.
        nulbyte 3y ago
        Not for email specifically, but there is a flag for encrypted communications and another for signing. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21 https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.... I believe separate keys for encryption and signing is the default in most implementations.
        akerl_ 3y ago
        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.
  - franga2000 3y ago
    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.
    - twiss 3y ago
      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.
    - layer8 3y ago
      Would you also make TLS opt-in for each website?
      - akerl_ 3y ago
        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".
        3y ago
  - watwut 3y ago
    Usually by random action completely unrelated to emails they forgot about a few years ago.
- Valodim 3y ago
  I dunno, you'll have to ask Proton about that. Presumably they think it is what their users want, and they may or may not then be right about that. This feature has also been active for a few months only, so it might also change with further insight.
  - twiss 3y ago
    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 3y ago
      I'm just kind of wondering how this wasn't discovered or why it wasn't fixed in testing?
      - twiss 3y ago
        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 3y ago
        > 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.
kazinator 3y ago
> 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 3y ago
  Yeah, my mom would totally understand that prompt.
  - kazinator 3y ago
    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 3y ago
      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)
yau8edq12i 3y ago
Is this page really the entirety of your privacy policy? https://keys.openpgp.org/about/privacy 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.
- Valodim 3y ago
  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 :)
  - yau8edq12i 3y ago
    [flagged]
  - yau8edq12i 3y ago
    [flagged]
- twiss 3y ago
  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 3y ago
    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?
jojobas 3y ago
>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 3y ago
  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.

akerl_ 3y ago

> 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 3y ago
> 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?
- UberFly 3y ago
  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 3y ago
    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.
- kazinator 3y ago
  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.
- noahtallen 3y ago
  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 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 3y ago
    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 3y ago
      Encryption is not just for encrypted emails.
      - soraminazuki 3y ago
        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.
      - nulbyte 3y ago
        There are separate flags for communications (like email) and storage (like files). https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21 https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....
        Macha 3y ago
        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.
- jsnell 3y ago
  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.
  - Spivak 3y ago
    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.
  - bananskalhalk 3y ago
    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_ 3y ago
      What's the subtype that's for encrypting emails? Last I looked, there's a subtype for encryption, with no specificity for what medium.
      - nulbyte 3y ago
        Not for email specifically, but there is a flag for encrypted communications and another for signing. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21 https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.... I believe separate keys for encryption and signing is the default in most implementations.
        akerl_ 3y ago
        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.
- franga2000 3y ago
  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.
  - twiss 3y ago
    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.
  - layer8 3y ago
    Would you also make TLS opt-in for each website?
    - akerl_ 3y ago
      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".
      - 3y ago
- watwut 3y ago
  Usually by random action completely unrelated to emails they forgot about a few years ago.
Valodim 3y ago
I dunno, you'll have to ask Proton about that. Presumably they think it is what their users want, and they may or may not then be right about that. This feature has also been active for a few months only, so it might also change with further insight.
- twiss 3y ago
  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 3y ago
    I'm just kind of wondering how this wasn't discovered or why it wasn't fixed in testing?
    - twiss 3y ago
      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 3y ago
        > 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.

kazinator 3y ago

> 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 3y ago
Yeah, my mom would totally understand that prompt.
- kazinator 3y ago
  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 3y ago
    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)

yau8edq12i 3y ago

Is this page really the entirety of your privacy policy? https://keys.openpgp.org/about/privacy 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.

Valodim 3y ago
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 :)
- yau8edq12i 3y ago
  [flagged]
- yau8edq12i 3y ago
  [flagged]
twiss 3y ago
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 3y ago
  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?

jojobas 3y ago

>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 3y ago
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.