For a group of developers on Facebook’s platform, the clock is ticking.
Last night and into today, Facebook has been sending out notices to developers they believe have apps in violation of their policy against sending authentication data to third parties. Those developers have 48 hours to fix their apps or they risk being “subject to one of the enforcement actions” — read: being booted.
You may recall that all of this initially came up last week when Symantec wrote a blog post entitled “Facebook Applications Accidentally Leaking Access to Third Parties.” That post detailed how the company found close to 100,00 apps that were inadvertently leaking auth tokens due to the use of iframes for app authentication. As a result, Facebook responded with a blog post of their own noting that by September 1 of this year all apps must migrate to OAuth 2.0, ensuring encrypted access tokens.
But September 1 is still a long way away. And there are still apps out there leaking these tokens, which is even more of a problem now that Symantec has exposed the issue (Facebook, for its part, says there haven’t been any problems as a result yet). So it should be no surprise that Facebook is issuing this ultimatum to the apps they’ve found to still be in violation.
Still, 48 hours is a sharp turnaround time. One developer wrote us calling it the “great Facebook auth 2.0 switch panic of 2011”, noting that developers are pouring onto web forums to express their panic and confusion over the situation. It’s sounding a little bit like the brilliantly named “Oauthpocalypse” which Twitter has encountered a few times over the years (though the situation is completely different).
Facebook says these changes are only required from “a very small percentage of the developer community”. But given Facebook’s size, that’s still likely a lot.
So what can those in violation do? There are two choices — one easier than the other.
They can either move over to OAuth 2.0 now or “create and use an interstitial page to remove the authentication data before redirecting to your page with 3rd party content”. The latter is likely easier than the former for many developers in the short term. It’s more of a temporary fix until they’re ready to move over to OAuth 2.0 by the September deadline.
Below, find the full email Facebook is sending to offending developers.
Our automated systems have detected that you may be inadvertently allowing authentication data to be passed to 3rd parties. Allowing user ids and access tokens to be passed to 3rd parties, even inadvertently, could allow these 3rd parties to access the data the user made available to your site. This violates our policies and undermines user trust in your site and Facebook Platform.
In every case that we have examined, this information is passed via the HTTP Referer Header by the user’s browser. This can happen when using our legacy authentication system and including <iframe>, <img> or <script> content from 3rd parties in the page that receives authentication data from Facebook. Our legacy mechanism passes authentication information in the URL query string which, if handled incorrectly, can be passed to 3rd parties by the browser. Our current OAuth 2.0 authentication system, released over a year ago, passes this information in the URL fragment, which is not passed to 3rd parties by the browser.
Please ensure that you are not allowing this data to be passed immediately. Accessing your site as a test user while running a HTTP proxy/monitor like Charles or Fiddler is the best way to determine if you are allowing this information to be passed. If you discover the issue, you can do one of two things:
1. Migrate your site to use our OAuth 2.0 authentication system. We are requiring all apps and sites to update to this mechanism by Sept. 1, 2011. Migrating now will address this issue and ensure that you are one of the first to meet the deadline. For more details, please see our Authentication Guide.
2. Create and use an interstitial page to remove the authentication data before redirecting to your page with 3rd party content. This approach is used by many of our largest developers today (although they are all migrating to OAuth 2.0 shortly). This is a simple and straightforwardchange that should have minimal impact on your site. For more details on this approach, see our Legacy Connect Auth doc.
Because of the importance of ensuring user trust and privacy, we are asking you to complete one of the above steps in the next 48 hours. If you fail to do so, your site may be subject to one of the enforcement actions outlined in our policies.
If you have any questions or believe you have received this message in error, please contact us.
Facebook Developer Relations
Update: Symantec reached out to note that Facebook says they fixed the token problem (via scrubbing) so it shouldn’t be an issue anymore even with the legacy API. Clearly, Facebook is just taking precautionary measures here. “We don’t want to be seen as increasing the problem, which we are not. As part of responsible disclosure we only released info about the potential problem after we had worked with Facebook to make sure the issue was fixed on their end,” Symantec writes.
https://twitter.com/jennifermontes/status/70143308634144769