Friday, December 23, 2011

Changes in Facebook's swf flash handler..

Ever since Facebook introduced a change in their Facebook Connect Library that caused severe login issues for IE users that lasted for more than a week, we've created scripts to monitor Facebook's JavaScript Connect Library to detect for any changes that might affect our users. Nate Frieldy first created the first version to monitor for diffs, and I soon forked it here to monitor for diffs that span more than just the changes that happen on the 1st line that indicates timestamp changes.

On December 8, 2011, our diff detection scripts picked up this change:

1 /*1323218538,169893481,JIT Construction: v482006,en_US*/
1 /*1323305592,169920374,JIT Construction: v482779,en_US*/
33 if (!window.FB) window.FB = {
44 _apiKey: null,
53615361 [10, 3, 181, 34],
53625362 [11, 0, 0]
53635363 ],
5364 "_swfPath": "rsrc.php\/v1\/yK\/r\/RIxWozDt5Qq.swf"
5364 "_swfPath": "rsrc.php\/v1\/yD\/r\/GL74y29Am1r.swf"
53655365 }, true);
53665366 FB.provide("XD", {
53675367 "_xdProxyUrl": "connect\/xd_proxy.php?version=3"

This SWF file is Facebook's cross-domain handler for web browsers that don't implement HTML5 but can use a Flash-based version of HTML5's postMessage() function that allows messages to be passed between different domains. Facebook doesn't often recompile the SWF file, so this diff caught my attention. The most reliable decompiler I've found is Sothink's SWF decompiler, which can be used to export the ActionScript files with a 30-day trial (for more context about how to decompile, see

I've decompiled the SWF file and ActionScript files from\/v1\/yD\/r\/GL74y29Am1r.swf and reviewed the diffs between the previously decompiled SWF with this one. If you were to compare the diff changes for the file, you would see:
> private static var initialized:Boolean = false;
> private static var origin_validated:Boolean = false;
< Security.allowDomain("*"); < Security.allowInsecureDomain("*"); --- > if (XdComm.initialized)
> {
> return;
> }
> XdComm.initialized = true;
> var _loc_1:* = PostMessage.getCurrentDomain();
> Security.allowDomain(_loc_1);
> Security.allowInsecureDomain(_loc_1);
> ExternalInterface.addCallback("postMessage_init", this.initPostMessage);
> private function initPostMessage(param1:String, param2:String) : void
> {
> origin_validated = true;
> this.postMessage.init(param1, param2);
> return;
> }// end function
> public static function proxy(param1:String, param2:String) : void
> {
> if (origin_validated)
> {
>, param2);
> }
> return;
> }// end function

The changes indicate that Facebook has tightened the cross-domain security policies. Instead of using wildcard domains to accept messages in its allowDomain() function, it now invokes a call to getCurrentDomain(), which is a function defined in the file used to execute a call to document.domain, relying more on the browser to define the security restrictions.

Most of these change should not affect your users...just wished Facebook would discuss more what's going on behind the scenes since your apps may very well be using the Facebook Connect Library without realizing these changes are happening beneath you!

I've started to post the decompiled SWF files here:

Note that these updates are only manually. If someone knows of an open-source SWF decompiler, then the diffs could be much more automated!


  1. Just found this post of yours... in my website i have a facebook login button which opens the popup window with the login form. Suddenly, since a couple weeks ago, it stopped working properly on IE. After I fill the login form, the popup window doesn't close. If I close it manually the process continues as expected (the user is logged in). It doesn't happen in other browsers... it it related to the question here in this post? Thanks.

  2. I've noticed that issue if you have a channel_url: parameter in your initial FB.init()...if you remove it, does the popup go away?