“Iframe Post Proposal” and Unique Identifier Mechanisms Aim to Solve Facebook User ID Issue

Facebook has outlined a new “Iframe POST Proposal” as a solution to prevent User IDs from being passed through HTTP refferer headers. The mechanism embeds the UID in a HTTP POST body ensuring that it will not be exposed in any HTTP Referrer header whatsoever (encrypted or otherwise).” The system should be easy for developers to implement.

For cases when a user ID must be passed between an application and a legitimate third-party, Facebook has developed an anonymous unique identifier mechanism.

While the information attached to user IDs is public, many national publications criticized Facebook for allowing the leak. In response, Facebook put forth the Canvas Encryption Proposal a month ago, and solicited feedback. Developers wanted a mechanism which had less impact on their applications and that didn’t require them to use encryption libraries. Meanwhile, Facebook sought a way to to prevent UIDs from being passed, even in encrypted form.

Iframe Post Proposal

The Iframe Post Proposal embeds the user ID within a <form/> element targeted at the application canvas URL in the body of an HTTP POST.

Instead of this:
<iframe src=”http://example.com/?fb_sig_user=218471″></iframe>

Applications would use:
<form target="canvas_iframe" action="http://example.com/" id="canvas_form">
  <input name="fb_sig_user" value="218471" type="hidden" />
</form>
<iframe name="canvas_iframe"></iframe>
<script>
  document.getElementById("canvas_form").submit()
</script>

Additional implementation details can be found on the POST for Canvas documentation page.

Facebook is now asking for feedback, but a schedule for transition to the Iframe POST Proposal has already been set. The migration is now active, will leave beta and become default for new applications on December 1st, and will be complete for all iframes on March 1st, 2011. Because of the limited time in beta, developers should promptly experiment with the new mechanism so they can share their thoughts with Facebook before December.

Third-Party Unique Identifiers

When an application interacts with a partner website, such as identifying that a user has completed an offer and earned Facebook Credits, it may be necessary to verify that user identity. To allow this without sharing the user ID, developers can assign a third-party unique identifier to a user. This can be done though either the Graph API or FQL, for one or more than one user.

To request a unique identifier from a user object through the Graph API:
http://graph.facebook.com/dmp?fields=third_party_id
&access_token=[access_token]

From the user table through FQL:
https://api.facebook.com/method/fql.query?query=select third_party_id
from user where username =”dmp”&access_token=[access_token]

This mechanism will become mandatory on January 1st, 2011. This is significantly faster than the three month opt-in migration system Facebook recently implemented in the spirit of Operation Developer Love , likely because it is part of Facebook’s expedited response to the User ID issue.