Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, I haven't used PGP extensively, but my reasons for not doing so (as probably with everyone else) have had to do with the fact that no one else uses it and it hasn't been cleanly incorporated into existing online identity frameworks.

I'm imagining that the webmail providers could implement it piecemeal, and though I'm speculating here, I think this slightly-less-secure-than-complete-PGP approach would address a lot of the problems you're referring to (I'd be eager to hear why you disagree, though!). Corner cases should only be a problem if the approach is all-or-none, right? And if done properly, a piecemeal PGP implementation would still be more secure than no implementation at all.

From the user's/your-mom's perspective:

a) conversation threads would be kept separate from each other depending on whether or not they were secure

b) some messages would be signed, explaining what is known about the sender and why (e.g. "this message has been verified as originating from xx@gg.com", or "message is known to have come from John Smith at 2nd National Bank, with email address xx@gg.com", or even "John Smith, with the following verified profile".

c) some messages would be encrypted, telling the user "this message was securely sent to you, and person X, and person Y, by xx@gg.com."

d) when a user sends a message it would default to the most secure mechanism that all of the conversation participants allow, given what it knows about the recipient

Even if Gmail was the only provider that implemented this, especially given two-factor authentication, users would immediately get secure conversations at least in conversations that included only other Gmail users, which would go a long way to dealing with the fact that it's the lack of other people using PGP that makes adopting PGP kind of pointless.

Given that Google provides webmail to many universities and businesses, implementing PGP would immediately turn on secure and verified communication within those organizations: the benefits of PGP there would be instant and enormous: identity verification, timestamps, and signatures are the only reasons people still shuffle paper around. No more clumsy and expensive university-stamped transcripts; no more running around trying to find people to get their signature; no more running signed documents between various offices, etc.

Furthermore, your mom might already use Facebook (or another social website) and if so is already experiencing the benefits of verified identity and higher-trust communication. On fb you have absolute confidence that you're actually posting to friend X's wall; and when you're messaged by friend X you're absolutely sure it's X (unless someone gained access to X's account). This implies that similar such UI-based cues could be used for webmail, no?

Indeed, one could characterize part of the success of facebook (and other social networks) in terms of identity verification: you know that information posted by person X has actually been posted by person X (vulnerabilities notwithstanding); you know that what you post will not be seen by people whom you don't want to see it; you know when person X posts on your wall that it was actually the X-that-you-know and not some other one or a fraud; you know by virtue of X's existing relationships to your other friends that it's the X-you-know rather than someone else.

Ultimately, I think Google hasn't implemented PGP, in spite of all the incredible benefits, because it doesn't want to encourage its users to be more private. Is this evil?

tl;dr partial PGP implementation on webmail would avoid corner case problems while providing huge benefits to millions of people and organizations



If you can't even explain what the system would appear to do from a user's perspective in less than (hold a sec...) 11 paragraphs, I don't think you get to call Google "evil" for not doing it.


it would just do a,b,c,d -- the rest was meta




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: