Recently, using the Deft project, I created a multi-file uploader Flash component for DojoX. It uses a typical design pattern: embed a hidden SWF in the web page, and with the ExternalInterface, trigger the FileReference’s browse() method to open a system dialog.

Shortly thereafter, it came to my attention that this functionality is to be crippled in version 10 of the Flash player. Due to security concerns, a dialog can only be opened upon a user interaction—in this case, the user must click on a button, preventing malicious code from opening the dialog. This change has caused quite an uproar on the Adobe forums and the SWFUpload forums.

Adobe’s Change

While I’m not a security expert, I do take it seriously. But I also view it with a critical eye. Security measures should primarily be in place to protect the user, but they should take user experience into consideration, as well as the developer’s experience to work within the imposed limitations.

Like many others, I’ve fought the web’s lack of proper multi-file uploading capabilities for years, using various Ajax, Java, and ActiveX solutions, and was very excited when Flash 8 introduced this long-desired ability. The problem with this new security enhancement is that it breaks existing functionality. Developers certainly don’t enjoy having to unarchive old code and fix something that has worked successfully for years.

In his blog, Adobe’s Lee Brimelow states that the new change is to move Flash in line with general web security guidelines. He then gives two examples necessitating the change:

Developers can do things like repeatedly open the dialog forcing users to choose a file before being able to continue. This can essentially lock the user out of the application. Another potential concern arises from the situation where there are multiple SWF files on the same page from different sources. The user seeing the file dialog window does not necessarily know which SWF spawned the dialog. I will let you use your imagination about how this could lead to some bad things.

I’m sorry, but these arguments are inadequate. Especially the part where I have to use my imagination. When removing functionality that we’ve had since 2005, at the very least developers are looking for explicit reasoning.

If Adobe is protecting us from is rogue third-party code, then a broad denial of service is not the right approach in my opinion. Locking down the abilities of an SWF from a different domain would be not only more reasonable but possibly a security change that would be welcomed.

Don’t Blame Adobe

However, when you think about it, Adobe hasn’t completely killed the upload feature. While fixing existing code is very inconvenient, it will still be possible to do multi-file uploads. In my opinion, Adobe is taking the heat on a feature that fixes someone else’s mistake. And that someone else is every browser currently on the market.

The scenario is actually quite ludicrous. I think it would be fair to suggest that Flash expected that this feature would be used within the Flash environment, and they simply implemented the original specification, RFC1867, that allows for multiple selections and a file mask. Web and Ajax developers, craving a sane alternative to anemic HTML single-file uploaders, have managed to hack this Flash functionality into our pages to emulate what should have already been there in the first place. Now we’re mad at Adobe for crippling our hack.

Blame the Browser Vendors

Among other sources, an excellent research page on file input by Jukka Korpela leads me to the conclusion that the reason that browser uploaders are so bad is because they are emulating the original, primitive implementation by Internet Explorer 3 and 4. This could be excused in the early days of the internet when the thought of uploading a file to “who knows where” was intimidating. But now, a decade later, it seems the continued rationale is little more than laziness.

It further boggles the mind that current file inputs can’t be styled, for fear that they could be disguised as something they are not. This again appears to be for logic buried in the archives of 20th century security. I’d like to be able to hide the text field. I’d like to be able to change the button label to “Choose File…”. I’d like to make the button look like the rest of my website, and not look like someone glued a googly eye to it.

Any possible argument seems even more blurred by the fact that Flash has had a dynamic file input for three years, and the only apparent issues are being addressed by a button click.

Which browser will take the lead on this? Google’s new Chrome doesn’t add to the painfully inept file input, (although it does have Gears; more on that in a second). Opera’s version is subtly different, allowing for dynamically changing the value of a file input, but warning a user with a dialog that such an action has occurred — which indicates that change is possible. Firefox and WebKit, however, seem satisfied to continue following the more than ten-year-old approach taken by Internet Explorer, much to the dismay of users and developers.

In fact, now is the best time to implement fully-featured uploads in a browser, because of the proliferation of Ajax libraries, not to mention projects like SWFUpload:

if(well_behaved_browser){
	use_native_upload()
}else{
	use_some_ugly_hack()
}

However, not at all hope is lost. The new Gears Desktop API supports a fully functioning uploader in the upcoming 0.4 version. Hopefully, between Gears, and Chrome’s bundling of Gears, the days of single-file uploading are coming to an end.

Conclusion

I’d certainly like Adobe to reconsider the severity of their decision to require user interaction for a system dialog to open, as I think it is overkill. However, I’m more concerned with getting a viable long-term solution, so we can avoid the myriad of workarounds. I think there’s little doubt that across the board, feature-rich, multi-file uploading capabilities would benefit everybody.