in Actionscript 3

Flash Player 10 FileReference Changes

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.

Lee

Write a Comment

Comment

123 Comments

  1. I am a little hazy on how to make sure we comply with the new standard. Do we just need to place the FileReference.browse within an MouseEvent.CLICK handler, or is there more to it than that?

    thx

  2. Here is the exact verbage from the documentation:

    “In Flash Player 10, you can call this method successfully only in response to a user event (for example, in an event handler for a mouse click or keypress event). Otherwise, calling this method results in Flash Player throwing an Error.”

  3. I GUESS that make sense. :-).
    In fact, it makes perfect sense, and it has to be done.

    When I first read Keith’s post, I was also a bit :-\ frustrated by the news; however, you defended the decision rightly so.

    Security comes at a cost for freedom sometimes… and vice versa.

  4. Maybe its late here.. but could a dispatchEvent(new MouseEvent(MouseEvent.CLICK)); circumvent the “must be clicked by user”? Or is Flash somehow watching these bits of code too?

  5. “In Flash Player 10, you can call this method successfully only in response to a user event (for example, in an event handler for a mouse click or keypress event).”

    I’m sorry, but this is really ambiguous! Does it mean that the browse method must actually be within the event handler function? Right now I have an UploadManager class that contains a private FileReference object. So my click event handlers call myUploadManager.browse(), which in turn calls _fileReference.browse() internally.

    Will this work? Or do I have to make _fileReference public and have the event handler call it directly? e.g.: myUploadManager.fileReference.browse();

    Also, Lee, can you post a link this documentation you are referring to? Thanks

  6. I have an application which sends data to the server after the user clicks a button. The server makes a pdf from the data and my app then uses FileReference.download to download the pdf.
    But the FileReference.download is called in the result event handler (from the server). I guess it will throws an error with FP10.
    What is the workaround for that?

  7. I’ve tried to post this comment into Keith Peters post few minutes after he posted it, but, to no avail. Maybe I was censured for flaming Adobe though I’ve never meant to do so. I’ve generally meant what you just said that Adobe got to align with security standards.

    —————————————————–

    “I’m guessing Adobe has high hopes for the Flash 10 feature of editing a file on the client without going to the server. And that users will get used to the upload dialog everywhere on the web and will be willing to more easily “upload” their sensitive files.

    For example:
    The attacker might sit in one of the user’s tabs and wait, for example, that the user will go to gmail.com (monitoring like this can be done with current browsers) then it’ll popup the dialog asking for the user address-book file.

    Adobe want to be a good and secure player as it’s regularly been bashed as a provider of an insecure player, not always justifiably though.

    Not saying that the crippling of this feature isn’t highly annoying, but, maybe it for the best.”

  8. That makes perfect sense. Sad though that this will likely lead to more Flash hating.

    So Flash can’t count JavaScript clicks connected with ExternalInterface as user interaction?

  9. I really don’t see what all the fuss is about…. is it really that hard for BIG websites like wordpress and Flikr to update their uploading swfs?? I mean really…. people cry over the smallest things… I bet in a few months people will forget all about this and it will be normal to add FR.browse() in mouseEvent handlers.

  10. We use the browse button to allow the user to upload multiple SWFs. However, when the user presses the browse button it first calls a script to get an ID for the multiple upload sessions and then attaches this ID to each uploaded SWF to then allow us to display all these uploaded SWFs together in the application. So we open the browse programatically after the ID has been returned – and this delay of waiting for the server ID response (usually a fraction of a second) gets interpretted by Flash player 10 as a security exception and the browse window does not open.

    The only work around I can think of is to force the user to press a button to get an ID and then press a second button to invoke the browse and upload the SWF files.

  11. It sure would be nice if:
    1. The flash plugin could examine the browser event queue and determine that a javascript key/mouse event had occurred in the event bubbling stack that led to an ExternalInterface call into flash. Kind of like “marshalExceptions”, but for events.

    2. Could there have been a different way of mitigating the security concern than just shutting off the browse dialog all together? Like, for instance, could a programatically launched dialog have different/limited behavior versus an event launched one? Maybe the programatic one could be limited to one instance in a browser at a time, and maybe it could force the swf which referenced it to highlight in the browser, or display the id of the swf in the title bar of the browse dialog, or something like that. Or, maybe a programatically launched dialog would have to first ask the user’s permission to display?

    I just think there could have been other ways to chase down the potential security threats rather than just throwing the baby out with the bath water.

  12. I agree with Kyle. ExternalInterface calls should be able to trigger the dialog (and full screen mode, etc.) and putting invisible Flash movies all over the place will not do the trick. For example, imagine a Flash video player with a JS/HTML playlist where you’d like to have a ‘watch in full screen’ button launch videos directly from the JS/HTML playlist. Every ‘watch in full screen’ button couldn’t be an instance of a swf video player… that would be a pig. And if it is possible to create invisible Flash movies isn’t it then also possible for someone to trick people into opening dialogs they don’t even know are there, or ‘take over’ their experience? I would imagine a full page Flash button overlaid transparently on top of a site could get clicked, open a dialog and the user would have no idea from where or what purpose it serves. Javascript could be used to covertly resize and move the document element to appear on top of other things on the page. The bigger question in these sort of cases case is – how did that malicious Flash app get on the page, or how did the user end up on the page?

    These design limitations occlude better interfaces for the many to account for a few limited bad scenarios, all of which present other possible workarounds… for example you could simply prevent Flash from allowing multiple dialogs to open sequentially without time elapsing (or other interaction occurring) between them. For example:

    – Dialog opens (without event).

    – User cancels dialog.

    – Dialog attempts to open again (without event) in less than X milliseconds, and as a result throws a security error.

    – This to the user could be similar to the ‘do you want to abort a script’ dialog so they can opt to allow it to open again. ‘A flash movie on this page is attemption to re-open a file browse dialog. Do you want to allow this?’

    I dislike having to use one of Flash’s specific MouseEvents as-is to open the file dialog (or go full screen, etc.). I’ve written my own enhanced mouse interaction architecture that wraps Flash’s own ‘button’ mechanics, and in turn it dispatches custom events (or in a custom way dispatches MouseEvents). I did this to facilitate richer interactivity with clickable elements – for doing things like fine-tuning click and double click speed thresholds, or in ‘multi-purpose’ buttoned elements, determining whether a user dragged the element (clicked and held the mouse, then dragged off of the element) vs. accidentally nudged it (clicked and released the mouse in different positions while over the element).

    For example… MouseEvent.CLICK is poorly designed, because it considers any long press of the mouse button a ‘click’. In my mind, a click is when a user presses and releases while still over the element, in under X amount of time. Otherwise, it is not a ‘click’ (it is a ‘hold’, or a user realizing they didn’t mean to click a button then moving off of it and releasing…). So I wrap a display object, capture the mouse down and up events, measure the interaction time and if it is under X milliseconds and still over the button I call it a ‘click’. Otherwise I call it a ‘hold’ or so on. Of course, if I generate a custom event (or I dispatch a MouseEvent.CLICK manually) it won’t work to open full screen or the file browser. Now I am stuck using flash’s sticky and crude interaction models if I want clickable elements that open dialogs or full screen.

    So again, our capability to develop fluid user experiences is hampered by somewhat hacked together ‘security fixes’.

  13. Well, I do see the security point here, but as others, I do not believe that blocking the possibility to call the FileReference programatically completely is a reasoned solution (plus it breaks the uploader module used in a software for art schools I did a year ago)

    I would second the necessity of a security dialog (re-)allowing that programatical access, preferably with a checkbox that allows the user to always trust scripts from a site (until consent is canceled).

  14. Why not just simply popup an question before the user gets the file browser. Like “Site http://www.xzy.com” is requesting you to upload files?” then the user can clearly see what site is asking for the file and choose to accept it or not?

    Removing this functionality is just dumb. Then multiupload will be done with Google gears or Silverlight instead and Flash will loose more market share.

  15. @Spocke The decision was not “dumb” and was based on many factors, not all that I can talk about. But automatically launching system dialog windows breaks general web security guidelines. If Gears and Silverlight want to do that then that is their decision. It’s also your decision about what platform to use. If you prefer Gears or Silverlight then you should use it.

  16. @lee: I fail to see how it breaks general security guidelines whats the difference between clicking on a button in a flash movie or firing the same action from script level. I guess you need to know what site open the dialog and that can be avoided with the confirm dialog I suggested.

    But I guess other factors might be that you guys want users to build the whole UI in Flash and not HTML/JS or other technology. :)

    I’m no security expert so I might be missing some important point but if so please enlighten me. It’s just a bummer to see that Flash will be missing this support and the others will have it. I wanted to continue to use scripts like SWFUpload but I guess I need to switch to gears or something else to achieve the same effect now.

  17. @lee: I don’t want to take sides in this discussion, since I am just now trying my hands at an uploader so backwards compatibility is not an issue. My specific need is to allow uploading files of arbitrary size to max-upload-file-size limited Web servers, so I initially welcomed the new FileReference.load() method, only to find out one has no way of reading the file in chunks. I’d like to send the chunks in a loop to a server-side program, which will rebuild the original file at the end. Is there a way to do this without first reading the whole file in memory, therefore limiting the maximum file size? Are you planning to add such functionality in the future, or are there (security?) reasons that discourage this approach?

  18. I’ve been advocating Flash in the JavaScript world and on several Ajax conferences as something to keep an open mind about and showed the YUI uploader and Flickr as great examples to have file interaction without having to go through the pains and hacks that are Comet these days.

    This change makes all these efforts pointless. I think it is a dangerous step for Adobe to take as it will make people go to other technologies for the same task. A small Flash movie was a wonderfully clean and easy solution for a task that is not in HTML as we’ve exceeded the usefulness of HTML. HTML5 and ARIA both are ideas to extend HTML to deliver what we have come to expect from web apps these days. Instead of Flash being an aid to this process we now limit its usefulness as a mediator because of security reasons that could be changed in other ways.

    Take JavaScript alerts for example. I can easily bring a user into an infinite loop with those, too. I was also able to phish information using alerts and confirms, but now that all browser vendors agreed to show the url of the originating script in the alert or confirm box this problem is much smaller. Maybe that would be a good idea to avoid the need for Flash interaction.

    Think about accessibility: you cannot access a flash component in non-IE browsers with a keyboard, so any upload button will become unavailable for blind or mobility impaired users.

  19. What? seems place some transparent swf and misleading user to click them also can be used for doing some bad things.

    As you said “The user seeing the file dialog window does not necessarily know which SWF spawned the dialog”.

    When a transparent swf was placed on web page, people think what them click is actually not what them think and so people still does not know which swf spawned the dialog. I think restrict js programmatically interact with file select dialog doesn’t make sense at all. When a dialog opened and asked to select files, people should clearly know what them do will cause file be stealed by 3rd party.

    I guess a kind warning message to notice people is enough.

  20. Wait, so you’re planning to break SWFUpload? (The only really useful thing Flash does other than video players).

    Could you post instructions for upgrading to Silverlight or something else that fixes this bug?

    Not sure I understand why you’d do this.

  21. @lee
    Hi Lee – what’s your answer to the “this breaks accessibility” arguments that are currently doing the rounds? Do you have an “Adobe approved” solution we can all adopt as web developers to provide a consistent experience?
    Thanks.

  22. [Unfortunately I wasn’t aware of this issue until I read about it on Ajaxian.com. I suspect this may be too little, too late, but here goes…]

    Limiting functionality based on the current event context is a good strategy… but Flash 10 isn’t doing this. It’s doing this only for Flash events, while breaking completely for browser-based (DOM) events. From a security perspective, is there any difference between a user clicking a Flash button .vs. clicking an HTML button? I would hope not, and it would be really nice if Flash didn’t treat these two cases differently.

    The unfortunate downside to this change in security model is that it forces JavaScript developers to implement a Flash UI anywhere they find themselves having to rely on a Flash API that uses this flawed event-based security logic.

    Even if there are technical reasons for why making Flash behave consistently for Flash and non-Flash user events is difficult, surely the right solution is to work with browser vendors to address this problem. Instead, Adobe seems to have rushed out a heavy-handed (and flawed) solution that breaks one of the most common use-cases for Flash on the web: file uploading. It’s pretty disappointing.

  23. @lee: Is there a forum where we can read further on the security concerns this change is designed to address? I understand why you don’t want to go into detail here, but I am curious about the deeper rational behind this decision.

  24. It seems that Flash is focusing too much on security concerns … after all the most secure thing for a user would be to disconnect his PC from the internet. In the same sense the most secure use of Flash in future will be to serve as a pure animation tool.

  25. Its obvious you guys just want the whole interface to have to be done in flash, otherwise you could just as easily prompt saying “site blah blah wants to upload files – will you allow it?”, the same way you do with the camera or microphone.

    I use multifile file uploads called from ExternalInterface via javascript in many sites in a fashion similar to swfUpload. It allows me to use HTML js technology unobtrusively and still allow users to upload multiple files. I implemtented it into my javascript toolit surebert.

    If this no longer works in Flash without a flash UI, I will just ditch it for google gears or silverlight and so will all the developers at the company I work for. I imagine this problem is going to be a huge deal in sites thta use flash ExternalInterface.

  26. That reasoning makes no sense whatsoever.

    1. Repeated opening of a file upload dialog can be easily prevented by placing a checkbox in the dialog “Don’t show this dialog again” if it is shown too often in a particular timespan to the user. Chrome does this for alerts (and other browsers should adopt this approach).

    2. The argument that the user doesn’t know which flash movie the dialog is triggered from still applies even if you require a direct click, because you can overlay a flash movie on top of any content and make it transparent (invisible). It is trivial to “steal” clicks this way.

    3. The argument that opening dialogs programmatically is “bad web security practice” also makes no sense, because alerts can be opened programmatically.

    In short, I strongly disagree with this change, because it offers no real security improvement, and decreases the web’s usefulness.

  27. Why not just leverage the crossdomain.xml file for when the swf file tries to open the file dialog from script? If I’m a developer and need the functionality then I host the swf on my server and I can also access the crossdomain.xml too.

  28. Why don’t they create the concept of “signed Flash movies”?

    Just like you have signed Java applets. We use a signed Java applet for our CMS, to resize images locally and upload stuff. The user only gets a security warning the very first time he runs the applet – after that you can do all you want.

  29. Dude, this is like the dumbest thing i’ve ever heard of…

    transparent FLASH? Really?! like thats very intuitive… or “safe”. I would fire the people that made this decision in a heartbeat… like whatever happened to being able to simply sign your code and get a break.

  30. I believe Adobe will think about this decision again… To many companies wouldn’t be able to use flash on…

    I helped lots of companies turning away from Javaapplets because of the nice Upload abilities of Flash – It was able to keep it userfriendly, simple and small – Adobe will not remove these important features, I hope.

    Appart from that – I can see already that this new restriction is a real disaster for webdesign companies and freelancers worldwide. The fact that you have to of rewrite scripts & applications will cost companies thousands. This is no update will will not be able to use mature parts of websites anylonger. I can think of appx 30 websites I will have to change… guess my boss will not like that :(

  31. A lot of people are upset, but the real question is, is Adobe listening to this outcry, or are we past the point of no return on this “feature” and we’re just going to have to deal with it?

    Any feature that trades out security for user-experience may seem strategically sound but is going to lose in this highly competitive market. You can trade out developer effort for security all day long, but when you start sandboxing flash so that it just flat out can’t do things it used to, because you can’t think of a better way to protect it, you are giving so much fuel to those anti-flash people that most of us spend our lives trying to defend Adobe against.

    I’m such a huge flash enthusiast, but it’s disheartening to see that the community is coming up with plenty of viable alternatives and Adobe is failing to address any of them.

    You think Gears and SL won’t figure out a better more secure way to handle this? Or, you know they will, but you don’t care? Or, you care, but you would rather lose content authors and developers to their ranks than listening to them on this (and other) vital issues?

    That sounds like a formula for failure in this tighenting race for RIA dominance.

    Maybe all the javascript/chrome junkies are right… maybe flash will tumble because it can’t keep up. I sure hope not.

  32. The justifications for this change are weak at best. It’s another case of ‘good idea, poor implementation’. Rather than simply providing a UI for the user to choose if an action was their own, the choice was made to break nearly 5 years of expected functionality. Very, very, very poor project management.

    This gentleman has put together a fantastic blog post on the issue, and calls out the excuses for the change (because I can’t view them as valid reasons, but very weak excuses) for what they are.

    http://www.sitepen.com/blog/2008/09/11/the-state-of-file-uploaders/

    Shame on you, Adobe, for implementing an extremely poor solution to a valid problem.

  33. In many applications I use the library SWFUpload, recently did the updated Flash Player to version 10.

    I am very concerned, I have read of possible solutions, such as a flash of film hidden, but this solution does not find it effective for applications that have been made.

    I understand that this solves a problem of security, but also incurs a problem for people utlizamos bookstores such as the SWFUpload

    It is also worrying that as incovenientes to resolve this, stop future applications

    We appreciate the cooperation we can give

  34. I’m not an expert flash developer, but I wonder if it would be possible to do something like the following:

    1) Throw a full screen transparent SWF shield over the whole page

    2) Capture click events in flash, but let them bubble to the DOM – or fire off DOM events to simulate the actual events

    3) Add any extra “must be clicked” flash functionality. That is, anything the user clicks on in the page gives the SWF shield the chance to execute browse() or other privileged actions.

    Just a thought. Not sure how hard this would be to implement, or how complex the DOM wrangling would become, especially developing for multiple browsers.

  35. Of course, the GOOD thing would be to have worked together with Mozilla and Apple so that the Flash Player can capture the JS events as well as its own events (for IE it’s an ActiveX control so they should be able to do it without MS support).

    Why rushing out such thing that breaks existing apps, while there is NO clear workaround (using a flash button is out of questions since we have many websites with different CSS’styled buttons, and SWF transparency works very badly on Linux).

  36. @Kyle Simpson

    you are talking about the fact that probably Adobe isnt listening to this outcry. So what are our possiblities? Fp 10 isnt out so far…. is there a chance to stop this ??? ;)

    But seriously – there must be a way to let them now how hard this decission is – especially for small companies – they cannot afford to change hundreds of scripts.

    But the whole thing seems so absurd by thinking about the fact that Flickr and WordPress cannot stop it…

    Maby this step is just another try to push Html/JS/Flash Programmer in direcction Flex.

    …such a pity

  37. Phu, I just found this post after noticing that our Ligthbox wasn’t working with the Flash Player 10. After klicking, our data is sent so the server for processing. After that the swf is notified and a second request is made to download the finished PDF. With the Flash player 10 I had to include a second step, where the user has to click so that the download dialog is opened. Does someone have a workaround for this issue?

  38. That is a very stupid changes.
    Do you team want to force the developers use Flash as UI ?
    I will not use Flash any more, I don’t like be fucked.

  39. This is really bad Adobe…we are very frustrating with this broken API.

    Seriously consider to move to JavaScript. We don’t believe anymore in Adobe Air.

    It’s really dissapointing. It’s the right decision of Apple not to use flash lite. How company can depend on this very mediocre API design.

    We are very frustating with this mediocre API design

  40. I understand _why_ Adobe did what they did. I just disagree with _how_ they chose to handle the problem. The “transparent” solution is very hackish. What’s to stop someone from making a full screen transparent swf that does the same thing you are trying to prevent? What are you going to eliminate next: transparency or full screen?

    “The only secure computer is one that’s unplugged, locked in a safe, and buried 20 feet under the ground in a secret location… and I’m not even too sure about that one”
    — Dennis Huges, FBI.

  41. This “solution” to the purported security flaw is serious overkill. Knowingly breaking functionality that has been widely implemented without providing any type of workaround aside from a major code rewrite or an ugly hack seems to not be taking web developers at large, nor the entire web community, into consideration. While I’m sure the intention behind this change was well meaning, in my opinion, the consequences of the changes were not appropriately measured. Even after months of outcry from the developers, no alternative solution seems to have been considered. I realize any changes are probably not possible as Flash 10 is already shipping, but I just felt that more voices needed to be heard.

  42. The URLLoader API is also affected by this broken incompatibility. How come these incompatibilities were not communicated clearly to developers?
    Why are no workarounds announced at Adobe Developer site?

    I fully understand why Google and Apple do not choose Flash as their strategic platform. We are seriously consider not to use flash again in our platform. We really don’t know what will be changed in the future by Adobe that will screw all of our applications.

    Leason learned: Not to put all your egg in one basket, especially a basket that you can not really trust.

  43. Thanks for all the great feedback. I am trying to get more details internally about the reasoning for this in addition to more about possible workarounds. Yes we are listening I can assure you. Your honest feedback is exactly what we need!

  44. The transparent overlay trick is a terrible solution from a usability standpoint. It may work when the user ‘clicks’ on the button but it will not correctly handle keyboard navigation (tabbing to the button and pressing enter). I hope Adobe can provide a better solution.

  45. This is a most awesome BC break, and something that should’ve been announced well before the release. Adobe’s screwing over developers (such as myself) who are getting really annoyed for this and feel F’d in the A. If this isn’t fixed by Adobe (and I suggest we don’t wait for it), I hope someone will come up with a Silverlight solution.

  46. I just want to mention that the Multiple File uploader (and save to database) from ADDT (which ‘was’ a really great behaviour, doesn’t work anymore with FP 10. GRRR

    At least provide a immediate solution/update for this SWF file, since it coms from you, Adobe!

  47. The issue is not whether it’s good or bad. It’s simply LACK OF COMMUNICATION!

    Adobe behaves as though they are a ‘god’ and whatever they do, we have to accept. A simple communication of the issue over a period of 6 months before release would have solved all of these.
    People would have been aware and prepared to change their apps. Besides, after release, nothing was said aside dumping it in the documentation as though everyone reads every line of their docs.

    It’s very bad and they should work on their communication. They live within a community and without the community, their work is useless!

  48. This is ridiculous! We operate countless websites that rely on this functionality. We use swfupload on dozens of websites and to rewrite all of those systems to fix theoretical holes in security is a huge time-waster for a small agency. There’s a huge outcry on the internet regarding this issue already, and if adobe’s response to developers is “shame, you’ll just have to rewrite your code”, then I think that’s testament to their corporate mentality of “we’ll do whatever suits us”. Yes, I agree, there’s a potential security hole. But there must be a better solution that out-right disabling such widely-used functionality. What will I have to rewrite when the next version of the software comes out? Adobe, you need to be careful here – developers drive your business!

  49. Who had this brilliant idea?! Surely someone at Adobe has a way to bring security in without breaking everything that came before. That’s just bad business. And honestly to think anything on the net is secure is idiocy in its purest form. Nothing is impossible in programming…therefore nothing is unbreakable. Come on Adobe! Don’t become the next Microsoft. You’re better than that.

  50. This functionality was the reason we started using Flex. Sadly, I wasted a lot of time on a product that I can’t distribute anymore. What next Adobe? You obviously don’t want to be part of cloud computing solutions.

  51. Security is always balance between usability and safety. To disable something as widely used as this is pure ignorance. I hope that cooler heads prevail and you re-enable this feature because you’ve just broken about every blog and CMS on the web. I’ve already moved from flash to Silverlight to resolve the issue for the solution I’m working on as a result. Whoever is the IS person behind this decision, he has no awareness of the true meaning of security. If people weren’t willing to balance tradeoffs that may represent a risk they would just never install a component like Flash in the first place as, like more Internet facing software, it has a long track record of exploits.

  52. @Keith As SWFUpload did, the solution is not a hard one. The point about breaking sites is valid. If you are building something new, this shouldn’t be an issue at all though. Oh and if you want to use Silverlight, go for it. You’ll be back.

  53. Hi, Tristan Perich and I at http://jellyproject.com/ were trying to make a hidden, javascript file upload for our in browser web development software, but the new flash player 10 does disable all that beautiful work. So just throwing a vote in for another development group looking for flash alternatives, such as silverlight, for this simple, lightweight task. I wish you’d just reenable file uploads, though…

  54. Just to let everyone know, this is moving up to the highest levels of the company so there will definitely be some response from us. I unfortuantely just don’t know exactly when it will be. Trust me, I’m trying as best I can but these types of decisions happen well above my pay grade :).

  55. HTML security guidelines is a lame reason.

    The W3C also doesn’t recognize the XMLHTTPRequest object as being valid – let’s hope that the browser coders don’t take a lesson from Adobe and decide to cut out that object, or else our lovely Web 2.0 AJAX world will be dead.

  56. This is possibly the lamest thing I’ve ever read. Adobe breaking important functionality because of some theoretical security concern is stupid.

    This only once again proves that, thanks to Adobe, Flash is no longer a stable platform for production level use.

  57. @Otto First, it wasn’t a theoretical security concern. There were actually existing attacks that this was based on. Second, you should remove the Flash video from your blog if you are so concerned about it not being a stable platform. I’ll take constructive criticism from actual Flash developers but not from Adobe haters.

  58. I have an application I wrote in Flex builder that downloads a file and saves it on the user’s PC. This is very frustrating because Flash wouldn’t allow me to simply SAVE the information to a .txt file even though I had already downloaded the information into a grid and could have exported it from there. I have to go through hoops to get the data to the PC. The user REQUESTS the information to be exported by clicking on a button… this calls a routine that sends a packet to the server via AMFPHP. The server then dumps the data to a file and sends the temp filename back to the Flash App (once again, via AMFPHP). At this point, it’s suppose to prompt the user to select a filename to save the file under… instead if fails. This can’t possible be done in the mouse click routine, since the file isn’t available on the server yet. Thousands of people are using this program on a daily basis. And since I don’t have an instant solution, it makes me look like an idiot. (maybe I am, but I don’t like to look like one). :-)
    Do you have a suggestion on how to get around this?

  59. We appreciate your efforts in getting this issue addressed. We are all extremely frustrated by what has happened and some of us are expressing that frustration with teeth. Please don’t take it personally.

  60. Ok, Problem solved:

    try {
    fr.download(request,xhDest);
    }
    catch (error:Error) {
    version10WorkAround(xh);
    }
    In the workaround routine, I pop up a window with the following message:
    Security Alert
    This application is trying to export data to your PC.
    This Flash version requires you to Confirm this is OK.
    [OK] [CANCEL]
    I then define a mouse event routine:
    exportOK.addEventListener(MouseEvent.CLICK, exportOKClick);

    When the user clicks on the exportOK button, it calls this routine.
    private function exportOKClick(event:MouseEvent):void
    {
    In this routine I do what I originally tried to do and it works
    }

    Note: This will NOT work by simply defining a CLICK=”exportOKCLick()” in the MX code.

    Sorry to bore everyone that knows how this all works…
    There are many of us that need more of a hint and
    this code should help them out.

    John

  61. Hi, first of all sorry for my bad english.
    Well, it’s good to see that i’m not alone. I’m a freelance flash programmer and today was simply one of the worst of my life! I have my own flash-based CMS, and one of the core feature is a multiple file upload/download system.

    My customers are moving to fp10, my application stop working, and they call me telling “hey, file uploads feature is not working anymore! Do something!”.. I’m desperate!

    I understand that security is a big concern but, personally, i truly need a workaround for this.

  62. I think the change is well justified. However, the reasoning (meeting HTML security guidelines) causes me to reason that the security restrictions should have been in place to begin with. There could be more care taken with the power we are given. At least to better prevent it being taken away in the future.

    It would also help to include navigateToURL and any other functions that were missed as part of the “changes that may require action” article…

  63. Wow.

    Freaking wow.

    I can understand the ‘need’ for the change. The implementation of the ‘fix’, however, is pretty weak.

    I use fileref.download to download a file that is created when the user clicks on the download button.

    To work around this I have to ask the user if they really want to download it…bad user interface design.

    If you could somehow track through the HTTPService call, that might be better but wow…this sucks.

    G-Man

  64. Hey Lee,

    Thanks for caring about the community and detailing this in the post. We found out about this after getting scattered reports from testers this morning. If there’s any way you can connect and help us through the issue, we’d appreciate it a ton. thank you!

    -jlb

    jason [at] publictivity.com

  65. This is simply another case of: “give web developers a useful feature, and when the feature causes so-called security issues, don’t fix the feature, just take it out entirely.” And it seems to be the method of the day. You CAN have all the power with all the security, but only if the developers (in this case Adobe’s) have half the intelligence that even me, without so much as a computer science degree, find to be common sense.

    My small business, which has been developing a very comprehensive Ajax windowing system/web desktop/content management platform, really can’t afford the time needed to cope with a radical change like this. You’ve made it hard on us, the developers, and added an extra step of complexity for my end users. This is entirely unacceptable.

    Kicking myself for getting in bed with an evil proprietary product like Flash to begin with.

  66. @John Well since you’re such a genius, tell us how we should have resolved the issue. The workaround for this is VERY easy if you would actually listen. But you’re a Flash hater so I’ll be happy if you find another technology. Have a nice life.

  67. I just fixed my Actionscript 2 upload code so it works on flash 10. Was really easy to do, I just moved the function calls into the onRelease event handler.

    But I understand that its a pain in the ass for some to fix some old flash code.

  68. I’m a .net developer from China. In out project, we used filereference, and it dosen’t work now…., so I have to rewrite the code… and why adobe do this … it’s really bad for developers to use flash …

  69. Hi Lee,

    We are using a flash-based file upload for Stixy. I need to update our flash movie and a bunch of javascript next week. It would be great if I could get some support from you to make the transaction as seamless and smooth as possible.

    Regardss,
    /jonas höglund

    jonas [at] stixy.com

  70. Hi Flash told me to update to their new release earlier today and now all the programs I used to watch online are completely fucked up!!! What the fuck happened, I thought updates were supposed to make it work better. All the video slows down while the sound keeps running and then the video needs to catch up so it skips. It is basically impossible to enjoy the television programs that I used to watch on the Fox website. I do this because I work during the hours these programs come on and I would watch them after I got home from their website. Thanks Flash Player, Thanks for nothing!!

  71. I understand you have a leading role in protecting end users from harm. But you should be at least just as concerend with already build applications, that in some situations, can be at least! as harmfull to people that rely on them.

    Are there any channels to announce changes in upcoming Flash Players to Flash developers? Is there something like a centralized build plan for Flash, that documents Flash thourougly, and displays upcoming changes in detail, that for example first were suggestions which now made it to the main plan. Onchange we like to receive an email.

    We developers, as participants needs their piece of documentation too, and learn as good as realtime what is being evangelized. We should be notified about changes, upfront, and not as an afterthought. You can not just expose and give us, and so our clients, functionality to build upon for years and then suddenly take it away only with a notification about you being aware that some applications will be broken.

    My usggestion is: You decide what a particular Flash Player version is going to be, but freeze that plan a reasonable time ahead, lets say 4 months before launch, so we developers have time to make modifications to existing software, so it keeps on running.

    You invite us developers to rely on you, and we do, and in turn we invited our clients to rely on us, so be reliable for us as we like to be reliable for our clients.

  72. First of all the FP10 security changes are very vague. So does it mean that I have to have the browse() call inside a mouse or keyboard event handler only??? Or can it exist in a method later in the callstack which is still called by my event handler? Also, what if in my handler I call browse() in a delayed interval? Does that count or not?

    Also, I can still get the upload button to work if I rapidly click on it…so Adobe’s security change still doesn’t even seam to work properly. Try it out and if you rapidly click on it see if you can get the browse() dialog to show up.

  73. what can I say now to mine customers that have alredy buy a service based on that class ? Mr. adobe does not say me about this change?
    …fantastic…
    in AS2 there is no documentation about this.
    what I have to do now? i need to completly redesign an application in as3 ?
    sorry but is not correct
    users are important and their security too, but us workers maybe to…

  74. This is really bad idea. Lots of our software BROKEN after updating to Flash Player 10. I exeperience time losses and clients are not paying for adapting the software, treating your change as our problems.

  75. Puzzle:

    So I got that FileReference.browse() cannot be called from JS.
    But in my case it is not JS calling, but another Flash movie using LocalConnection and it doesn’t work.

    Shouldn’t Flash Player know that I interacted with the first movie and that this movie called the second movie ; and as a result authorize the second movie to run FileReference.browse()?

  76. This security feature sucks… It breaks a lot of uploader out there and one I just wrote a few days ago. What’s the point since one must first select a file to upload anyway… and what’s the point of making the browse method only triggered by a click action if one can engineer a social engineering way to deceive people in doing just that and sending what they dont want to send… please Adobe, be responsible. You’re breaking millions of installed plug-ins and web sites… that’s bad karma it will certainly backfire on Adobe… loss of developers, loss of popularity, adoption of new technologies by users, more advanced javascript and javascript plug-ins making flash useless except for videos.. but wait… video too might become a web standard integrated in all web browsers and scriptable via javascript.. yes no more Flash!! at one point I was a great supporter of Macromedia and had stocks in the company.. now I’d be happy to see alternatives to Adobe’s bloated and proprietary technology…

  77. @JM If you just wrote one a couple of days ago then you should have been aware of the changes. So your idea is to just ignore security because people can be social engineered? Go spread your FUD elsewhere.

  78. Lee,

    1) We’ve been using the excellent SyntaxHighlighter script to show source code in our docs and blogs. SH uses the copy to clipboard SWF technique and its now non-functional due to the change discussed here.

    Note that it’s only triggered when a reader clicks a link labeled Copy to Clipboard so there’s no question the reader requested this action.

    Can you point me to a webpage that shows how to recode to deal with the FP 10 change?

    2) Quite some time has passed and, at least in this blog post, there is no further explanation as you said you were getting from the ‘higher ups’, do you have anything to tell us yet?

  79. Hello,

    I just spent 2 days fixing previously perfectly working applications thanks too all this.

    Can you please provide me the correct Adobe invoice handling department coordinates – I’d like this bill to be paid within 4 weeks.

    Thanks in advance

  80. I feel like a solution to this problem is not going to come. Considering Adobe’s recent layoff announcement I’m guessing there will not be enough people left to work on community issues like this one.

    All said and done, I would rather spend the time it will take to fix this problem instead working on the next iteration of our website which will use Flex based forms. Unfortunately there is still too much to be done before launch and I can’t keep forcing my customers to reinstall Flash 9.

  81. Kyle (#26) is absolutely right. This does have a very negative impact and there’s much better ways to solve this issue! In many applications I have been opening a file select dialog in response to user action, but the user action is handled by JavaScript. Replacing the buttons with Flash movies is not an acceptable option for many reasons, most of all being the JavaScript buttons are created by an entire windowing system and they need to have a consistent UI.

    WHY isn’t there an alternative, some way to turn this off? As Kyle and Neil said, why can’t there just be more limits on how these boxes operate when opened from ExternalInterface?

  82. Or how would it be possible to use ExternalInterface for file browsing in FLP 10. For instance I created a flash upload plugin for recordlists of the PHP RAD Framework ATK. The clue was/is, that all html-javascript trigger buttons of a possible very long data list are using only one swf for the upload action manage my ExternalInterface triggered by user actions!

    I never implemented more custom security features then in this programm inclusive file en/decryption on the fly and so on;-)

  83. The above mentioned plugin provides inline upload capabilitíes
    for large recordlists incl. session management item-id and user-id transfer through the flash movie to the backend server. It is strongly secure and uses ExternalInterface and DHTML to provide a convinient UI for extensive web based datamanagement regarding to user actions. Related screenshots are available googleing psycholutions.com

  84. @stevie

    Yes, I tried dispatching a click event from an external interface call. It did not work. Nor did setting a timer to trigger a click event from an external interface call. At least the Adobe programmers were thorough.

  85. I tried every work around possible to get this thing to trigger the file download dialogue without doing it directly from a button and believe me, it’s impossible. It’s a huge pain in the ass because basically we wrote a complicated script so that our flex web client goes and interacts with our server, then our server builds an xml file, and upon response from the server I wanted to make it so that you could download the file in the UI using a loading bar component. (upon receiving the url to the file the server had generated). Unfortunately this doesn’t seem possible so now I am just using the navigateToUrl function and downloading it externally. booooooo. Over 130 people have commented on what a pain in the ass this is and Adobe has done nothing in response. It is just further proof that Adobe is a big corporation that doesn’t really care that much about what it’s customers have to say.

    The only workaround is to pop a button up on a popupwindow right before you’re going to trigger the download and make the user click again. So beat.

  86. Yes, its extreme annoying.

    Our WCM/ERP System relies on inline uploading via ExternalInterface too. So till know we only can work with it (upload files to related database-items) using FLP 9!!!

    There is currently now HR available to rewrite the complete stuff.

    Great. I m exited what will be happen, if we sell our first Adobe AIR Products related to requiring services. Maybe sometime Adobe makes a new decission which will completely smash our business.

    I think therefore we will establish a new paragraph in our terms of use.

    WE ARE NOT RESPONSIBLE FOR DECISIONS OF THE ADOBE COMPANY.
    ANY TROUBLE…;-)

  87. Help I Need to download Version 10 of
    flash player so i can hear my music on myspace
    but everytime i try it say “completed dowload 9.)
    I Need Help!

  88. i too found this problem recently while i was working on a project where the user can download some zip files. There is also a new problem added to the ones mentioned above. when i use the download function of filereference, it shows a warning message in the download dialog saying the file may contain malicious executable files(check the link below to see wat i’m talking about). I’m still searching for a solution for this.
    h**p://www.imageharbour.com/uploads/03200911/TK2C62D5P7DBMO2O.JPG

  89. I work with new Flex project (just a prototype yet). And I knew about the restriction and was sure that will be able to build app. However I was wrong.

    Scenario:

    1) User selects file – no problems, just open browse from click handler.
    2) User clicks “process” – and we begin. All according to Adobe guidelines: “use event-driven model, do not try to hack async actions to sync”. OK, using events. And – ups… If we started async work in response to user click, when it will be finished and corresponding event fires – we are not able to do restricted actions!

    Again. I used Flash GUI. I made user to initate process with click…

    What I do/understand wrong? It seems that asynchronous nature of the platform conflicts with the model of “user-initiated-actions”. Because no one of async methods can be called in front of restricted API call.

  90. I have a similar problem as Alex do. We have a Flex app and user click a button to start a process. The process is a async process and at the end of the async process, we will get an completed event. The logic requires the app to start a POST request to the server to start a file download right after the async process is finished (because the async process provides the data for the POST), and because of this security restriction, the file download cannot be started because flash think that the initiator of the file download process is not from the user action. But, in fact, it is really from a user action.
    Does anyone has any workaround on this? I have tried to cache the original mouse click event and re-dispatch it after we get the complete event from the async process and that does not work. Does it really mean that in between the file download and the user click action, there cannot be any async processing?

  91. I’m still VERY confused by these UIA restrictions. All I want to do is post some data to the server, get a response (including the ID of the new record I’ve added to my DB) and then do another request (in this case saving an image with the ID in the filename) back to the server. This worked fine until v10 – but now we’re only allowed one call per user action (e.g. mouse click or key stroke). Insane!

  92. “HTML security guidelines do not allow the opening of file dialog windows without user interaction.”

    WTF do you think clicking a link via ExternalInterface is? I suppose that could not necessarily be a user action and an automatic script…Of course the user of the computer still needs to select an actual file… It’s not like JavaScript or Flash could ever just go and upload any file from a user’s computer that it wanted to just for visiting the page.

    How about this one? Using LocalConnection to fire the event? … THAT IS MOST DEFINITELY a direct/in-direct user action. A second swf that uses the click event to call the browse() or load() method in the other swf. Two swfs on the page.

    Reason? One swf is perhaps a “browse for file” and the other, a “submit.” I’m pretty disappointed that these new security changes dictate application work flow and limit visual layout. It’s just simply wrong. I wish Adobe would be smarter about this.

  93. This change unfortunately prevents a clean Flash uploader integration with a web application framework such as Cappuccino since you wouldn’t be able to use a regular button.

    Furthermore, a transparent overlay would not provide an optimal user experience since the button would react differently in regards to keyboard shortcuts, keyboard navigation, cancelled clicks (mouse down followed by moving the mouse away) and visual feedback (the button looks depressed, the action occurs when the button is released).

    As many of these comments point out there is no security benefit to this new behaviour since transparent overlays can still trick the user just fine. This is unfortunate since upload support is one of the few remaining Flash advantages today with the HTML video tag and the canvas tag replacing the more traditional uses.

  94. There is a simple solution to this, just don’t use a regular file dialogue pop-up box, make an AS3 based one which runs only within the flash file/area. This way nobody can pop up tens of thousands of dialogue boxes on a person’s computer because they would all simply be bound to the flash stage area. This would then allow us all to freely create our own save and import features.

    I realize the need for security by flash, but even a work around as simple as requiring a user to allow/disallow certain features via dialogue box on SWF load would be far superior and more of a welcome than existing methods which are extremely annoying(Limitations on file browsing, many features only available in flex. Also, cross-domain policy files which are a complete nuisance and waste of time imo, they should just ask if the user wants to allow outgoing connections from current SWF file and if so, each consecutive connection attempt towards a different IP should require validation.)

  95. ActionScript 3?

    Never herd of it. ;)

    Never will.

    I need to brainwash myself into never even seeing such an appalling move my Adobe.