Hacker News new | comments | show | ask | jobs | submit login
Securing Email Communications from Facebook (facebook.com)
399 points by wrboyce on June 1, 2015 | hide | past | web | favorite | 164 comments



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.

So … another vote for http://www.thoughtcrime.org/blog/gpg-and-me/


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 server error is turns out to be relatively simple: urlview was picking up the plain-text version, which wraps the URL in square brackets:

[https://www.facebook.com/…/publickey/verify/?e=1&fp=…&ext=…&...]

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.


Thanks, I noticed the square brackets as well. We'll look into it.


Great, thanks!


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/


iPGmail works, but it's a somewhat cumbersome solution.

The lack of a decent iOS mail client with GPG support is somewhat of a show stopper for me.


The point is that somebody shouldn't have to come in and diagnose the server error.


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.


I agree with the general intent but since something broke, +1 to sweis for trying to fix it.


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…


I don't routinely do it anymore myself, but I had an one liner "May contain a digital signature to ensure integrity" and noone asked me any questions.


Not my website, nor do I know the website owner, but I often use http://futureboy.us/pgp.html.

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.


Yes, I know that one! Unfortunately this starts way further down the road of computer knowledge than does who ask me if I caught a virus… :/



Update: Somebody just sent me a PGP'ed email! Encrypted to my 1998 key, to which I no longer have the private key :-(


Do you have a new PGP key? Provide us a fingerprint, short ID, link or whatever, and you'll get mail ;)


66DB D820 C755 1E5E 2339 ABEC 98A3 E568 5745 0109

Edit: Achievement unlocked, thanks Iain and Seth.


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.


Each pseudonym needs its own GnuPG key. And there can't be any overlap in usage, signatures, etc. Just sayin'.


The point of this is to hide the data from gmail/hotmail/yahoo/other mail providers. Not Facebook themselves, obviously.


One of the engineers behind this is a YC Founder of this company: http://techcrunch.com/2011/03/21/sendoid-finally-sharing-big...

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 :)

[1] https://github.com/rakoo/idlewatch

[2] https://github.com/sup-heliotrope/sup/wiki/gpg


My setup uses alot/notmuch with offlineimap doing sync. If you have offlineimap sync on cron, or put it in daemon mode, you don't have to wait at all.


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.


can you expand on what you found terrible about the chrome plugins that added decryption to gmail?


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.


The number of people who will actually upload their PGP key is so low that the loss for Google is negligible, and FB knows it.

I find it more likely that they want to protect and to be seen to protect their users.


The number of people who will actually upload their PGP key is so low…

So another act in "security" theater for most people. They must keep everyone guessing at what they will do next.


Wat.

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?


> if you trust facebook with the plaintext

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.


This! I do not use Facebook but would love if this leads to increased interest in using asymmetric crypto to encrypt automated notification emails.


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.


I have the opposite experience. I installed Enigmail and everything just works.


Same here. Thunderbird with Enigmail on linux and it has worked for years.

What really made me happy was K-9 Mail on Android - now I'm not tied to a computer to send or read a secure email.

Facebook? I don't use it, but it is nice to see someone try to get GPG/PGP in front of people.


I've been unable to get Enigmail to work in Thunderbird on OS X. Anybody else has that problem? It leaves "normal" mails alone, though.

The issue I have is that it fails to discover my private key, even though gpg2 is clearly aware of it (and Engimail is configured to use gpg2).


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.


Thanks, I'll look into that. I don't think I ever explicitly configured gpg-agent, so there might be a lingering issue.


That's interesting. I've had nothing but success on it. It discovered my key that I didn't have to do anything with.


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.


They link to their key at:

https://pgp.mit.edu/pks/lookup?op=vindex&search=0x2F3898CEDE...

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:

"Software Developer / SysAdmin for hire. See https://mywebsite"

I guess at that point I'd be permanently branded a spammer though. ;)


Well, someone tried putting an ASCII goatse in there. I suppose that counts as "abusive."


How would that be spam? Aren't the keyservers intended to act as repositories for signed keys?


He'd be posting ads via signed keys. Not an actual usable signed key.


Is that already a problem? If not, I don't see how FB having a key changes anything.


Just a high profile key which people are going to look at, that is all.


Aaaand now pgp.mit.edu is down :)


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)


Fun fact: one of the big reasons Tom created Myspace in 2003 was because of Friendster's real-name policy. https://en.wikipedia.org/wiki/Tom_Anderson#Career


Things I didn't think I'd be doing today: adding my PGP key to my Facebook profile!


Perhaps this has already been said and I missed it, but Facebook has the capability to be a pretty neat public key repository.

You could have a pretty high degree of confidence that the public key associated with a Facebook account belonged to the account owner.

Hopefully they'll be come kind of API (if there isn't already).

Either way, I hope http://keybase.io lets me add my Facebook profile now!


