I applaud the sentiment but really wish we had something which wasn't a UX disaster. I tried to set this up on a Mac, which is what this looks like for someone who first started using PGP in the mid-90s:
GPG Tools seems to be popular and has Mail.app integration. It loads, shows the secret key as valid in the GPG Keyring app, but any attempt to decrypt a message fails with “Secret key to decrypt the message is missing”. No diagnostic information is provided.
Okay, I'll pretend it's still 1995 and run it on the command-line. "pbpaste | gpg --decrypt" needs a password, so I naively attempt to setup gpg-agent so I don't need to keep pulling my 30-character password from my password manager. "brew install gpg-agent" and it quickly turns out that it's just broken: pinentry doesn't get stdin for some reason and chews 100% CPU printing * as quickly as possible.
So much for saving time in the future; let's just see if we can open one message. Save it to a temp file, run it through gpg --decrypt and … it's HTML so the URL needs to be unescaped, so make that "gpg --decrypt encrypted.asc | urlview".
Open that URL and get … a server error from Facebook.
Hi Chris. I worked on this and want to diagnose your server error.
When you decrypted from the command line, did you notice the plaintext blob preceding the HTML message content? Look for "Content-Type: text/plain;" and see if there is an unmodified verification URL there.
You might have only noticed the HTML one, which will be a pain to cut & paste. If it's still broken, please contact me.
Incidentally, I've been using both GPGTools/Mail.app and Gmail/Mailvelope without trouble. The latter doesn't open clicked links in a new tab, though. I've had to "Copy as" and paste in another tab.
The regex which urlview uses includes the final bracket, which causes the error. Once I removed it, I successfully validated the key.
It'd probably be best to put the URL on its own line but if not, RFC 2396 recommends using angle brackets – see “Recommendations for Delimiting URI in Context” in http://www.ietf.org/rfc/rfc2396.txt.
I just went through and installed GPGTools for mac mail, and installed the key into facebook with no issues. (Well I copied just the 'random' set of numbers and the fb site told me to include a bit more of the header/footer of the key ). ]
It all seems to work (perhaps they fixed the issue?)
... the challenge now is how will my email come through on iOS!? Any recommendations for that? I saw https://ipgmail.com/
Yes, that's the point with all software. Everyone would love not ever getting errors and issues. But, just like with all other software out there, there will inevitably be bugs and corner cases which have to be diagnosed. I'd prefer someone from the product team actually caring about this and helping out rather than no support offered whatsoever, which is closer to the norm for big companies.
Show me software that has been released with 0 bugs. This is part of what makes the HN community so great, being able to interact with real people who work on the topics being discussed.
This is such a typical HN negative comment. Obviously the point is for there to be no bugs - any other extremely obvious things you would like to state?
People post things on here and simply get attacked, even if they're trying to do good and improve like OP for this thread is. It's people like you who drive others away from this site through your constant "this sucks, that sucks" mindset.
OP's comment is intended to tell us that This Shit Is Broken for him, and clearly for other users as well. OP is not requesting tech support. As nice as sweis is for offering support, he fails to acknowledge that solutions such as this one are simply not ready for most users from a UX perspective.
Reinforcing this point to sweis is not a negative comment. It is a comment you do not like. There is a difference.
It is the first day of availability of this service, so it might be possible to find ways to improve its reliability and usefulness, even if you're kind of skeptical of PGP's design overall.
Installing GPG Tools on Mac sets up gpg-agent automatically and has Mac Keychain support. I use the agent support all the time for signing Maven artifacts (which requires password-less entry due to the way the release plugin works).
Indeed – and yet it still doesn't work. I'm sure that it could be made to work with enough debugging, having done so multiple times over the years, but this needs to work better by default. Security software in particular needs to inspire trust to avoid incentivizing everyone not to use it.
This isn't yet at S/MIME levels, much less something like iMessage or Signal/TextSecure – and, yes, there's a ton of room to argue their respective merits but most users are simply going to switch to something which gets their message through rather than debug failures, particularly when the software doesn't give any feedback about what's wrong and, critically, what you could do to fix it.
I get what you're saying, but it took me literally less than 5 minutes to configure this on my MacBook Pro running Yosemite and the latest GPG Tools.
To copy your public key to the clipboard where it can be pasted into your Facebook profile, just do this from the command line:
gpg --export --armor bob@example.com | pbcopy
A short time later, I received a signed and encrypted email message from Facebook. The whole thing went surprisingly smoothly; it gives me hope that using OpenGPG won’t solely belong to the neckbeard crowd and that Twitter, Google+ and other social media platforms will follow suit.
I also love the subversive nature of this; regardless of how the Patriot Act legislation turns out, Facebook is now providing email that only the recipient’s private key can decrypt and that nobody else can read.
> I get what you're saying, but it took me literally less than 5 minutes to configure this on my MacBook Pro running Yosemite and the latest GPG Tools.
That's the same config I used as well. I used the same export as you but I could have used the GPG Keyring for that step – it's only the mail integration or gpg-agent which fail, unfortunately without any explanation.
That was my real point: I can use everything from the command-line, just like the first time I used PGP in 1993, but for this to catch on the integration needs to be both seamless and reliable. All but the most dedicated privacy / security activists handle failures by disabling the crypto software.
That's been the rule since the 90s: I've seen a bunch of people use PGP/GPG or S/MIME for a few weeks and then give up when they hit a problem and realized that nobody else actually noticed or, in the case of mailing lists, that people using crypto-aware clients couldn't read legitimate messages but everyone else could.
Exceedingly few people care that the software is working correctly when the experience is unpleasant and that's really what needs to change to see popular update. People love iMessage and that's because they're confronted with the always-on strong encryption breaking the experience. It'd be harder to hit that with a decentralized, cross-platform system but that's what we should be shooting for.
I set up my first PGP key in 1998, and I have as yet never received a PGPed email from anybody except myself. So it's exciting that I might finally do so.
I use GPG/PGP to sign my mails, using PGP/Mime, not inline PGP, which creates an ugly mail header that will confuse many readers. My mail has a signature.asc file, and sometimes I get a question about this. Then I explain. The most surprising about this is that most people don't ask anything. Maybe they figure it out, but I doubt that. I do this to introduce the concept to other people.
I sign emails too, for the same reason. I got the most different reactions, up to "Careful, you have a virus that put a lot of strange characters in your email".
Do you have a standard text you use to explain what it is? I confess, I planned to write it, but it's still on my to-do list…
Provides a good overview of PGP/GPG, and more or less gives enough instruction that someone could set it up on their own provided they were more technically inclined. Either way, if they were interested, this would be a good enough starting point I think.
I know those feels; I had an old PGP key (private key and passphrase now both lost) linked to my old AOL account (long gone, of course) using my old surname (been married eleven years now), but registered with the MIT server back in 1997, so it's still visible to the world. It's like a digital version of some mysterious, unopenable time capsule.
For this reason, I've learned to encrypt my first-ever email keys (from 2013 -- hey, I'm young) into an encrypted disk image that I can mount from any computer sync'd on the cloud.
I have only ever sent one encrypted email, but that was by accident. Turns out Thunderbird + enigmail will default to encrypt the email if you have your recipients key.
Besides the obvious "why care about security when Facebook has your data", this is a very positive move.
One thing is giving your data to companies and another one is living on a country where there is not free speech, your beliefs/lifestyle/genetics are illegal, etc. More encryption is always a good thing.
By the way, the article links to an official FB Onion site. Neat!
> "why care about security when Facebook has your data"
(not specifically responding to you, just a general response)
Facebook and the NSA aren't the only threats to protect yourself from. Improvements to security aren't bad just because they aren't absolute 100% solutions.
This could be an attempt to correlate gpg keys to facebook accounts. Also, make sure you're verifying the key out of band after you've pulled it from facebook. /paranoia
So what, gpg keys are unlimited resource. Just generate new ones whenever required. I've been using that strategy. Just like you don't want to reuse your password everywhere. If you don't want to be anonymous anymore, you can sign nonce with your official and with your temporary key. Some seem to claim that OpenPGP doesn't support ephemeral keys, but it does. You just need to generate new keys and use those, when ever you want/need to.
This is likely an attempt by motivated individuals inside an unstructured place like Facebook to get a feature they want out to the public, and less driven by some PM who wants to compete with others.
I'm the engineer mentioned here. Its nice people actually remember my startup. :)
Facebook is definitely a place that lets engineers run with ideas, and it is that environment that allowed us build this out as something engineer created, designed, and driven.
I will acknowledge the PMs on the relevant product teams were all great to work with at the points they became involved and understood the problem we were hoping to solve here.
I was wondering if facebook wanted to hide more of their users activity from competitors. I know a lot of my friends get all notifications (or used to) as emails and auto archive those, essentially giving google insights into their entire Facebook presence. Something Facebook obviously don't want to give away.
Your theory seems much more likely, given the probable adoption of this feature :)
As people have said in this thread, one instant advantage of this is an anti-phishing measure. Not only can you verify mails from Facebook, but they can send you password reset links to click on and know that your email account has probably not been compromised.
Compromise or loss of the PGP key remains an ongoing problem. Maybe we could persuade Apple to add PGP functionality to their secure co-processor.
What more or less sunk PGP for me was gmail. The various gpg-in-chrome plugins I've tried have been pretty uniformly terrible (including Google's own end-to-end), so the standard web interface is out.
And unfortunately, by allowing me to store so much mail (~7.5GB at the moment), gmail has made it effectively impossible to use any other IMAP client – I've left Mail.app and Thunderbird running for days trying to do their initial sync, to no avail. The only client that actually works with the amount of mail I have, and has PGP support, is mutt, and even that takes ~5 minutes to read in its header index on startup.
The end result is I pretty much just don't use PGP unless someone sends me something encrypted (which does happen! But probably this is just because I work in security), and then I break out mutt and resign myself to waiting around a bit for things to load.
Use offlineimap. It's slow, but I built this [1] to watch my Gmail mailbox and launch a sync whenever a new mail arrives so I don't have to wait and I don't have to poll. After that you can use mutt with the maildir you have locally. Bonus: you get to backup your mails.
I use sup (https://github.com/sup-heliotrope/sup/) as a MUA to manage my mail, with the gpgpme gem [2] I can use gpg almost flawlessy (but I'm biased, I help maintain it :)
There is an option to fetch only last some number of E-mail through IMAP, but then you can't back log so it defeats the purpose of fetching E-mail this way. (and for the same reason, I moved from Thunderbird to Gnus.)
From my experience, it seems to be just about any MUA on any platforms will start choking when it starts getting around 2GB to 3GB -- not only fetching takes forever, but also makes it very unresponsive. We have a few people here using Outlook with Google for Work, and I had to set it up to limit fetching and tell them to go on to mail from a browser for older E-mails as it'll start doing weird stuff when it hits a certain threshold.
Disclaimer: this was about a year ago, so some things may have changed. Specific comments mainly apply to Google's own end-to-end, since that's the one I remember best.
In general, they tended to not mesh well with the gmail UI – you could decrypt, but the decrypted message would pop up in a new window. And sometimes it just wouldn't detect that a message was encrypted, so you'd have to select the encrypted text, find the context menu for it, etc. Composing was also more difficult than it needed to be – another extra set of steps to remember before hitting send, rather than something that would be triggered automatically if the recipient was in my keyring.
Basically, the functionality offered usually ended up not being much better than selecting the message, opening a terminal, and doing `pbpaste | gpg --decrypt` (or --encrypt on the way out).
This sounds like it's more about keeping Facebook data out of Google's hands. They must leak a lot of information about who did what on Facebook to them through notifications ending up in Gmail accounts? Does that impact either party in a significant way? Just a thought.
How is this security theater? It's providing an actual, useful service for those who choose to use it. If the majority of people choose not to, then the fault would lie primarily on the end user, not on Facebook.
Indeed. It's not theater - this really is more secure than before. It's just got painful usability. However that is not Facebook's fault: the security community has failed to produce any end-to-end encrypted email product that is easy to use.
The good news is:
a) This continues the momentum that the big Valley companies are creating around strong crypto
b) This will motivate people to build better replacements for PGP, because now they know that they might actually receive encrypted emails if they can get sweis and others at Facebook on board.
S/MIME would have been slightly better, IMO, but I understand why they didn't do it that way - Yahoo and Google are working on OpenPGP browser extensions, and "copy/paste your key" is easier than "upload your certificate".
We badly need a modern, fresh take on email end-to-end crypto.
If people trust other mail providers, which most do in general, why would they use this?
Maybe facebook has some numbers on how many users distrust other major mail providers to the extent to use this, while also trusting facebook.
At least to me, that sounds ridiculous.
Because along the measures of distrustfulness of who allows information to propagate to third parties (some third parties more privileged than others…), I don't particularly see any major mail provider above and beyond any other major players…
Considering that most people wont even know what GPG/PGP are, this seems like an exercise in "Don't trust others, but trust me" and the user is supposed to go like "Welp, ok!"? Haha.
No, it's more an exercise in "Don't trust anyone else, trust this proven, well-known (in the tech world) encryption" which is markedly different than "Don't trust others, trust me". PGP doesn't give you confidence in the source, nor should it. It just gives you confidence on the transmission.
Now if we could get the public more aware of it, then that'd be great. :)
In any case, this isn't security theater. There's nothing theatrical about this. This is a real security benefit that has newly been added. Lots of things can be said about PGP in general, sure, but the ability to encrypt the messages from Facebook so that only you can read them is an actual security benefit. The entire concept of "security theater" is something that looks like it increases security but does nothing. By sheer fact that encrypting communications increases security, it can't be security theater.
"…ability to encrypt the messages from Facebook so that only you can read them is an actual security benefit."
Except it isn't really "only you", its whoever else has access to the key or keys facebook uses to encrypt such messages and if one distrusts other mail providers that they use to such degree, but trusts facebook, I'd really start question what threat model they are contriving…
> Except it isn't really "only you", its whoever else has access to the key or keys facebook uses to encrypt such messages…
No, you are giving FB the public key, and keeping the private key. So anyone with the (public) key you give Facebook could send you messages that you can decrypt with the private key (which is why FB also lets you publish the key on your profile page), but could not read the messages sent by someone else with the same key.
Only you -- or someone else with the private key that you don't give to Facebook -- can read the messages. Of course, if someone breaks PGP so that they can use one half of the key pair to recover the other half, they could read the message just by knowing the key you share with Facebook ... but that that is intractable is the whole foundation of public key cryptography.
So setting side the intractable nature of the key issue, there is also the issue of who has access to the plaintext… if you trust facebook with the plaintext are you also trusting that plaintext is not available to other parties?
Uh, its the plaintext of notifications sent by Facebook, to you.
If you don't trust Facebook with the plaintext of those, you probably shouldn't have a Facebook account.
This is a means of preventing interception by third-parties not intended to have access by either of the parties to the transaction. Its kind of an orthogonal concern to the degree of trust one has in the other party, though I suppose if one sufficiently distrusts the other party, the risk of accidental interception becomes negligible compared to the risk of intentional disclosure by the other party. But if the trust is that bad, why would you even voluntarily have relationship with that party?
>But if the trust is that bad, why would you even voluntarily have relationship with that party?
Good question, but It's probably best for those who trust facebook, and complain about parties that have a carte blanche to subvert such security of interception (like government actors and civilian contractors but most don't complain about the contractors) like the crowds do on HN from time to time. I ask that question to myself when I see such complaints being raised…
Sure, but that plaintext would have been available to not only the same, but more parties pre-encryption. Because anyone in between Facebook and your mail provider, your mail provider, and anyone in between your mail provider and you would all be susceptible to some form of interception. Now, it's limited to just those on Facebook's side. And that would be covered by a Privacy Policy and potentially the Terms of Service.
Also, how is it "intractable" exactly? If you keep your key safe, you keep your key safe. If you give your private key to anyone and everyone, then it's on you if someone else reads your stuff. There's nothing inherently intractable about this. Either you're good with informational security or you aren't. Facebook has absolutely nothing to do with it.
>Because anyone in between Facebook and your mail provider, your mail provider, and anyone in between your mail provider and you would all be susceptible to some form of interception.
So now that part of the puzzle has been addressed by facebook without the acknowledgement of the rest, people are suppose to just set this aside?
>…And that would be covered by a Privacy Policy and potentially the Terms of Service.
So a technical implementation with its foundation on a social contract that has and can change at any time is to be trusted…
The parent mentioned:
"Of course, if someone breaks PGP so that they can use one half of the key pair to recover the other half, they could read the message just by knowing the key you share with Facebook ... but that that is intractable is the whole foundation of public key cryptography."
Which I decided to set aside since between the user and privcy policy/tos, are the ones that seem to be the weak points that are often exploited in practice that subverts "security".
This is a thread about Facebook adding the ability to encrypt their notifications for you. While all those may be valid arguments, and are certainly worth discussions, this is neither the time nor the place for it. As I said before, there could be many arguments made against a whole number of things, but none of them are on topic. In terms of this one specific feature Facebook added, it's a net security positive, and not theater, as we have shown you several times over the course of this constantly-offtopic thread.
To answer your question bluntly, people are supposed to just set this aside here, yes. Because all those things are not at all even remotely related to the topic at hand. If you have concerns about PGP, there's plenty of security-oriented forums you can take those problems to to have them analyzed by actual security experts who would be able to provide much more information about it than we could. If you have concerns about Facebook's policies, then I'm sure there's legal forums and other Facebook-related discussions which would more closely match those concerns. If you have concerns about Facebook itself, well, perhaps you shouldn't be on it in the first place. But regardless, this topic is not the appropriate place for any of these conversations because none of them are about the encryption of notifications from Facebook to you.
So what if one has questions that span the dimensions of GPG/PGP in practice/ facebook's policies and facebook itself relative to other parties it says its securing one from (of which has been vaguely defined)?
To call this one specific feature a net security positive while being willing to silence all else (out side of empty nods to such) that is related to the encryption process for the sake of giving a pat on the back it seems, doesn't inspire much confidence…
> So a technical implementation with its foundation on a social contract that has and can change at any time is to be trusted…
No, the "social contract" at issue deals with a different set of concerns than the "technical solution".
The "technical solution" addresses the issue of providing a mechanism to prevent the data sent from Facebook to you being exposed to third parties without you or Facebook intending that exposure.
The "social contract" addresses limits on intentional sharing by Facebook of data related to you (which overlaps with some of the information in the communications protected by the technical solution.)
The former is not the foundation for the latter, they address distinct, though related, issues.
IIRC (and correct me if I'm wrong, I haven't used PGP extensively), but Facebook wouldn't be able to decrypt a message they encrypt to you. They'd only be able to if they had your private key (since the message is encrypted using their private and your public key). That's the whole thing about PGP, if someone were to get ahold of a private key, they'd only be able to decrypt everything sent to that person, not sent from.
So really, the only one at fault for someone else reading the message would be the key owner, who's responsibility it would be to store that safely. And once again, we ask, how is this "theater"? Everything points to it being a net positive security wise. If you want to debate PGP, or the usefulness of encryption, then I'm sure there's plenty of forums for that. But in terms of the actual feature that Facebook just implemented, it's a security gain as before we had nothing, and, by definition, can't be called a security theater.
Wonderful! I don't use Facebook that much, but I hope this helps make PGP more popular among users and services. In particular, I am hoping for banks to start PGP encrypting the reports they send to me via email.
I tried using PGP in Thunderbird on Linux. It was a pain. E-mails suddenly didn't format properly, and I got weird error messages at unexpected moments.
We need better user-agents for dealing with encrypted email.
You may be failing to start gpg-agent properly. Are you exporting GPG_AGENT_INFO? What does it say?
I noticed this was somewhat of a sore spot for people when Enigmail started forcing gpg2 instead of letting the user choose. I don't disagree with forcing gpg2, but there were definitely some configuration changes that needed to be made on my system to cope with / reflect that choice.
That's a great move, and Facebook deserves props for this. Not only for making it easy for people to disseminate keys, or for making it hard for my email provider to read my email, but for also eliminating phishing. Now my email client will show me beyond a shadow of a doubt that a given email was sent by Facebook.
Totally agree. Going off of this, it would be kind of neat if they started signing all outgoing email by default, regardless of whether the recipient has uploaded their public key for encryption.
Surprised that nobody has generated a private key with a UID containing an abusive or self promoting real name/comment, signed Facebooks key with it and uploaded the signature to the keyservers yet. Tempted to sign it with a key with a real name of:
The funny state of Facebook: the research side pushing for more privacy by promoting Tor/PGP, and the official side requiring you to upload your government ID if you want to keep your account. (see #MyNameIs)
One existing problem is that email encryption is so unusual it stands out and can arouse suspicion to some people. I'd just like to encrypt to protect my privacy but "why encrypt if you've nothing to hide?"
The more mundane email traffic like this is encrypted, the less encryption will be equated with suspicious activity.
Email provider, overbearing parents, abusive spouse, scriptkiddie who's just phished your email password...
It's only a small "win" for privacy - given that Zuckerberg is on the other unencrypted end of anything "private" this might send, but I can see it as an important win for a few people...
Of course, perhaps this is part of a cooperative or NSLed collaboration with the NSA, "Hey Zuckerberg! We need you to tell us which of your users knows how to use PGP, then give us their entire social graph, the social graph of everybody who's ever uploaded a photo with them in it, the locations of those photos, and any Facebook-javascript-bugged webpages they've ever visited. Thanks."
But it does nothing to hide that it is a facebook notification or that it is from facebook because the envelope information is still unencrypted. So the 'From' address and subject are still in the clear, which doesn't prevent overbearing parents and abusive spouses from knowing you received a notification - only from reading the contents of that notification.
Hi. We use a generic subject line "Encrypted Notification from Facebook" and tried to remove fields that leak metadata. The From: field should just say "Facebook".
Please contact me if you do see anything leaking metadata about the plaintext email.
The parent to my post mentioned that this was a win for people with "overbearing parents" or an "abusive spouse". My response is that the message From field still says that this message is from Facebook, and the subject line apparently says "Encrypted Notification from Facebook". So this is not really a win for someone with overbearing parents or abusive spouses because sufficiently overbearing or abusive people will be on the lookout for any communication from Facebook and will assume the mere fact that the message is encrypted is a sign that it's something they would disapprove of.
That is no way meant to say that the feature is useless, rather that the parent to my post is mistaken about who this feature is useful for. More useful would be an option to have the notification message come from somewhere innocuous - to otherwise make it look like spam. If it did, the PGP encryption would allow the recipient to pick it out of the spam and make sense of it while not alerting others to the fact that it's a message from Facebook.
Even in your scenario, I can see some utility. A paren or spouse who has your email password still can't reset your Facebook password without your PGP keyphrase password as well. That's perhaps not a significant additional barrier, but at least it's a much less commonly used password/phrase than your email account...
Again, the big problem for abuse victims is getting the shellac beat out of them for disobeying their abuser. This encryption does nothing to enable an abuse victim to switch on notifications as the (now grand-)parent post I was responding to was insinuating - abusers on that level don't care what the message says. They are going to interpret any message they can't read as a message that goes against 'their rules'.
Yeah but there is a hell of a difference between seeing that you have received a friend request and seeing that you have received a friend request from an agency that helps victims of domestic abuse.
The first is pretty innocent, the other could get you killed.
If someone is suffiently abusive and paranoid then the distinction is meaningless - they will assume that any notification they can't read is one they don't approve of, and somebody in that situation wouldn't benefit from encrypted notifications. They likely wouldn't have notifications on at all, so encrypting them doesn't make them safe to use in this situation.
That doesn't make encrypted notifications useless in general or otherwise bad, but it's an oversell to say this makes them useful for abuse victims. In fact, selling it that way is dangerous given a sufficiently abusive and motivated adversary as it's false security.
Sure - but we (or Facebook) need to weigh up whether doing this which may (or may not) help in some cases is of greater benefit than not doing this because in some "sufficiently abusive" cases it won't work (or may even me harmful). My gut feel is that it's a good thing, and that the benefits against "snooping grade" abuse is positive and way more common than the potential downside in "sufficiently abusive" cases. It's not a requirement that Facebook fix everything to "worst case abuser" standards before providing additional features or utility to other users of their site. (Lets face it, if your postulated "sufficiently abusive adversary" is the threat model, you've got bigger problems to solve than securing your Facebook account - and Facebook can't help you with those in general...)
It's a good thing. If the take-away from my post was that it wasn't then I'm sorry for not conveying that more up front.
Again, I'm responding to the grand-parent post that said this would be good for abuse victims. It's not all that great, but that doesn't mean it's useless.
The cynic in me believes that both this and the official onion sites are baits to lure in those who typically care about privacy and thus don't want to use Facebook. By doing this Facebook allows them to gradually extend their medium of communication to FB, and thus gather more information on them.
People who care about privacy enough to stay away from Facebook in the past are going to know enough about privacy, I hope, that they'll continue to stay away in the future.
If this truly is Facebook's intention, I somehow doubt it'll be very successful. I'd like to think it'll encourage more people to start encrypting and signing their emails, although somehow I doubt that as well.
I would guess that it will help (eventually) with email deliverability: phishing emails claiming to be from Facebook wouldn't have valid signatures. Yes, DKIM and other stuff already partly does this, but signed emails are much harder to forge!
Signed (and unencrypted) mails are vulnerable to known-plaintext attacks; in other words, it is possible (although not always feasible) to alter their content yet retain a valid signature.
How about S/MIME? Most mail clients offer out-of-the-box support, including iOS. No additional software required. Requesting a free certificate from Comodo with a web browser is much easier than grokking PGP.
But then exporting your private key and importing it on iOS ... Still a UX disaster, unfortunately.
pool.sks-keyservers.net is a round-robin pool pointing to several dozen synchronized keyservers (including the MIT server). It's usually the default option for most PGP clients. See https://sks-keyservers.net/
There is absolutely zero reason to trust Facebook. Facebook is essentially a self-maintained government dossier on everyone that uses it and doesn't take adequate precautions. Who would have thought that in the future, 1985 would look more like people reporting everything they do and say and think to the government surveillance state rather than the government actually having to put any kind of effort into actually acquiring that information.
Ok, Facebook is a modern version of the Stasi, but it's still good that third parties can't snoop on my interactions with them. I don't see any reason to feel bad about this specific measure.
Hi, engineer who worked on this here. Would you mind linking me to your key, including the version line, and letting me know the error message is? I'll try to see what the issue is.
The key you linked to seems to have invalid CRC bytes at the end of its ASCII armor - this is why we can't accept it, as it's malformed. http://imgur.com/J1bp73V
This might be mostly useless, but at the very least it will increase the volume of PGP-secured email floating around in the world. It will make encrypted email more common, and therefore less of a red flag for security services.
There's perhaps the risk of it becoming the major anchor in the web of trust. That said, you're probably right with respect to the other keyservers being no better.
Precisely why they should be adopting Google's End-to-End system. Yahoo is already supporting it. Also it would be better if everyone went with the same (solid) standard than doing their own thing.
I've started signing (not encrypt) every email I send, even to my friends and professors. The cost of this is that they see the ugly block of a signature. I hope to raise awareness.
Not sure what you mean, but good encryption algorithms (including GPG's RSA and DSA) are not vulnerable to known-plaintext attacks. Even if you know the plaintext and the cryptotext shouldn't help you in cracking the key in any way.
Generate one. Which OS are you on? Look up for a tutorial, you'll certainly find a good one.
Edit: you either have to install GPGTools (for OS X, https://gpgtools.org/), GPG4Win (https://gpg4win.org) Windows, or gpg for linux. To use GPG in Thunderbird you'll also need Enigmail.
No security measure will 100% prevent attacks; any security measure is about increasing the cost to attackers. Forcing attackers to be active is a good thing on this measure (though of course if you can use a technique that is also effective against active attackers this is better still).
GPG Tools seems to be popular and has Mail.app integration. It loads, shows the secret key as valid in the GPG Keyring app, but any attempt to decrypt a message fails with “Secret key to decrypt the message is missing”. No diagnostic information is provided.
Okay, I'll pretend it's still 1995 and run it on the command-line. "pbpaste | gpg --decrypt" needs a password, so I naively attempt to setup gpg-agent so I don't need to keep pulling my 30-character password from my password manager. "brew install gpg-agent" and it quickly turns out that it's just broken: pinentry doesn't get stdin for some reason and chews 100% CPU printing * as quickly as possible.
So much for saving time in the future; let's just see if we can open one message. Save it to a temp file, run it through gpg --decrypt and … it's HTML so the URL needs to be unescaped, so make that "gpg --decrypt encrypted.asc | urlview".
Open that URL and get … a server error from Facebook.
So … another vote for http://www.thoughtcrime.org/blog/gpg-and-me/