October 6, 2015


Cognitive disconnect: Understanding Facebook Connect login permissions

[Nicky Robinson is an undergraduate whose Junior Independent Work project, advised by Joseph Bonneau, turned into a neat research paper. — Arvind Narayanan]

When you use the Facebook Connect [1] login system, another website may ask for permission to “post to Facebook for you.” But what does this message mean? If you click “Okay”, what can the site do to your profile?

Motivated by this confusion, we explored Facebook Connect login permissions with the twin goals of understanding what permissions websites are given when a user logs in with Facebook and whether users understand that they are authorizing those permissions. Here is a working draft of our research report.

As it turns out, allowing an app to “post to Facebook for you” allows it do quite a bit. It can update your status, upload photos, upload videos, share things with your friends, check you in at locations, publish your activity on that site, create notes—basically, it can put anything on your timeline.

Facebook Connect provides a plethora of permissions developers can request to allow their website to access various parts of a user’s profile. The majority are for reading information, others are for particularly sensitive areas such as sending text messages. Eight are permissions to publish. But quietly these eight permissions have been combined into one. If a developer requests any one of the eight, they will get them all.

Two blog posts by Facebook (1,2) explain that they “simplified” and “clarified” the permissions process by combining all of the publishing permissions into a single one called publish_actions. However, the other seven more limited permissions (such as a permission to create a note and another to upload a photo) can still be requested. Many apps still request them but now get the full set whether or not they realize it.

We filed a security bug report with Facebook stating that requesting one publishing permission gave access to all of them. Facebook Security reiterated the position from their blogs, stating that “this behavior is by design” and claiming that all-or-nothing write permissions are “easier for users to understand.”

To evaluate this claim, we surveyed hundreds of users to see if they actually understand what sites will be able to post on their profiles when they log in. Respondents were actually significantly worse at identifying what could be posted than if they had just guessed randomly. However, this was not true of read permissions—users were significantly more likely to understand read permissions correctly with their granular model. This suggests that fine-grained permissions may be easier for users to understand.

Percentage of respondents that correctly understood each read permission

Percentage of respondents that correctly understood each write permission

We identified several other major gaps in user understanding of Facebooks’ permissions model. Users generally don’t understand that their privacy settings only affect what other users can see, not what the apps they authorize can see. They also tend to think apps can only perform actions that make sense for that application: they expect Flickr can post photos and TripAdvisor can post checkins, but don’t realize either app can take both actions. This suggests users implicitly have a contextual integrity model of privacy.

Building user interfaces that intuitively reflect user expectations about privacy is always challenging. In the case of all-or-nothing write permissions, however, it appears Facebook is using a model which is much harder for users to understand than the granular system despite claiming publicly that the new model is easier. So why the discrepancy? Facebook may be unaware that their new model is actually more confusing. It’s likely that the consolidation of write permissions is a technical artifact of the ways Facebook has changed. It used to be that uploading a photo and updating your status were distinct actions, but now they’re both posts on your timeline.

A more cynical possibility is that Facebook is intentionally creating vague messages so users do not understand all the permissions they are giving up. This would let developers obtain more permissions to share content without putting off users. Facebook’s own documentation claims that “apps that ask for more than four permissions experience a significant drop off in the number of completed logins.”

Single sign-on systems have the potential to make the web more secure (fewer passwords can mean stronger and more secure passwords). Facebook Connect’s data sharing features allow sites to do some really cool things and have been a major factor in making it the most deployed single sign-on system on the web. But this potential win-win depends on giving users effective understanding and control of the data they’re sharing, as Facebook recognized when launching the system back in 2007.  Our research suggests that there’s still significant room for improvement.

Note: On April 30, after the conclusion of our research and our correspondence with Facebook security, Facebook announced an update to its permissions system which allows users to reject individual read permissions or login anonymously. However, this change does not address our concerns: there is still only one publishing permission and it is still presented with the same vague message.

I would like to acknowledge my coauthor and adviser on this research, Joseph Bonneau.

[1] The system is now officially called Facebook Login and not Facebook Connect. We stick with the latter term which is still more widely recognized.


  1. That single publishing permission is a huge and obvious social-engineering security hole (not to mention personal-relations mess). If you sample facebook feeds (at least in my circles), there’s a constant low-level stream of “Sorry for the spam, I didn’t know such-and-such app would be sending you messages in my name.” So it’s pretty hard to imagine that the conflation is anything but deliberate.

  2. “They also tend to think apps can only perform actions that make sense for that application: they expect Flickr can post photos and TripAdvisor can post checkins, but don’t realize either app can take both actions. This suggests users implicitly have a contextual integrity model of privacy.”

    Or more simply it suggests that users naturally expect least privilege interprerations of coarse grained write permissions.