Today, Facebook rolled out major changes to their API. While I’m involved in the indie web scene, I have a professional interest in the Facebook API platform and have built a number of Facebook apps.
The changes to Facebook’s API are interesting. First off, there’s Anonymous Login which has got a lot of interest amongst geek friends who think about identity. The idea there is very much pitched at the mobile app market and I don’t see quite so much use for it on the web. If you want to provide “anonymous login” on the web, you just… don’t log in.
Also on the mobile app front, Facebook are pushing App Links which means dropping lots and lots of meta tags into your pages, including a pointer for ‘deep linking’ inside native iOS apps (using custom URL schemes) and native Android apps (using Intents and Activities). It’s interesting to note that Spotify has implemented App Links given how using Spotify on the desktop has become very far from seamless since the introduction of the Web Player.1
Where the Facebook API changes get a bit more interesting is the changes they’ve made to the login process and the Graph API. For user privacy, these have mostly been good. The new Facebook app login window lets you be a lot more clear about what permissions you grant to an application. Before, let’s say an app asked for both basic information and some extended profile like, say, your relationship status, you had two choices: accept the app and grant it both basic and extended information, or reject the app. Now you can choose which pieces of non-basic information you provide to an app. Now app developers will need to check what abilities the user has given you and then deny them the functionality they need and bounce them back through the auth process if they don’t give it to you, or offer more limited functionality.
Apps also now get an app-specific user ID token instead of a universal user ID. What this means is that you can’t easily join together Facebook API data across apps anymore: you have to use a new API called the Business Mapping API, which requires that you set up an account using Facebook’s Business Manager system. This ties together Facebook pages, ad buying and app management with a corporate permission structure: so you can set up developers and testers and administrators to have access to a suite of company Facebook assets. This might actually be useful for some companies, although it may present issues with companies that delegate the production of apps to agencies: will agencies build apps in the agency business account or in their client’s business account? It’s an issue anyone who does Facebook will have to think about.
The API doesn’t let you return a list of a user’s friends anymore. The friends endpoint will now return a list of the user’s friends that have authorised to use the app. Apps that rely on spidering a user’s friend network may be in for a shock. And not just spammy apps: the Tinder dating app shows the number of mutual friends when you are looking at someone. When they switch to V2 of the Graph API, they’ll only be able to show you the number of mutual friends who also use Tinder. (The cynical bit of my brain says Facebook will probably offer them a bizdev deal to give them the full capacities. Maybe.)
More important than that is that Facebook are now going to require review of apps that use Facebook Login and the Graph API to get access to anything beyond public profile information, email address and the list of friends that also use the app. Want to know what brands users of your app like? You’ll need to get your app reviewed. Want to know whether your users are single or married, employed or not, university graduates or not, straight or gay, what their birthday is or perform a wide variety of functions including publishing on their stream without an explicit Facebook SDK UI? You’ll need to submit your app for review and include details of how having access to particular bits of data will improve the experience for the user.
As a developer, this means an infuriating loss of functionality. Certain things you could do fairly straightforwardly will be harder to do, and the acceptability of them will be at the whim of Facebook. It means less experimentation on the Facebook platform: companies will be less interested in building an app that is at the fringes of acceptability.
As a user, it is probably a good thing. Facebook apps have been very spammy and users have been less than careful with their private information. Facebook aren’t preventing you from using the data, they are just saying “if you want to use a particular type of information from a user, tell us why”. The review process actually requires you to explain how your use of the information will “enhance in-app experience” for the user. “Flogging your personal data to sleazy data brokers” isn’t really positive UX: actually having Facebook make sure that the data asked for serves a purpose may not be a bad thing for the user at all. For people building apps for marketing, it may push them away from the platform. Your perspective on whether this is a good thing is probably determined in a large part by whether you are in marketing or not.
Those with existing Facebook apps have a year to switch over to V2 of the Graph API and Login system. New apps must use V2 from now on.
We’ll have to wait to see how the changes play out, but these API changes seem to show that Facebook are leaning more towards protecting user privacy from the many “low-quality” apps and making it so that some actual benefit in UX is given to the user in order to be given access to the data.
And, yes, it’s their playground, they get to set the rules. Whining about them if you don’t like them is pretty pointless: instead, you know, build something better without centralised control.
Pasting an HTTP link to a Spotify song into my browser now launches the Web Player and nags me to log in rather than just telling the Spotify app on my laptop to play the song. The only way to avoid this is to log into Spotify Web Player and stay logged in, even if you don’t use the Web Player. ↩