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
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