Encrypting Facebook UIDs

Over the past few days, we have been investigating a technical solution to the issue of sharing Facebook User IDs (UIDs). While initial press reports greatly exaggerated the implications of sharing a UID, we take this issue seriously. Our policy is already very clear that UIDs may not be shared with ad networks and data brokers, but we recognize that some developers were inadvertently sharing this information via the HTTP Referrer header.

This proposal addresses the underlying technical issue of inadvertent sharing for applications on Facebook. We are outlining the details of this proposal early in order to solicit feedback from our developers and the greater Web community. Our intent is to quickly address this issue while minimizing the impact to developers and users.

Technical Background

When a browser loads images or other resources on a Web page, it will sometimes send an HTTP header that identifies the URL of the Web page containing the resource. For one type of application written on Facebook Platform (iframe-based canvas applications), after a user has authorized the application, the URL of the iframe may contain the UID of the user. This UID is included in order to enable the application to build a personalized experience for the user.

In the last few days since this issue was reported, some of our developers started using techniques like redirects or “double framing” to remove UIDs from the URL. While applications are able to address this issue on their own, we wanted to find a solution that would address this issue for all applications on Facebook Platform.

Encrypting Parameters

To address this inadvertent sharing of UIDs, we plan to start encrypting the parameters that we pass to iframe-based applications. We have posted the technical details of the proposal on our developers site, including a place for discussion and comments.

The proposal builds on our recent support for a parameter called signed request which is inspired by our discussions in the OAuth community. We will start encrypting this parameter as well, using the application’s secret key, so that only the application will be able to read this information. This will prevent the accidental disclosure of this information via HTTP headers.

Our plan is to enable parameter encryption as an option over the next few weeks and to then work with the community to add support for this option to the various Facebook SDKs. Once the design is finalized, we will work with our developers to ensure a speedy transition to encrypted parameters.

While this proposal will address the inadvertent sharing of this information on Facebook, the underlying issue of data sharing via HTTP headers is a Web-wide problem. We look forward to working with the Web standards community and browser vendors over the coming months to help address this issue.