In this post I hope to address some of the concerns raised by Keith Peters in his recent blog post. In the post Keith brings up some existing applications that will be broken because of the new security enhancements to the FileReference class. I for one had no idea that this issue existed so thanks to Keith for bringing it up. Let’s first take a look at exactly what has changed.
In previous versions of the Flash Player, you could programmatically call the FileReference.browse() method to open a file browser dialog window which enabled users to locate a file on their system so that it could be uploaded to a server. Many existing applications use this feature including various WordPress and Flickr uploaders. In Flash Player 10 you can no longer spawn this dialog window programmatically and it must be initiated by a user click. The attempt to launch the dialog with code will throw a security exception, effectively breaking these existing applications.
There are other important changes in the FileReference class like the new ability to read and write local files. My initial reaction was that the new security features were added because of these new features. But actually these changes were coming anyway due to some existing security concerns surrounding the FileReference class. Let’s a take a quick look at what some of these concerns are. Please bear in mind that I’m not going to go into too much detail about what all the security implications are but rather give a high-level overview.
HTML security guidelines do not allow the opening of file dialog windows without user interaction. The new changes in Flash Player 10 will move Flash in line with general web security guidelines. So why are there security concerns with doing this in the first place? Well for one, 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.
These concerns and others have made it vital that we implement the need for user interaction to launch the dialog. So then what will happen to existing applications that rely on the programmatic launch approach? In short they will have to update their applications to account for these changes. That being said, there are some workarounds available for applications that are launching Flash-based uploaders from HTML content. One such workaround is to create the HTML upload button in Flash rather than HTML so that the user will initiate the upload request from Flash. Similarly, another possibility is to overlay a transparent SWF button over the HTML content so that again, the user clicking happens in Flash and not in HTML. We are currently reaching out to partners to help them find the best solution for them.
Keith mentioned some well-known applications that will currently be broken because of the new security features like WordPress and Flickr. If you know of other applications please let me know in the comments section so that we can connect with them to help them find the optimal solution for their application.
After hearing the internal reasoning behind the new security enhancements I think they make total sense. There are just too many security concerns that arise when you allow developers to spawn native dialog windows programmatically. But we will definitely step up our efforts to ensure that existing developers get the help they need to update their applications accordingly.