In-browser AIR functionality
Published on November 19th, 2007 by DannyT. Filed under Adobe AIRSo, after my previous post moaning about how I think AIR functionality would be ideally suited in-browser, I did a little digging and it turns out you might kind-of be able to acheive some of it!
I’ve yet to test the feasability of this, but according to Jeffry Houser, local connection works between browser loaded swfs and AIR swfs. What this potentially means is you could create an AIR application that does nothing except run as a local service in the system tray and merely exposes AIR functionality through localconnection.
Take the example of Buzzword in my previous post, they could create an AIR application that does nothing except for offer a simple “saveLocal” function. The online version could then check through localconnection to see if that AIR application is available and if so offer users the facility to save their document locally (obviously if localconnection fails then it offers only the online version).
Jeffery raises concerns on the security side of things, but I’m not so sure that it is a problem, it comes down to the age old point of educating users to just be vigilent in who they download applications from.
I’m going to see if I can come up with a proof-of-concept for this but unfortunately have a lot on right now so if anyone else feels like having a go feel free and let me know how it goes.
Mike Weiland
November 19th, 2007 at 4:55 pm
I’ve used this concept before, I’ve used Director with embeded Flash movies do the heavy lifting on the client side and localconnections between the SWF running in a browser. I haven’t tested this with AIR, but the concept shouldn’t run into any roadblocks.
Ethan Malasky
November 22nd, 2007 at 7:15 pm
The LocalConnection pattern is already in use by some AIR apps you’ve seen. Finetune uses it, for instance, to transfer a selected radio station from the browser page to the desktop player.
As far as security goes, you’re half-correct. Users still (always) need to be vigilant about whose apps they install. But when applications themselves start offering services to other content, the security burden on app developers increases.
Clearly, it’s not impossible, but it’s something developers need to consider. Who is going to be able to call your “saveLocal” function? How do you verify the caller’s identity? The level of verification required changes, depending on the level of functionality being exposed. How can your exposed function be abused? Caller-provided paths or filenames are extremely dangerous, as they can be used to give an attacker local access. And on and on.
All these concerns can be addressed. But development is likely to be slow, because the price of getting it wrong is so high.
DannyT
November 23rd, 2007 at 12:50 am
Thanks for the info Ethan, I think the security aspects are going to be something that’ll continue to crop up now AIR gets us onto the desktop. I’m still interested in the approach and will try to mock-up a prototype when I get a chance.