If you haven’t already, PLEASE update to the latest (9.0.124) plugin, right now! Also, help Jens’ article get some love by digg’ing it, please. We’ve got to get the word out!

NOTE: This security bug has been known and exposed for months now, and is *not* the same as the new security hole I found and wrote about last week. That one, unfortunately, remains unaddressed by Adobe so far.

As I mention in the first comment on that digg posting, for quite a while now, libraries like SWFObject and our very own CheckPlayer have exposed Adobe’s “ExpressInstall” functionality, which is a drop-dead simple way for users to be prompted to update their Flash Player plugin automatically, unobtrusively, inline in the browser whenever they visit a site with Flash content (even ads!).

If web authors would realize the importance of keeping users’ systems up to date and secure, and would simply use libraries and features like “ExpressInstall” to update users’ plugins as they visit their site, I think there’d be much less chance that hackers and malicious folks will be able to wide-spread take advantage of such vulnerabilities.

This call is *especially* true for the big, high traffic sites, who have probably the best possible chance of getting updates out to the public. If Yahoo, MSN, YouTube, Flickr, etc would use the “ExpressInstall” feature on their flash content, and specify the latest secure version (such as “9.0.124″), then millions of users would be updated very quickly, and vulnerabilities like this would die very quickly too!

I also think Adobe could do a better job of getting this same call-to-action out, for the general web-dev authoring community. We all have to take responsibility in helping keep the web as safe and secure as it can be for the technologies we use to present content to users.

First, a brief summary of the two main “use case” conclusions of this article regarding the impact of the security hole found:

1. If a page is hosting a SWF from a different domain than the page… In this case, Adobe’s model will *only* check the SWF’s domain for cross-domain policy permission. Since a SWF has to be made publicly available through HTTP/S just like images do, *anyone* can link to your SWF and use it in their page… any server who your SWF can contact would probably want to allow access not just based on where the SWF is coming from, but also from the page context it’s running in, but they cannot control the page-domain access. This is especially true if you as the creator of the SWF had to make the SWF more open/flexible in its capabilities for arbitrary communication (such as flXHR or other RIA communication widgets), because it’s more susceptible to “abuse” by a malicious page and its javascript.

2. The more limited, niche-case is if you want to host a SWF on your server, but do not want that SWF to be able to contact your server… you *cannot* control that, because the flash player will grant “auto-trust” to the SWF to talk to *any* part of your public server’s access points. Ideally, it would seem like most server admins/authors would want to be able to publish a policy on their own server which controlled access by *any* SWF, not just any remote SWF. It seems pretty clumsy and dangerous that a host’er of a SWF cannot control that SWF’s communication back to the same hosting server with a server policy… and moreover, *this* case is actually contradictory to what Adobe’s own whitepaper says (bottom of page 28 of this PDF).

Here’s a run-down of the major things to note (more details can be found in the documentation and release-notes for each project):

• Both CheckPlayer and flXHR have been tested thoroughly on a wide spread of browsers and platforms. The pass/fail notes can be found here: flensed Documentation
• A new test-suite tool is available for easy testing of CheckPlayer and flXHR in various browser environments. The tool can be found here: flensed Test Suites
• CheckPlayer now supports two new events, SWF_TIMEOUT and SWF_EI_READY. The timeout is an optional setting that times-out a non-responsive loading request of a SWF asset. The EI-ready is an optional SWF ExternalInterface callback function to check for availability/initialization on the loaded SWF (since the EI takes some time to be ready after a SWF is fully loaded). Both events tie into the DoSWF callback function feature, which allows your code to respond definitively when either of these events occur, and either load a new SWF asset or display other alternative content.
• flXHR now supports the username/password parameters to the open() method call, which if non-empty, will create an ‘Authorization’ header and append it to the request.
• flXHR now has a new feature called ‘instancePooling’. Essentially, this feature is most useful when integrating flXHR with Ajax frameworks (jQuery, Dojo, etc). The feature instructs flXHR to keep references to flXHR instances around, and when new instantiation requests come in, if a suitable idle (already-used) instance is available, to re-use that by sending back its reference, instead of the time/memory penalty of creating a new instance. This should greatly improve the performance of flXHR in a multiple-request environment, especially with JS frameworks.
• Both CheckPlayer and flXHR have undergone some significant polishing in terms of code clean up, proper memory management, robust asset loading, etc.
• Lastly, flXHR has received a major security upgrade. Details of this security change are far too intricate for this post, and will instead be handled in a separate post and in dedicated pages. These writeups are forthcoming very shortly. The short story is that (what we deem as) a security ‘hole’ in Adobe Flash Player’s cross-domain policy model was identified and reported to Adobe, and is pending a response from their engineers.

  But rather than wait for a future plugin update, flXHR’s code has *temporarily* (hopefully!) been augmented with code to attempt to plug the hole in the best way possible. The change in behavior that authors will now see is that the cross-domain policies will be enforced more strictly, in that both the flXHR.swf’s originating domain *and* the URL domain of the HTML page that hosts the flXHR.swf will be checked for cross-domain authorization (before, only the SWF’s domain is checked).

