Adobe AIR supports enterprise deployment. There, I’ve said it. We’ve had a bit of trouble getting this message out, so I wanted to be clear about this right up front.
Now, before anyone jumps all over me for this one, I’m also sure we could do a better job of supporting enterprise deployment. If you’ve deployed AIR in an enterprise setting and have thoughts on what we could do better, please send them our way.
If you aren’t familiar with AIR’s enterprise support—and, as I said, you’re probably not—here’s what you can do now, in AIR 1.0:
- You can deploy AIR and AIR-based applications via enterprise deployment tools like Microsoft SMS and IBM Tivoli,
- You can disable auto-update of both AIR and AIR-based applications, and
- You can configure which applications, if any, AIR will permit to be installed.
I’ll dive into more detail on some of these items in future posts, but there’s one more thing I want to cover now. If you want to deploy AIR in an enterprise setting from a centralized server of some sort, instead of deploying it from Adobe’s download servers, then you’re redistributing AIR. We typically allow this, but you do have to sign a redistribution license in order to be granted the necessary rights. See the redistribution site for further information.
Oh, and feel free to spread the word!
Commenter Tek suggests that AIR should warn the user each time an application tries to do something potentially dangerous, like access the file system.
Here’s just a few reasons why we don’t do this:
- It’s annoying. No one likes to deal with these dialogs all the time. And if everyone just suppresses them, then what’s the point?
- It’s insufficient. Accessing the file system alone or the network alone is often ok, but approving the combination is sufficient to let someone upload all your data.
- It’s unanswerable. Unless you wrote the application or studied its source code, you probably don’t have enough information to answer, anyway.
- It’s broken. If you say no to any of these dialogs, the application will most likely stop working.
Ultimately, choosing to run a desktop application is about trust. Virus scanners, firewalls, and the like don’t ask you about what applications are doing because they’re trying to protect you from those applications. On the contrary, they’re notifying you about behavior that might be the result of software you didn’t install. That’s an altogether different question: if you didn’t install the software, say no!
[Update 2009-07-30: This dialog has been revised for AIR 1.5.2.]
If you’ve ever installed an Adobe AIR-based application–you have installed one, right?–then you’ve probably noticed the installation screen warning that the application you’re installing will have unrestricted system access. I’m frequently asked by developers how they can get rid of this warning, lest it scare off some of their customers. The short answer: you can’t.
When we developed the installation screens for AIR, one of our major goals was to make sure they were informative. Installing an application on your machine is a big deal. You’re trusting code that someone else wrote to not steal or destroy your information. If you’re going to do this, you ought to be well-informed regarding what you’re installing and what risk you’re taking.
The “unrestricted system access” warning is there to make sure you know that, once you install this application, you’re trusting it to behave. No one else is going to keep an eye on it for you.
Some future release of AIR might offer to perform this function for you–that is, restrict the system access of certain applications. With that capability, you might make different decisions about which applications to install. But that’s all theoretical for now. Right now, all application are unrestricted. Even if they don’t need to, say, access the filesystem, they still can. So that warning shows up every time.
How do you know, then, which applications to trust? I recommend making that decision based on the publisher’s identity–the other major piece of information on that first installations screen.
As you’ve likely discovered by now, applications that run on Adobe AIR are distributed via AIR files. While the AIR file format is unique to Adobe AIR, it’s mostly made up of familiar parts. Here’s a quick tour of some of its salient features.
- AIR files are ZIP files. Note that the converse is not true; not every ZIP file is an AIR file. In general, any tool that can read ZIP files can be used to inspect, unpackage, etc. an AIR file. Making an AIR file, however, generally requires a purpose-built tool to handle the AIR-specific requirements.
- AIR files do not protect against discovery. That is, anyone with access to an AIR file can easily read its contents; there is no encryption of any kind. Individual files within the AIR file may be compressed, and typically are if they’re a text-based format to begin with. As noted in the previous point, that’s hardly a barrier to inspecting their contents. If you want further protection against discovery, you need to run your source through on obfuscater, etc., before packaging.
- AIR files do protect against tampering. An AIR file must contain a valid signature covering the entire contents of the file. If the signature isn’t valid then the file isn’t either. Signatures are stored in the W3C-recommended XML Signature format.
- AIR uses a naming convention to keep user-provided files separate from those required by the format itself. Format-specific files, such as the application descriptor and signature, are stored under the prefix META-INF/. (This convention is borrowed from the JAR file format.)
Most of the time you don’t need to know any of this, as your tools (adt, FlexBuilder, etc.) will do the heavy lifting for you. All the same, sometimes it’s fun to know what’s going on under the covers.