You can use this feature to transition from a self-sign certificate used during initial development to a CA-issued certificate purchased later. You can also use it switch between certificates issued by different CAs, or even to switch identities if say, your company is purchased by another.

The feature is straightforward to use: First, package a version of your application using your new certificate. Then, sign it a second time (using the “-migrate” option to adt) using your old certificate. The second signature covers the first, so the original signer is effectively granting permission to the new signer to take over the application’s identity. Note, though, that both certificates must be valid for some overlapping period of time in order to make the transition.

Without this feature switching certificates is disruptive for the end user: the version of the application signed with the new certificate is handled as an entirely different application than the old one. The application can’t even update itself from one to the other, as the Updater API will refuse to see them as related.

With this feature the transition is much smoother, although there are still a couple of rough edges. An application can use the Updater API to update to the new version when using this feature. However, the application’s publisher ID will change during this update, which means that:

The application’s local connection name will change,

The application will no longer have access to its old encrypted local store, and

The application’s application storage directory will change.

Regarding the storage directory, it’s worth noting that you can still access the old one via the File API; you just can’t get to it via File.applicationStorageDirectory.

Applications sometimes store potentially sensitive data. Sometimes the items are obviously so, like store passwords. Sometimes it’s less obvious but still sensitive, like your browser history.

I was recently asked how an AIR application could make sure that sensitive data it stores was cleaned up as part of the application uninstall process. That, unfortunately, isn’t possible.

Not all is lost, however. Instead of depending on the uninstall process, applications that store sensitive data should include an explicit method (e.g., a menu item) for clearing that data. Your browser, for example, probably already has such an option. Users can use this before they uninstall to make sure that data is cleared out. As a bonus, they can use it without uninstall, too.

How to clean up the data? In general, deleting the files is sufficient. If you’re using the EncryptedLocalStore API, use the reset() method to erase it.

In my previous post, I described why installers don’t do per-user setup. Do the same issues apply at uninstall time?

Yes, only more so. First, as with installation, the user directories may not be accessible to the installer. This can happen, as I’ve mentioned before, when using Windows roaming profiles.

Even if you could access the user directories you may not get to run any code to do the cleanup, anyway. On Mac OS, for example, the preferred uninstall method is simply dragging the application to the trash. There is no uninstaller to do any work.

Finally, it isn’t always clear what you should clean up, anyway. Clearly user documents should not be removed. What about preferences? If the user is done with an application forever—and they’re not going to reinstall it—then delete the preferences might be reasonable. But what if the application is going to get reinstalled right away? Or re-installed in a week or a month? Should the user preferences persist across the uninstall/reinstall? It isn’t clear.

From an end users’s point of view, an installer is all about getting an application from a source (a DVD, or maybe a downloaded file) to the point where it’s ready to run on their machine. Why, then, do so many applications have more to do the first time a user runs them? Why doesn’t the installer just get all of that stuff out of the way up front?

To understand why, you first need to know a bit about how file ownership and permissions are organized on those machines. Along the ownership/permission access, you can generally divide files into three categories:

Owned by the administrator and read-only to users. This category contains the applications themselves.

Owned by a user and writable only by that user. These are all of your files.

Writable by all users. These are “shared” files; this category isn’t much used in practice.

Items in the first category are written by the installer; after that, they’re not touched except for updates. Things like user preferences are all stored in the second category.

The second category contains one set of files for each user. For example, each user has his own set of preferences, accessible only for that user account.

Now, let’s imagine that an installer wants to both install the application (of course) and set up the initial user preferences. Clearly the application is written to files in the first category. The preferences file has to go in the second category. But for which user should those initial preferences be written? Writing them for the user running the installer might make sense and might work. But writing for the other user accounts doesn’t work. There are a variety of reasons for this, but on particularly interesting one occurs when using roaming profiles on Windows. In this case, additional user accounts may not even be accessible from the machine while the installer is running, even though later they will be!

Even if the preferences were written for one user, then, they can’t be written for other users who might use the same application on the same machine. Preferences for that user will have to be set up when that user first runs the application. Fortunately this is simple to implement; when the user runs the application, their files are definitely available.

Once you’ve got the logic written to take care of per-user setup at first launch, there’s no longer any need to special-case that first user at install time. And that’s why installers don’t do per-user setup: the application has to do it anyway.

When I first posted about AIR’s support for enterprise deployment, there was some confusion over whether or not silent installation was allowed. That was problematic because, in enterprise scenarios, silent install is generally required. (Note that it’s not required for all redistribution scenarios; some of those involve GUI-based installation from a CD, for example.)

When we released AIR 1.1 last month, we also made changes to the redistribution license and documentation to clarify this situation. Silent installation is now supported for anyone who has a redistribution agreement, whether that agreement was signed before or after these changes. For details, see the updated redistribution documentation.

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.

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.