Raising Consciousness: Facebook's "Automatic Authorization"

By Nitesh Dhanjani
April 6, 2010 | Comments: 1

Facebook users have been repeatedly warned and educated to comprehend the reality that 3rd party Facebook applications can consume their private information. As such, many users have begun to expect a fair warning (illustrated in the figure below) that includes an explicit authorization request from the Facebook platform,when a 3rd party Facebook application is accessed.

facebook-authorization.png

Image: Facebook platform requesting authorization from user prior to enabling 3rd party application

However, there is a way for 3rd party Facebook applications to bypass displaying the warning and the explicit authorization request, using "Automatic Authentication" which is further defined at http://wiki.developers.facebook.com/index.php/Automatic_Authentication:

"Automatic authentication means that if a user visits an application canvas page (whether it's an FBML- or iframe-based canvas page), Facebook will pass that visitor's user ID to the application, even if the user has not authorized the application. The UID also gets passed when a user interacts with another user's application tab.

With this ID, the application can access the following data for most users (except for users who have chosen to not display a public search listing):

  • name
  • friends
  • Pages fanned
  • profile picture
  • gender
  • current location
  • networks (regional affiliations only)
  • list of friends"
Nitesh Dhanjani together with Billy Rios and Brett Hardin is the author of Hacking: The Next Generation.

With the advent of rich Internet applications, the explosion of social media, and the increased use of powerful cloud computing infrastructures, a new generation of attackers has added cunning new techniques to its arsenal. For anyone involved in defending an application or a network of systems, Hacking: The Next Generation is one of the few books to identify a variety of emerging attack vectors.

The 'Automatic Authentication' feature is not new - it has been in place since July 2008. The reason I'm bringing this into attention today is for the following reasons:
  • Even the more privacy savy individuals are not aware of this 'feature'. Individuals who have made the effort to learn about Facebook's privacy settings are unlikely to be aware of this capability. Many of these users are likely to go trigger-happy by clicking on URLs within Facebook because they rely on the Facebook platform to ask for explicit authorization upon clicking on a 3rd party application page.
  • The implications of publicly available data and the potential ability of a rogue 3rd party to uncloak a specific user's identity are mutually exclusive issues.

    In their explanation on the developer wiki, Facebook explicitly states that 3rd party applications that use this feature can only gather information about the given user that may be publicly search-able anyway.

    However, this assurance from Facebook is without merit because the implied reasoning is based upon flawed assumptions: the act of users choosing to make some of their information publicly search-able does not imply in any way that the users are granting the ability for rogue 3rd party applications to uncloak their identity (and data). Here is a simple example: my name is Nitesh Dhanjani and the information on my blog is public - however my web browser vendor cannot use this as a reasonable excuse to uncloak my identity to 3rd party web applications I visit.

  • The widening delta between the granularity of controls provided by social media platforms and the controls demanded by privacy advocates may lead to the need for client-side controls.

    fb_fromhash.png


  • Image: The fb_fromhash parameter


    For example, users that land upon Facebook applications will notice a parameter called _fb_fromhash which is present regardless of what authorization mechanism the 3rd party Facebook application chooses to use. This can be potentially leveraged to create a browser side control (example: Firefox plug-in) to warn the user that he or she may be accessing a 3rd party application that has the ability to automatically capture his or her identity. In other words, I foresee the need for a client side model to bridge the gap between privacy controls provided by vendors of social platforms versus the needs of individual users. Social-privacy-client-IDS, if you want to call it that.


Indeed, there is the clear rule of thumb pertaining to the use of online social applications: don't put anything online that you wouldn't want to persist in the public domain. However, this does not mean that brands in the business of providing us social platforms can go scott free. I sincerely hope the data contained in this post has provided you some additional information on how 'automatic authentication' works, including the implications of which, in case you were not aware of it prior.


You might also be interested in:

1 Comment

The problem is that many people use sites like Facebook and Twitter through multiple devices.

Resetting privacy preferences once is challenging enough for most consumers -- are they really going to install and set them on their smartphone, laptop, and work computer? (Assuming they have authority to install client side software on a work computer.) That doesn't even get to the people who use these technologies in schools or at the library....

I also worry about the business model for client side privacy tools. People haven't shown a great willingness to pay for privacy tools. Maybe the idea should be pushed towards other protective software companies, ie AVG or McAfee?

News Topics

Recommended for You

Got a Question?