3 ms·

Cryptography Dispatches: Replace PGP with an HTTPS Form

13 points by arkadiyt 6y ago

eqvinox 6y ago
I wish the post was more clear about its actual scenario, because: My spicy take is that if you are concerned about email, instead of trying to be cool you should skip PGP and just put up a Google Form. This is perfectly reasonable for Golang, which is a Google project anyway, but not for the rest of the planet.
- floatingatoll 6y ago
  I wish your reply was more clear about the argument and reasoning to support your view that it’s unreasonable “for the rest of the planet”. Your position is theoretically an interesting viewpoint, but without any context or explanation it is meaningless to the rest of us here. I hope that you’ll take the time to explain further, so that we can all comprehend your reasoning.
  - eqvinox 6y ago
    Go development, to my knowledge, is mostly a "Google shop". And a lot of the infrastructure at Google is harmonized company-wide, which means it's reasonable to treat it as one large entity that is already involved and there isn't much of a change in using another service of the same entity. As in, it doesn't add any parties to the security scenario. The information enters into Google anyway. For other people, information on security incidents does not a priori enter into Google, and adding Google as an additional party is to be considered a cost — as is any addition of people you need to trust. Furthermore, this is a situation where disaggregation provides a strong benefit. If a lot of people use any service, e.g. Google Forms, for vulnerability reports, that service becomes a prime target for state-level surveillance. How realistic that is is secondary — the question is what the benefit is for the security cost that you're incurring. While PGP is showing its age, I'm gonna argue that it's still perfectly fine for security handling, and by design its use means that you can pick and choose very well who can decrypt the data, and on what systems. [Ed. P.S.:] Or just set up your own https form on a system already within your trust domain. If you're more comfortable with that than PGP, anyway.
    - floatingatoll 6y ago
      There's a paragraph endorsing various HTTPS form solutions that are not Google Form midway through the article, including the specific comment: > The specific implementation of that form really depends on your circumstances, I am not trying to sell you Google Forms specifically. Based on that and the surrounding context, the author understands that a Google Form is not always the right solution. They do tend to suggest centralized solutions rather than self-hosted ones, but that aligns with my perception that DIY sites are exponentially more likely to be hacked than Google or Zendesk are. So it seems like you're combining the argument for PGP when the argument against centralized solutions, but your footnote walks back the argument against PHP as long as the solution is not centralized. Do you agree with the author of the post that an HTTPS form is more effective than PGP, but only as long as it's not centrally hosted?
      - eqvinox 6y ago
        > The specific implementation of that form really depends on your circumstances, I am not trying to sell you Google Forms specifically. And that's followed by a footnote: > Still, a Google Form going to a Gmail mailbox enrolled in the Advanced Protection Program is probably the most secure reporting channel against real-world threats. PGP will get misused and anything else phished before anyone gets into an APP’d Google Account. ... so it's back and forth on it. Since this is security we're talking about, I don't think it's a good idea to communicate in a style like that. People's brains will condense it down and then you're stuck with "use Google Forms", and that's what I'm arguing against. > So it seems like you're combining the argument for PGP when the argument against centralized solutions, but your footnote walks back the argument against PGP as long as the solution is not centralized. The decentralization is very high on the priorities for me on this, and the argument I really want to make is that you should be using something decentralized. PGP seems to be the established practice, and that gives it a huge edge just because people still need to deal with it anyway (and hopefully spend a bit of time learning how to use it correctly.) I also think that a message-level encryption system will beat account-level access control; I really don't want my phone to have access to security exchanges. > Do you agree with the author of the post that an HTTPS form is more effective than PGP, but only as long as it's not centrally hosted? Honestly, no, because I agree with you that I can't host a HTTPS form and get better security out of it than I do with PGP. And I think a huge part of people is in the same boat with me there. But that may not be the case for all people, hence my "If you're more comfortable with that than PGP, anyway." (…especially since that form is only half the way, you still need to somehow read the submissions…) But this is something that could change with the introduction of a pre-made FOSS kit to run a page like that.

13 points by arkadiyt 6y ago

I wish the post was more clear about its actual scenario, because: My spicy take is that if you are concerned about email, instead of trying to be cool you should skip PGP and just put up a Google Form. This is perfectly reasonable for Golang, which is a Google project anyway, but not for the rest of the planet.

floatingatoll 6y ago
I wish your reply was more clear about the argument and reasoning to support your view that it’s unreasonable “for the rest of the planet”. Your position is theoretically an interesting viewpoint, but without any context or explanation it is meaningless to the rest of us here. I hope that you’ll take the time to explain further, so that we can all comprehend your reasoning.
- eqvinox 6y ago
  Go development, to my knowledge, is mostly a "Google shop". And a lot of the infrastructure at Google is harmonized company-wide, which means it's reasonable to treat it as one large entity that is already involved and there isn't much of a change in using another service of the same entity. As in, it doesn't add any parties to the security scenario. The information enters into Google anyway. For other people, information on security incidents does not a priori enter into Google, and adding Google as an additional party is to be considered a cost — as is any addition of people you need to trust. Furthermore, this is a situation where disaggregation provides a strong benefit. If a lot of people use any service, e.g. Google Forms, for vulnerability reports, that service becomes a prime target for state-level surveillance. How realistic that is is secondary — the question is what the benefit is for the security cost that you're incurring. While PGP is showing its age, I'm gonna argue that it's still perfectly fine for security handling, and by design its use means that you can pick and choose very well who can decrypt the data, and on what systems. [Ed. P.S.:] Or just set up your own https form on a system already within your trust domain. If you're more comfortable with that than PGP, anyway.
  - floatingatoll 6y ago
    There's a paragraph endorsing various HTTPS form solutions that are not Google Form midway through the article, including the specific comment: > The specific implementation of that form really depends on your circumstances, I am not trying to sell you Google Forms specifically. Based on that and the surrounding context, the author understands that a Google Form is not always the right solution. They do tend to suggest centralized solutions rather than self-hosted ones, but that aligns with my perception that DIY sites are exponentially more likely to be hacked than Google or Zendesk are. So it seems like you're combining the argument for PGP when the argument against centralized solutions, but your footnote walks back the argument against PHP as long as the solution is not centralized. Do you agree with the author of the post that an HTTPS form is more effective than PGP, but only as long as it's not centrally hosted?
    - eqvinox 6y ago
      > The specific implementation of that form really depends on your circumstances, I am not trying to sell you Google Forms specifically. And that's followed by a footnote: > Still, a Google Form going to a Gmail mailbox enrolled in the Advanced Protection Program is probably the most secure reporting channel against real-world threats. PGP will get misused and anything else phished before anyone gets into an APP’d Google Account. ... so it's back and forth on it. Since this is security we're talking about, I don't think it's a good idea to communicate in a style like that. People's brains will condense it down and then you're stuck with "use Google Forms", and that's what I'm arguing against. > So it seems like you're combining the argument for PGP when the argument against centralized solutions, but your footnote walks back the argument against PGP as long as the solution is not centralized. The decentralization is very high on the priorities for me on this, and the argument I really want to make is that you should be using something decentralized. PGP seems to be the established practice, and that gives it a huge edge just because people still need to deal with it anyway (and hopefully spend a bit of time learning how to use it correctly.) I also think that a message-level encryption system will beat account-level access control; I really don't want my phone to have access to security exchanges. > Do you agree with the author of the post that an HTTPS form is more effective than PGP, but only as long as it's not centrally hosted? Honestly, no, because I agree with you that I can't host a HTTPS form and get better security out of it than I do with PGP. And I think a huge part of people is in the same boat with me there. But that may not be the case for all people, hence my "If you're more comfortable with that than PGP, anyway." (…especially since that form is only half the way, you still need to somehow read the submissions…) But this is something that could change with the introduction of a pre-made FOSS kit to run a page like that.