CommandProxy : It's cool, but is it a good idea?
I posted some proof of concept code the other day, which showed how to create a local command proxy to proxy commands from AIR applications to the underlying operating system. This was some code I put together in the fall during a European user group tour as a way to see if it was possible to extend the AIR runtime (after lots of requests on the tour from developers asking how to extend the runtime).
One of the reasons I posted the code, was to generate a discussion not only around the solution and its feasibility, but also on other possible solutions. While there was a lot of positive feedback in the comments, there was not much focus on whether this is actually a good and / or feasible idea.
Scott Barnes, a Microsoft evangelist touched on one of the potential issues, raising concerns about security. Unfortunately though, his posts went off on a tangent and didn’t really explore any of the issues in any depth.
So, I wanted to make another post to discuss some of the potential issues with the command proxy model, in the hopes of spurring additional thought and discussions on it and other possible solutions. I will touch on potential development, deployment and security issues.
How feasible is it to actually build and deploy an application that uses a command proxy? My thoughts are that in most cases it is not feasible due to the complexity of development and distribution, although there may be instances where it could be useful. Development is made more difficult by the simple fact that you must now develop in at least two languages and development environments. From a purely code writing standpoint, this may not be too big of a problem if you are familiar with both the languages. However, developing and debugging would be an issue, as you would no longer be able to easily debug your application directly from Flex Builder, but would rather have to either modify your code to run from Flex Builder, or deploy to the desktop and test your code as it is launched from the proxy.
The second main issue is that you cannot use the AIR install mechanism to install the application (although update would work in most cases). This is because you need the user to launch the command proxy first, and not the AIR application and the AIR installer sets up shortcuts to the AIR app. It might be possible to do some hacks to place another shortcut to the command proxy, but this would probably not be that robust of a solution, and could potentially confuse the end user.
The solution to this is to write your own native installer that:
- Installs the AIR runtime (if necessary)
- Installs the AIR application
- Removes shortcuts directly to the AIR application
- Installs the command proxy
- Creates shortcuts to the command proxy
Now, this is something that is doable, but is probably outside the reach of most web developers who are used to working with ActionScript and JavaScript (and who in general have not had to build any installers in the past). Note though, that it would be possible for someone to write a tool that automated the process and created the installer.
Finally, if having your application run cross platform is important to you, then you need to do additional testing to make sure your native code works across your supported platforms. I found out how difficult this could be with the command proxy example code. I wanted it to work on Mac and Windows (using Mono on Mac), but discovered that some of the .NET functionality simply did not work on Mac (in my case the code for screenshots). Since this was just proof of concept code, I moved forward, but if it was production code, it would have been a significant roadblock for the project.
The final issue which needs to be discussed is one of security. Scott Barnes touched on this, but again, then really go into any depth or details. Regardless, I will bring up one potential issue, and I welcome any additional discussions / issues in the comments.
Command Proxy is essentially a local proxy tied to a specific application (the AIR application which the proxy launches). When the proxy is run, it generates an auth token, which is passed via the command line to the AIR application. The AIR application then passes that auth token back to the proxy anytime it wants to run a command.
)
If another malicious application could somehow get that auth id, then it could then run commands through the command proxy (assuming it could also get the messaging format for the commands). The current proof of concept code has the AIR application communicate with the proxy over a socket connect (on a random port). It would theoretically be possible for another application running on the user’s system to sniff the data on the connection and grab the auth token. One solution for this would then be to encrypt the communication from the AIR application to the proxy. This could be done via encrypted sockets (not currently supported in AIR), HTTPS communication, or other custom encryption. Of course, since the malicious application is also running locally, it could try and sniff the memory for the AIR applications and / or proxy and thus steal the auth token.
However, lets think about this for a second. If the malicious code is running on the user’s machine, and can do things such as sniff local traffic and memory, why would it try and exploit the command proxy? Why wouldn’t it just do whatever bad thing it wanted to do itself? i.e. at least in this case, it seems like the primary security issue is not that the AIR application / command proxy communication might be able to be sniffed, but rather that somehow some other malicious code was already on the user’s system. I am interested in other’s thoughts on this.
The way the example code is setup now, it contains a generic exec command and screenshot command. If your application only ever needs to launch one application, then the path to that application could be hardcoded in the proxy (meaning for example, the worst that could happen is a malicious app could load the application). That is not to suggest that there is not a potential issue, but rather that any command proxy code can be coded to do only what you need it to.
Again though, the code I posted was just a proof of concept to generate though and discussion (which is why I didn’t release any binaries). I would be curious in hearing any other thoughts on potential development, deployment and / or security issues with the model, as well as potential alternatives.
Finally, the long term solution (and plan) is that the AIR runtime itself provide the low level functionality needed by developers. AIR 1.0 already provides access to the underlying operating system via number of APIs, and the scope of those APIs will only expand with each release.