Please update flensedCore (to v0.2), CheckPlayer (to v0.7) and flXHR (to v0.6) as soon as possible to take advantage of the bug fixes, security updates, and new features! Join us in the forums and in our google-group mailing list for more information and answers to any questions you may have!

So, is it fair to compare Flash and Silverlight as technologies — they’re both web-browser enabled plugin technologies? Or, is it more precise to compare AIR to WPF, since both of them ground themselves in the new frontier, the user desktop? Are all those blog posters right, should we be really making sure we don’t mix technologies when we make comparisons?

From a technology standpoint, yes, this is important. But maybe not from a strategic web ecosystem perspective. Maybe the AIR/Silverlight comparison (however buzzword misguided it may have initially been) is more on track that most of us have realized thus far.

I’m still, and have been for a long time, more a flash fan than what microsoft has had to offer. And with the recent explosion of interest in the Silverlight community, I’ve been reluctant to admit that Silverlight really had all that much to offer. I’ve had many a conversation with my Microsoft-technology developer friends about the various reasons why Adobe or Microsoft has a better head of steam to roll in and (re)define the true RIA technology environment. Not unexpectedly, being an Adobe enthusiast, I’ve had a thousand and one reasons why Adobe’s going to rule this space and MS will be the “never-was” second tier player.

But, I had a paradigm-shifting ephiphany over the weekend. I realized that what the Flash-to-AIR evolution has in common with the WPF-to-Silverlight evolution is that it’s the natural extension, although in opposite directions for each vendor, of core competency into the space that each’s counterpart has ruled for so long.

You see, MS has clearly ruled the desktop-application space for a long time. And they have a huge contingent of developers who are thoroughly entrenched in the “.NET ways”. Those same developers live and die by the powerful Visual Studio IDE and dev tools that MS has been so good at for so long.
But they’ve (MS devs) struggled a bit to extend themselves into the web-application world, because the browser is such a feeble “client” compared to what MS Office apps are used to leveraging for instance. There are a lot of improvements, with ASP.NET and the various open-sourced toolkits that come along with it. But you still get the sense that MS is playing catch up.

So, naturally, MS has created a way for all those MS developers and apps to start cross-targeting the web space by giving the browser a facelift with new technology (via the Silverlight plugin), while still being able to deliver a strong, powerful application experience for users. What will we see in the coming months? I predict we’ll see incredibly powerful and cool extensions of MS apps put directly inside the browser… MS Word on the Web™, anyone?

But then, what about Adobe? Yeah, they’ve got great developer tools in the desktop environment too. But their real strength has been they’ve been going at the browser-on-steroids RIA environment with the Flash plugin for a long time now, and they clearly have a strong lead. And then, consider that even outside of what Adobe’s done with Flash, there’s a *huge* community of really incredible developers building all kinds of amazing Javascript+HTML web applications that really defy what we once thought was possible inside the chrome walls of the browser.

So, along comes AIR… and here’s where my naivety and paradigm-shift were blown wide open. While certainly AIR will make Flash-on-the-desktop apps a reality… I think the far bigger tour-de-force that’s happening is that it will be so drop-dead easy for web applications to make the jump to persistable, offline-capable, desktop apps… truly the “next frontier” if you’ve been playing in the web application arena for any length of time. So, what will we see from AIR? We’ve already seen moves to make some really popular and powerful web applications available on the desktop. So, flickr/youtube/twitter/myspace/facebook/etc/etc/etc — all these great web apps are probably going to head toward a desktop near you soon.

And if you want to get really funky… what about applications which can leverage both Silverlight and AIR and Flash and WPF all in one? I predict it can and will be done. The question is, who will do it.

In broad, rough concepts, AIR represents Adobe’s move to the desktop, and Silverlight represents MS’s move to the web. They’ve passed the boundary that used to imaginarily separate them from each other, and have moved boldly into each other’s space, and both are doing a great job of it so far. So now it appears that truly the comparisons *should* be AIR + Silverlight.

What’s so great about this revelation? The point really is, both of these moves, while in opposite directions, are incredibly important for defining what the next generation of applications look like, both on the web and on the desktop. I for one am no longer hoping that Adobe beats MS (or the other way around), but that they both keep spurring each other along, and that us web dev authors continue to have more interesting and exciting choices when it comes to the technology we can leverage for our user audience.