One of the concepts that is important for you to understand from the get-go is application security. Desktop apps get permission in terms of what they can do and cannot do from the OS and the available permissions of the cur- rently logged-in user. They receive this level of access because the user needs to explicitly install the app — effectively telling the computer that the user trusts the app he or she is about to launch. As a result, native apps have access to read and write to the local file system and perform other typical desktop functions.
Web apps, however, are far more restrictive because of the potentially mali- cious nature of scripting. Consequently, Web apps limit all local file access, can perform web-based actions only inside the context of a browser, and restrict data access to a single domain.
Playing in sandboxes
The hybrid nature of an AIR application puts it somewhere in between both of these traditional security models. On the one hand, with AIR, you create a desktop application that runs on top of the normal OS security layer. Therefore, it can read and write from the local file system. However, because AIR uses Web technologies that, if unchecked, could be hijacked by a malicious third party and used in harmful ways when accessing the local system, Adobe AIR has a security model to guard against such an occurrence. Specifically, AIR runtime grants permissions to each source or data file in an AIR application based on its origin and places it into one of two kinds of con- tainers it calls sandboxes.
The application sandbox contains all content that is installed with the app inside the home directory of an application. These are typically HTML, XML, JS, and SWF files. You can think of files inside the application sandbox as
the equivalent of premium frequent flyer members that get full access to the special airport restaurants. Only these files have access to the AIR API and its runtime environment.
Adobe AIR does allow you to link in other local and remote content that is not inside the root directory of the application, but places that content in a nonapplication sandbox. Content inside the nonapplication sandbox is essen- tially handled from a security standpoint just as a traditional Web app is, and is not granted access to the AIR APIs (see Figure 1-3).
Additional restrictions within the application sandbox
AIR places strict restrictions over script importing of remote content and the dynamic evaluation of JavaScript code — even inside the application sandbox. Many JavaScript programmers use the eval() function as a way to generate executable code on the fly. However, if you’re loading data from a remote source, a hacker could potentially inject malicious code into your app without your knowledge. To prevent these security vulnerabilities, eval() and other dynamic code methods are prohibited after the onload event occurs.
As it is in Web applications, code being executed inside the application sand- box is free to load data using Ajax (the XMLHttpRequest object). However, any content received using XMLHttpRequest is treated purely as data and cannot be dynamically changed into executable JavaScript code (such as by using eval()).
Digitally Signing an Application
Because users open their computer to an AIR app, their trust in the software publisher is crucial. They need to know that you won’t do bad things to their private data or trash their hard drive. That’s why digital signing is a required final step of the AIR application development process before you can deploy it.
To provide a degree of confidence and trust, an AIR application must be signed by a code-signing certificate. There are two types of certificates:
✓ Self-signed certificates: “Do-it-yourself” certificates that you can gener- ate with the AIR SDK and then sign your app with. Self-signed certificates provide a minimal degree of trust, but because you have no outside confirmation that you are who you say you are, you are, in effect, tell-
ing users, “Hey, you can trust me. Really. Really!” When users install an app with a self-signed certificate, they are warned that the publisher is UNVERIFIED (see Figure 1-4).
Self-signed certificates are intended mainly for internal use when debugging and testing your app.
✓ Commercial code-sign certificates: These certificates are purchased from a certification authority (CA), such as Verisign and Thawte, who authenticate your identity. A commercial certificate enables you to
be considered a “trusted” publisher and gives users a much higher degree of confidence in working with your app. A commercial certificate enables users to verify the corporate or organizational affiliation of the application and ensures that users can say, “They are who we thought they were!” (see Figure 1-5).
Commercial certificates, however, are not cheap. Fees are generally around
$300 for one year and $549 for two years for a code-sign certificate.
Source: Adobe AIR for Dummies