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…
Facebook and PGP
51–60 of 60 posts
Re: Facebook and PGP
#52Another 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?…
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
#53Private public keys + verification gives way to lots of uses... Payments (bitcoin style currencies), banking, document signitures, and single sign-on?
Re: Facebook and PGP
#54To 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.
Re: Facebook and PGP
#55Earlier 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…
Maybe I should have used high-profile as the specifier in that sentence too.
Re: Facebook and PGP
#56Earlier 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.)
> 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
#57To 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.
Re: Facebook and PGP
#58Earlier 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
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
#59Earlier 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…
Re: Facebook and PGP
#60Earlier 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.)
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-...