1 Reply Latest reply on Oct 19, 2009 8:49 PM by Jeff Swartz

    The remote swf problem .. chasing the rabbit down the hole..

    tictox

      Hi all

       

      The firm I am employed at was recently was commisioned to upgrade some of our existing swf2exe applications to the AIR platform , which offers cross platform deployment. It was an exciting decision and I jumped into the development with glee , that was until yesterday when i was sadly intoduced to the security sandboxing issues with remote swfs. I have been searching the web now for the last  24 hours now and have seen the (URLLoader load bytes push into Loader.loadBytes workaround ) in many formats , and tested it , but also found posts that mention this technique not working with later builds of AIR from 1.5.1. I then tried to source a definitive response from any adobe documentation expanding on this restriction and the only disclaimer of sorts for forward compatibility issues is this text , This is from the AIR 1.5 PDF http://help.adobe.com/en_US/AIR/1.5/devappsflash/devappsflash.pdf :

       

      "Note: In a future release of Adobe AIR, this API may change. When that occurs, you may need to recompile content that uses the

      allowLoadBytesCodeExecution

      property of the LoaderContext class."

       

      the tricky word in this copy is "may" .. this API MAY change .. you MAY need to ..

       

      I have also read about sandbox bridges , but this option has restricted functionality regarding argument types (a glorified localConnection it seems ) , and is really not an option when you are wishing to plug your remote swf into your application with full rights to all your code.

       

      I then went to the AIR TEAM BLOG and watched the video presentation on AIR 2 , hoping to hear that this problem has disappeared .. nope it remains.

       

      This raises a great big question in my mind :

       

      What is the point of having software signing and certificates to prove or establish a trust relationship between a software vendor/distributor and a user/client  , when the application itself will never give you this trust? anybody? Does this whole baked-in security layer not render the software certification process absolutely redundant? ie.. why would I ever waste the money to get a certificate when it grants me no more privileges that a mention on the installer splash page and from there get treated in the same manner as a uncertified vendor?

       

      The last page i visited introduced a framework that would download files and an xml file or sorts that defines trust relationships  via checking the signing of the swf files in some manner (I briefly had a look at the code not sure how it does it yet) , but then proceeds to execute the same old URLLoader to Loader implementation i refer to above.

       

      I have reached the bottom of the rabbit hole!

       

      It is critical that I have a solid response from  Adobe regarding the current URLLoader security bypass methods functionality in the latest builds of the AIR runtime and its forward compatibility timeline. IF this is the only solution and its not forward compatible , then I cant really use AIR as a desktop deployment platform for modular applications and will have to respond to our client with the findings of the last 24 hours.

       

      Many thanks to anybody who can shed more light on this matter

       

      Ian Pretorius

        • 1. Re: The remote swf problem .. chasing the rabbit down the hole..
          Jeff Swartz Level 3

          Sorry for the delay in getting back to you.

           

          The restrictions on content in non-application sandboxes allow AIR developers to write applications that can safely load content from arbitrary internet sources. When writing an application that loads content from an arbitrary source (such as foo.com or someRandomURL.com), you don’t want the content to have access to the AIR APIs. The sandbox bridge mechanism does allow you to expose pre-defined application functionality to non-application sandbox content.

           

          A signed AIR application establishes identity so that the end user can determine whether they want to install an applicatio, which may have access to functionality that may have security implications (such as access to the file system APIs). However, AIR applications do observe security restrictions; and limitations on non-application sandbox content is one of these limitations.

           

          Although LoaderContext.allowLoadBytesCodeExecution may change n the future, existing applications will continue to work, even if the installed version of AIR is updated.If we change the API in the future in AIR version X, and the app is recompiled against the AIR version X SDK, you may have to change some code to use whatever replacement API we have put in place. If you continue to compile against the older SDK, no changes will be necessary.

           

          Please let us know if you have a specific requirement for which LoaderContext.allowLoadBytesCodeExecution or the sandbox bridge mechanism does not suit your purposes.

           

          Jeff Swartz