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.
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):
- Pages fanned
- profile picture
- current location
- networks (regional affiliations only)
- list of friends"
- 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.
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.