RAAK

Whether you love the Facebook API, or hate it, this week Facebook will welcome its 500 millionth user, making it impossible to ignore it.

Much scrutiny of late was directed at the social media giant’s security policies (or rather, lack thereof), and Facebook responded by stepping up their approach on security, at least as far as extended permissions go.

Let’s take a step back. In the past, users, by connecting to an application, allowed Facebook applications access to an implicitly specified amount of their profile information. Now users are confronted with an explicit list of permissions the Application is asking for.

Of course, change is always opposed by proponents of the status quo, and the reception of Facebook’s decision to try and sort out their permissions policy is no exception.

The change has caused waves of dispair in the Facebook developer community, especially amongst members of the DIY mashup community. For instance, click here to see what a search for “extended permissions” on the Facebook Developers Forum typically returns: Click here

While the extended permissions clearly proves to be a stumbling block to many developers, it is actually one of the few well designed aspects of Facebook’s suite of API’s. (no, I’m not generally a fan of the Facebook API, quite the contrary)

Ease of Use

A comma-seperated list of extended permissions is passed as a GET variable to the Facebook login URL, redirected to when getting the user to log in. It couldn’t be more simple. For some bizarre reason, though, Facebook decided to use different variable names for the graph API and the normal API. And, as usual with Facebook, this “feature” is extremely poorly documented. For your own reference, it’s scope in the graph API, en req_perms in the normal API.

examples:
https://graph.facebook.com/oauth/authorize?client_id=YOURAPPID&scope=read_stream,publish_stream
http://www.facebook.com/login.php?api_key=YOURAPIKEY&req_perms=read_stream,publish_stream

Clarity of Permission Names

Permission names are simple and self-explanatory; you don’t have to consult the list time and again to remember them. email, for instance, gives you access to the user’s email address. publish_stream allows you to publish to a users stream, and read_stream allows you to (guess what!) read from a user’s stream.

User Friendly Dialog Descriptions

The way each permission is translated to the user in the connection dialog is also simple, complete, and makes perfect sense. It’s amazing how often big software companies fumble with this step. For instance, read_stream is translated to the user as Access posts in my news feed. Pretty self-explanatory, huh?.

Next Week: Some security concerns, and the silver lining.