AIR Security

We just shipped Adobe AIR 1.0, check it out at http://www.adobe.com/products/air!

AIR lets web developers–whether HTML/AJAX, Flex or Flash–build rich and complex applications that run on the desktop. From a security standpoint, the “desktop” part of that is the key.

If you come from a web development background, you find that desktop applications differ significantly security-wise from apps based in the web browser. Desktop applications have direct access to the local system (insofar that the operating system permits, of course), but in return they must be explicitly installed by the user or system administrator.


Adobe requires all applications on Adobe AIR be digitally signed, by either a self-signed or commercial certificate from a trusted Certificate Authority (CA). For the end-user, when an application is signed with a self-signed certificate the installation experience will reflect that the publisher is unknown, giving the user pause as to whether they should continue. So, when developers use a commercial certificate from a trusted Certificate Authority users are more likely to install applications. We’ve worked with trusted Certificate Authorities such as Thawte (www.thawte.com) to make it easy to get a digital certificate for code signing. We’ve also enabled administrators to block applications that do not have a signature that chains to a trusted CA.In AIR, we provide a consistent installation experience for all of our supported platforms (Windows, OS X and soon to be Linux). This means that the user is always presented with the same installation dialogs regardless of which application they are installing or the particular platform that they are on. For some additional information on the AIR installation experience see my previous blog entry.Just because AIR applications are bound by the desktop security model, it doesn’t mean that you don’t have to think about security. On the contrary, desktop applications require as much consideration as web applications. This is something we put an enormous amount of effort into. For example, AIR applications have multiple security sandboxes to allow them to interact safely with content on the web.For an overview of the Adobe AIR security model, see the AIR Security White Paper which outlines the security model and provides information on the security sandboxes available to Adobe AIR applications. We’ve also put together another white paper which specifically details the enhancements to the HTML security model to enable applications on the desktop.If you are developer looking at AIR, a great next step would be to check out my introduction to the AIR security model at the Adobe Developer Center.

2 Responses to AIR Security

  1. Rey Bango says:

    “Adobe requires all applications on Adobe AIR be digitally signed”This statement was questioned yesterday and it was mentioned later that it wasn’t a requirement. Did something change?[Lucas:] Hi Rey, good question. The answer is that it is a bit of both. All applications must be signed, by either a self-signed or commercial code signing certificate.To the user, only applications signed by a commercial cert will appear to be signed, and will display the publisher information in the installation dialog. Self-signed certificate will appear as publisher “Unknown”.So why support self-signed certificates at all? For a few reasons:a) self-signed certificates are still valuable in certain workflows, such as validating updates to installed applications have been signed by the same certificateb) enterprises can use self-signed certificates to manage internal approval and distribution of applicationsc) developers can use self-signed certificates for development and testing

  2. Rey Bango says:

    @Lucas: That makes good sense. It sounded originally that you were saying that AIR apps were required to be digitally signed from, say, Thawte, in order to be distributed. Thanks for the info.Rey[Lucas:] Thanks for the feedback, I have updated the posting to clarify signing options.