Adobe’s Mike Chambers has an article and sample code for calling native operating system APIs from AIR applications, which use the Flash runtime outside the browser.
I took a look at the native side of the code, which is written in C# and compiled smoothly in Visual Studio 2008. The concept is simple. Instead of launching an AIR application directly, you start the “Command Proxy” application. The Command Proxy launches the AIR application, passing a port number and optionally an authorization string. Next, the Command Proxy creates a TCP socket which listens on the specified port. The AIR application can then use its socket API to send commands to the Command Proxy, which is outside the AIR sandbox.
It’s a neat idea though Microsoft’s Scott Barnes gave the design a C- on security grounds. He clarified his point thus:
The communication channel between the command proxy and AIR application looks like a potential vulnerability. One of the things application developers should worry about with security is insecure cross-process communication mechanisms hanging around on someone’s machine. For example if a process listens on a named pipe, and that named pipe has no ACLs and no validation of inbound communication, the process is vulnerable to all kinds of attacks when garbage is sent down the pipe. In the example on using the command proxy how do you secure it so that it doesn’t turn into a general purpose process launcher?
Barnes has an obvious incentive to cast doubt on AIR solutions (he’s a Microsoft RIA Silverlight evangelist), but nevertheless this is a good debate to have. How difficult is it to do this in a secure manner? It is also interesting to note the opening remarks in Chambers’ post:
Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application. Unfortunately, neither feature will be included in Adobe AIR 1.0.
This is really one feature: access to native code. I remain somewhat perplexed by AIR in this respect. Is the inability to call native code a security feature, or a way of promoting cross-platform purity, or simply a feature on the to-do list? I don’t think it is really a security feature, since AIR applications have the same access to the file system as the user. This means they can execute native code, just not immediately. For example, an AIR app could download an executable and pop it into the user’s startup folder on Windows. That being the case, why not follow Java’s lead and provide a clean mechanism for calling native code? Adobe could add the usual obligatory warnings about how this breaks cross-platform compatibility and so on.
Firstly, Not sure what Silverlight has to do with AIR? they are from two different ends of the spectrum and if AIR were to simply disappear tomorrow it would make little difference to Silverlight? (The two Mike’s have backed this and it’s probably a pet hate for both our brands)
Secondly, I’m actually a “RIA Evangelist” not Silverlight. In that I’m not tied down to a specific product. I focus my energy on places that aren’t being discussed as I find other colleagues blogs cover most ground well.
Thirdly,
I think it’s a fantastic conversation to have. I am foul with myself and also at some folks for letting the conversation get out of hand, as I think it’s a bold step in the right places, and I in some ways kicked the beehive over in order to get honey. Yet, the approach does concern me and still does. Being right isn’t about being popular..
Mikes a brilliant guy and I have enormous respect for his approach and think his intent was honourable.
–
Scott Barnes
RIA Evangelist
Microsoft.
Thanks for the comment Scott. I’ve amended the job title.
Yes, I realise that AIR and Silverlight do different things. Nevertheless, there are areas of overlap – both are broadly “RIA”, both are strategically important to Adobe and Microsoft respectively.
Tim