It's kinda cool that they're doing this, if not for anything else than to raise awareness about PGP.

That being said, I'm trying my best, and coming up short, in figuring out what problem this would solve...


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.


This solves the problem of your email provider reading your Facebook notification emails.


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.


That's not really what I'm taking issue with.

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.


You are right. I assumed that encrypted notifications would be sufficiently common that they wouldn't raise a red flag, but that is obviously wrong.


Given that if you turn on all notifications you'll have about a bajillion of them it's a pretty good smokescreen.


Yep. This is good overall and certainly for password reset e-mails.


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.


Facebook basically got pwned when firesheep came out. I think that ordeal basically made them more security minded.


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!


Yes, but they could just start signing the mail. There's no reason to encrypt the content if proof of origin is what they want to provide.


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.


Exactly. It seems perfect for this sort of email because the existing PKI handles trust.


Did they just kill pgp.mit.edu by linking from this page? I'm having problem retrieving keys from pgp.mit.edu, or it's just a coincidence...


Works for me (and quite fast, given I'm using the Tor browser).


The top page seems to be working but lookup part seems to choking. Getting one from gpg didn't work, too


It's long been the least reliable keyserver I've used.


What are some better ones?


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/


Hmm, I was about to suggest http://keyserver.eu/ but they seem slow now as well. A sudden surge of interest in PGP?


It's dead for me, too.


Since the pgp.mit.edu site is down, here is their public key DEE958CF: https://gist.github.com/grahamc/efbebf4c05ff9e097731


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.


Yeah, right. Except for the rape prisons I guess.

It's not against you personally, but I never understood how people compare a brutal, murderous gov. agency to something as mild as a social network.


At first I misparsed the title, and since I do not use Facebook, thought it was about preventing them from reading your email...


Bug report: the add public key page doesn't recognize the public key exported by GnuPG which has the header

  -----BEGIN PGP PUBLIC KEY BLOCK-----
  Version: GnuPG v1.4.9 (Darwin)
I figured out that the second line with version should be removed but the error message is not quite helpful.


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.


I wonder if they're using PEAR Crypt_GPG to facilitate this, or if they wrote their own encryption wrapper?

If it's the latter and anyone at Facebook wants someone to look over their implementation, let be know. ;)


Hi Scott. We're not using PEAR.

If you are interested in looking at the implementation and other interesting security stuff, we have a lot of security openings:

Security Software Engineer - https://www.facebook.com/careers/department?req=a0IA000000G2...

Open Source Security Engineer - https://www.facebook.com/careers/department?req=a0I1200000G4...

PrivateCore Software Engineer - https://www.facebook.com/careers/department?req=a0I1200000G4...

Security Infrastructure - https://www.facebook.com/careers/department?req=a0IA000000G4...


Do/will they support curve25519 keys?


Quoting from the article: "we are investigating the addition of support for GPG's newer elliptic curve algorithms in the near future"


Missed that. My bad


Neato. The idea of Facebook acting as a "keyserver" worries me a bit though.

I'm looking forward to when they inevitably (I hope) add support for visualising the Web of Trust


Why does the idea of Facebook as keyserver worry you? How is it worse than using another keyserver?


I don't need a MIT account to use MIT's key server. Facebook has the tendency to make things available only behind their wall.


Why couldn't you use both?


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.


Can you tell me more about the state of End-to-End?


It works, and should still be used with caution.


Do they use --hidden-recipient ?


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.


67uy, I hope you read this. Your account seems to have been falsely flagged as something bad immediately, you are "[dead]" ghosted. :/


Since notifications from Facebook will contain mostly predictable content won't these just become cribs for crackers?


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.


I dont facebook very often so every few days they send me a notification email "myname you have notifications pending." even when i dont.


Modern crypto algorithms are considered broken if they're not secure against known-plaintext and even chosen-plaintext attacks.


What is the easiest way to get a PGP key?


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.


This tutorial is very easy to follow, and will get you set up from scratch.

https://emailselfdefense.fsf.org/en/


Any they encrypting the contents, or merely signing them? The article seems to imply one then the other.


They encrypt with your key (so only you can read), and sign with their key (so you're sure it really comes from them)


My reading of it is that if you give them your public key they will encrypt to it and sign the message.


Next-up officially announced integration of Axolotl and ZRTP in both Whatsapp and Facebook Messenger?


WhatsApp already implemented Axolotl - https://whispersystems.org/blog/whatsapp/


It's only used opportunistically, though (which is still much better than plaintext).


> Implying that opportunistic encryption is much better than plaintext

Unless you have an active attacker, in which case they are equivalent.


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).


So, overall, much better :P



I said officially announced. Do you have a link from Whatsapp saying that?


This sounds like another completely pointless PR stunt to fool people into thinking Facebook gives a shit about their privacy.




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

Search: