4 ms·

Webmail services could have jump-started WoT a decade ago, much like Hotmail jumpstarted popular email usage. [1] Had they "turned on" PGP for all their users,

by leot 13y ago

Webmail services could have jump-started WoT a decade ago, much like Hotmail jumpstarted popular email usage. [1] Had they "turned on" PGP for all their users, and then made it easy to tell when messages were being sent securely and when they weren't, it would have completely (and for the better) changed how we interact online (e.g., no need to "sign up" for web services, or "sign in" to every single site we visit; a lot less spam; and incredible other potential besides). I think we can now surmise one big reason why they didn't. (tptacek will say that web-based PGP is the wrong way to go because it's too insecure: fact is it's still way more secure than sending cleartext emails, and in any case the point of it is to bootstrap adoption and hopefully trigger an email "arms race") [1] Gmail even began with some support for PGP signature verification http://googlesystem.blogspot.com/2009/02/gmail-tests-pgp-signature-verification.html http://googlesystem.blogspot.com/2009/02/gmail-tests-pgp-sig... ... and then stopped. Anyone on the inside know why?

IgorPartola 13y ago
Webmail + PGP really is insecure. The only way to do it properly would be with some OSS plugin + completely separate process for actually reading/writing emails. However, I think we could use a better way to associate emails with PGP keys. For example, my email uses a domain I own. I have HTTPS on my domain, so I can deliver my public key to you securely over the Web. Alternatively, Google could have a service where you securely ask it "what is the key for example@gmail.com" and it responds with the key. Bootstrapping a full WoT is hard, but often times the requirements are much less strict. Most times I just want to know that if I email you that you are the only one that can read the email. I might not even care if you are truly the person you claim to be, as I know you by your email handle more than by your real name (as in emailing Satoshi Nakamoto). Of course having a webmail provider tell others what your public key is means you have to trust your webmail provider not to lie. You also have to trust their delivery mechanism (HTTPS) and the people that issue them their SSL certificates (as we know this can be circumvented by motivated governments). I understand why GMail wouldn't want to support PGP. They read your emails to target ads at you. Without that there would be no GMail. If you encrypt everything you send/receive and GMail cannot read it, then they have no way to monetize it.
- leot 13y ago
  There are two concerns: 1) Security of email messages in transit, assurance that you're receiving emails from the person who claims to be sending them, etc. 2) Preventing your email service provider (and any MITM) from reading your emails. These concerns are relatively independent of each other. While if you're a die-hard PGP advocate you'll want both 1 and 2, PGP-in-Gmail gives us 1, and that's a pretty great start. Right now we have neither, and we're all much poorer for it. PGP-in-Gmail instantly gives it to everyone that has an @gmail account (and anyone else who has signed up to a WoT). It would probably insist that you use two-key authentication. And it would work like this 0) Every message you send is automatically signed by you by default. 1) type in >=1 email addresses in To: bar 2) If all of the email addresses you sign have public keys associated with them that Gmail can locate, they all look "Green" (or whatever) and the [Send] button becomes [Send securely]. 3) If any of the addresses doesn't have a public key associated with it, then nothing is encrypted (i.e., exactly the behavior we have now). If you don't trust Gmail, you shouldn't trust it any less if/when they deploy PGP for it. And no one is saying you have to use it. All I'm saying is that Gmail, Hotmail, etc. seem to be the best equipped to trigger the widespread adoption of PGP.
  - Natanael 13y ago
    > If you don't trust Gmail, you shouldn't trust it any less if/when they deploy PGP for it. The problem here might be that people (including Google, I guess) don't want users to trust anything MORE THAN THEY SHOULD, which is a major risk in a case like this. Sometimes security features can be counterproductive since they can lead to the users making bad assumptions and therefore bad decisions that they otherwise wouldn't have made. PGP in webmail implemented just in JS is likely one of these things that could make things worse due to how users treat them.
    - leot 13y ago
      I'm actually suggesting that if we're going to trust Gmail completely anyway, we might as trust them to encrypt-and-decrypt everything server side. No need for any fancy PGP in JS. Gmail still gets to read your emails and generate ads (though it might not be able to do offline analytics to your emails). The point is that with PGP-in-Gmail we can at least trust that the email in transit is much more secure, and furthermore we can verify the identity of anyone sending us messages, too.

by leot 13y ago

IgorPartola 13y ago

Webmail + PGP really is insecure. The only way to do it properly would be with some OSS plugin + completely separate process for actually reading/writing emails. However, I think we could use a better way to associate emails with PGP keys. For example, my email uses a domain I own. I have HTTPS on my domain, so I can deliver my public key to you securely over the Web. Alternatively, Google could have a service where you securely ask it "what is the key for example@gmail.com" and it responds with the key. Bootstrapping a full WoT is hard, but often times the requirements are much less strict. Most times I just want to know that if I email you that you are the only one that can read the email. I might not even care if you are truly the person you claim to be, as I know you by your email handle more than by your real name (as in emailing Satoshi Nakamoto). Of course having a webmail provider tell others what your public key is means you have to trust your webmail provider not to lie. You also have to trust their delivery mechanism (HTTPS) and the people that issue them their SSL certificates (as we know this can be circumvented by motivated governments). I understand why GMail wouldn't want to support PGP. They read your emails to target ads at you. Without that there would be no GMail. If you encrypt everything you send/receive and GMail cannot read it, then they have no way to monetize it.

leot 13y ago
There are two concerns: 1) Security of email messages in transit, assurance that you're receiving emails from the person who claims to be sending them, etc. 2) Preventing your email service provider (and any MITM) from reading your emails. These concerns are relatively independent of each other. While if you're a die-hard PGP advocate you'll want both 1 and 2, PGP-in-Gmail gives us 1, and that's a pretty great start. Right now we have neither, and we're all much poorer for it. PGP-in-Gmail instantly gives it to everyone that has an @gmail account (and anyone else who has signed up to a WoT). It would probably insist that you use two-key authentication. And it would work like this 0) Every message you send is automatically signed by you by default. 1) type in >=1 email addresses in To: bar 2) If all of the email addresses you sign have public keys associated with them that Gmail can locate, they all look "Green" (or whatever) and the [Send] button becomes [Send securely]. 3) If any of the addresses doesn't have a public key associated with it, then nothing is encrypted (i.e., exactly the behavior we have now). If you don't trust Gmail, you shouldn't trust it any less if/when they deploy PGP for it. And no one is saying you have to use it. All I'm saying is that Gmail, Hotmail, etc. seem to be the best equipped to trigger the widespread adoption of PGP.
- Natanael 13y ago
  > If you don't trust Gmail, you shouldn't trust it any less if/when they deploy PGP for it. The problem here might be that people (including Google, I guess) don't want users to trust anything MORE THAN THEY SHOULD, which is a major risk in a case like this. Sometimes security features can be counterproductive since they can lead to the users making bad assumptions and therefore bad decisions that they otherwise wouldn't have made. PGP in webmail implemented just in JS is likely one of these things that could make things worse due to how users treat them.
  - leot 13y ago
    I'm actually suggesting that if we're going to trust Gmail completely anyway, we might as trust them to encrypt-and-decrypt everything server side. No need for any fancy PGP in JS. Gmail still gets to read your emails and generate ads (though it might not be able to do offline analytics to your emails). The point is that with PGP-in-Gmail we can at least trust that the email in transit is much more secure, and furthermore we can verify the identity of anyone sending us messages, too.