gistfile1.txt

Response from Facebook

As you saw, the Facebook API is now versioned: https://developers.facebook.com/docs/apps/versions. That means any apps created today can only make requests to the v2 API, but apps created before the announcement can make requests to the v1 API until it expires as well as to the v2 API. That’s a necessary step since an application can’t always upgrade to v2 of the API in one synchronous step (ie: if a single app ID powers a number of mobile apps as well as a web app). To support that behavior, we support app-scoped UIDs even via the v1 API. And that’s where we run into problems 😉

Generally speaking, you identified three potential issues:

Given an app-scoped UID for v2 app X, it is possible to make requests to the v1 API with a v1 app Y and get back data.
Given an app-scoped UID, you can browse to https://www.facebook.com/app_scoped_user_id/APP-SCOPED-UID and trivially see the real user.
http://graph.facebook.com/APP-SCOPED-UID returns information about the user
The behavior in #1/#3 was caused by the fact that in v1 we were resolving app-scoped UIDs without verifying that the app was tied to the user account. Surprisingly, this is necessary in some cases (ie: an app which supports both v1 and v2 can make a request to http://graph.facebook.com/APP-SCOPED-UID and reasonably expect to get back a response, even without an access token, since that’s how v1 API works). What we’re changing is that IDs generated for apps which solely support v2 will not be able to make those same requests.

The behavior in #2 is actually by design and will not change. We need to provide a way for applications to generate profile links back to Facebook, which is what /app_scoped_user_id/ is for. Without it, there’s no way for users on an app to interact with their fellow users on Facebook. The endpoint requires you to be logged in and has rate limiting in place to prevent mass scraping. This was a security/usability tradeoff which we made as part of the development process.

In general, they’re more concerned about the ability to go from an app-scoped user ID to a global ID versus the ability to go from a global ID to an app-scoped ID. The former is at best a bug (ie: we’re returning an incorrect identifier) and at worst provides a global identifier that can be used to link users between unrelated applications. In the latter case, someone who knows the global ID of a user can already identify that user between applications.

…we’ve concluded that we won’t be rewarding issues of this type under our program going forward.

…the ability to go from an app-scoped user ID to a global identifier is definitely a Platform bug since the wrong identifier is being returned by the API. From a privacy perspective the fact that you can assign a global identifier to an API user also means that it’s easier to connect a person’s information between unrelated apps. However, app-scoped user IDs are a technical solution to a policy problem, and as such there are going to be ways to circumvent them (ie: two apps with access to your posts can collude to identify you by which posts you’ve published).

On the policy side, our Platform Policy document (https://developers.facebook.com/policy) lays out rules like “Protect the information you receive from us against unauthorized access or use” and “Don’t sell, license, or purchase any data obtained from us or our services” which are intended to protect people’s data. On the product side, our Anonymous Login system is intended for cases where you may not want to associate any of your personal information with your identity in an application.

We intend to treat future reports of this type as Platform bugs, which can be reported at https://developers.facebook.com/bugs/, since they affect the validity of the data returned via the API. However, since these identifiers are not directly intended to impart an extra layer of privacy, we aren’t going to treat these issues as valid Whitehat reports.