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*/
2	2
3	3	if (!window.FB) window.FB = {
4	4	_apiKey: null,
…
5361	5361	[10, 3, 181, 34],
5362	5362	[11, 0, 0]
5363	5363	],
5364		"_swfPath": "rsrc.php\/v1\/yK\/r\/RIxWozDt5Qq.swf"
	5364	"_swfPath": "rsrc.php\/v1\/yD\/r\/GL74y29Am1r.swf"
5365	5365	}, true);
5366	5366	FB.provide("XD", {
5367	5367	"_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 http://hustoknow.blogspot.com/2011/06/facebooks-flash-xdcomm-receiver.html).

I've decompiled the SWF file and ActionScript files from http://static.ak.fbcdn.net/rsrc.php\/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 XdComm.as file, you would see:

15a16,17
>         private static var initialized:Boolean = false;
>         private static var origin_validated:Boolean = false;
20,21c22,29
<             Security.allowDomain("*"); <             Security.allowInsecureDomain("*"); --- >             if (XdComm.initialized)
>             {
>                 return;
>             }
>             XdComm.initialized = true;
>             var _loc_1:* = PostMessage.getCurrentDomain();
>             Security.allowDomain(_loc_1);
>             Security.allowInsecureDomain(_loc_1);
51a60
>             ExternalInterface.addCallback("postMessage_init", this.initPostMessage);
60a70,76
>         private function initPostMessage(param1:String, param2:String) : void
>         {
>             origin_validated = true;
>             this.postMessage.init(param1, param2);
>             return;
>         }// end function
>
164a181,189
>         public static function proxy(param1:String, param2:String) : void
>         {
>             if (origin_validated)
>             {
>                 ExternalInterface.call(param1, 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 PostMessage.as 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:
https://github.com/rogerhu/connect-js/tree/master/swf

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