Live data from Hacker News

Facebook and PGP

cs.columbia.edu

51–60 of 60 posts

Re: Facebook and PGP

#51
post #2

Another possibility is one of their programmers thought "It would be good if there was more encrypted e-mail going around in general, I wonder if I can get it into facebook somehow" and coded this feature in their free time. Then convinced his managers to integrate it with that argument plus "and it's already coded we just need to merge it in"

"and it's already coded we just need to merge it in" Any manager worth their salt will know that maintaining code is 10x more expensive than building it in the first place, and if it's user-facing code you're even adding an implicit promise that the feature isn't going to be removed again. I strongly doubt the "oh but it would be so hard to build that" argument counts for much. That said, I've no idea about what kind…

Well, it's possible that "move fast and break things" is more than just hot air. :)

Re: Facebook and PGP

#52
post #11
post #2

Another possibility is one of their programmers thought "It would be good if there was more encrypted e-mail going around in general, I wonder if I can get it into facebook somehow" and coded this feature in their free time. Then convinced his managers to integrate it with that argument plus "and it's already coded we just need to merge it in"

Well, from what I know there are some seriously privacy minded people in there. As oxymoronic as that sounds. But I could certainly see some benefits both for FB and for world at large from this. One of the big problems with PGP is how to bootstrap web of trust. "Does this key really belong to this particular person?" But what if the otherwise loathed real name policy could be turned to service this particular need?…

Have you heard of keybase.io?

They don't do Facebook, but you can tie a PGP key to various other public identities (Twitter, GitHub, HN, Reddit, etc.)

Re: Facebook and PGP

#54

To me the strangest thing about this announcement is that, while the PGP user base is small, I imagine its intersection with Facebook's is much, much smaller. PGP is used by people who are extremely concerned with privacy, which is practically the antithesis of Facebook.

It'd be interesting if Facebook let ads be targeted at people with PGP keys.

Re: Facebook and PGP

#55
post #48
post #26

Earlier quoted context omitted.

> But what if the otherwise loathed real name policy could > be turned to service this particular need? The link between a real person and a Facebook account isn't secure - I could make an account with your name today without too much stress (no need to provide ID unless Facebook thinks your name isn't a real name).

I think the grandparent chose the wrong end of the stick with relating this to "famous" people, which, in turn, threw you off. Sure, you can register an account in my name, but there are quite a number of people who will not be fooled: people who actually know me. People who know me in real life can tell whether an account is real or not, because they can tell whether I post about things I do, whether I post pictures…

Yes, I deliberately chose the term "prominently visible" and not "celebrity". The context is different with PGP.

Maybe I should have used high-profile as the specifier in that sentence too.

Re: Facebook and PGP

#56
post #52
post #11

Earlier quoted context omitted.

Well, from what I know there are some seriously privacy minded people in there. As oxymoronic as that sounds. But I could certainly see some benefits both for FB and for world at large from this. One of the big problems with PGP is how to bootstrap web of trust. "Does this key really belong to this particular person?" But what if the otherwise loathed real name policy could be turned to service this particular need?…

Have you heard of keybase.io? They don't do Facebook, but you can tie a PGP key to various other public identities (Twitter, GitHub, HN, Reddit, etc.)

I had heard about them but never had taken a good look. Now I did and choose not to deal with them. Some quotes from their website:

> certain crypto actions (signing and decrypting) are limited to users who store client-encrypted copies of their private keys on the server

No. Especially combined with the next one:

> On the website, all crypto is performed in JavaScript, in your browser. Some people have strong feelings about this, for good reason.

The second sentence sums it all up.

I think the service has been made with good intentions, but the pavement on the road to Hell...

Re: Facebook and PGP

#57

To me the strangest thing about this announcement is that, while the PGP user base is small, I imagine its intersection with Facebook's is much, much smaller. PGP is used by people who are extremely concerned with privacy, which is practically the antithesis of Facebook.

PGP is still useful for signing and verification of identity which is what Facebook is about (the whole real name fiasco).

Re: Facebook and PGP

#58
post #30
post #20

Earlier quoted context omitted.

S/MIME has very little adoption - the kind of people who care about encrypting their email are usually the same kind of people who don't trust the CA system.

That's not true: https://gist.github.com/rmoriz/5945400

Probably it's "S/MIME has very little adoption, outside of the corporate / enterprise market.."

Getting keys sign by CA is just as bad (or even worse -- you have to generate and then have that key signed by CA) than generating a key on OpenPGP scheme, and then there's the issue of cost. (Although I've seen some free ones out there.)

Re: Facebook and PGP

#59
post #56
post #52

Earlier quoted context omitted.

Have you heard of keybase.io? They don't do Facebook, but you can tie a PGP key to various other public identities (Twitter, GitHub, HN, Reddit, etc.)

I had heard about them but never had taken a good look. Now I did and choose not to deal with them. Some quotes from their website: > certain crypto actions (signing and decrypting) are limited to users who store client-encrypted copies of their private keys on the server No. Especially combined with the next one: > On the website, all crypto is performed in JavaScript, in your browser. Some people have strong feelin…

The keybase CLI allows you to keep the private keys offline on a machine of your choice, and does the crypto the "standard way" (shelling out to gpg):

https://keybase.io/docs/command_line

Re: Facebook and PGP

#60
post #30

Earlier quoted context omitted.

That's not true: https://gist.github.com/rmoriz/5945400

Probably it's "S/MIME has very little adoption, outside of the corporate / enterprise market.." Getting keys sign by CA is just as bad (or even worse -- you have to generate and then have that key signed by CA) than generating a key on OpenPGP scheme, and then there's the issue of cost. (Although I've seen some free ones out there.)

No, it's not. WoSign, StartSSL and iirc Comodo create the private key in your browser. This functionality is afaik around since Netscape's first SSL-enabled browser and originally intended for client-side-certificates. Today it's implemened using the tag [0].

This usually means, that you press a button in your browser, the Browser generates public+private key, stores them in your Keychain (OSX for example), sends the public key to the CA and the CA mails you the certificate.

It's really done in seconds and for Mail.app or iOS mail you just need to enable S/MIME and sign/encrypt. There are many tutorials out there for various MUA. Except of Android nearly every popular MUA can speak S/MIME including Outlook, Thunderbird… [1] and many tutorials are out there [2].

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke...

[1] https://gist.github.com/rmoriz/5945400#file-1_smime-clients-...

[2] http://kb.mozillazine.org/Getting_an_SMIME_certificate

Post reply on HN