Pursuit of Simplicity

The Adobe AIR 1.5.2 release is now available. There are relatively few changes in it, given that it's a minor release, but I'll nonetheless be posting a few entries about the more interesting changes.

Perhaps most interesting of all is that we've revised the much-loved unrestricted system access warning that's displayed during application install. I think you'll be pleased with the new design:

Please note that this change applies only to applications signed with certificates that are trusted on the targeted machine. I hope you'll find some comfort in knowing that we do, indeed, listen to--and appreciate--your feedback.

Posted by Oliver Goldman at 1:50 PM | Permalink | Comments (0)

Those who sign up for the Adobe AIR redistribution license have had the ability to silently install and uninstall AIR applications since the AIR 1.0 release. Unfortunately, the silent uninstall support on Windows is a bit rough. I've included below a link to a utility I wrote that eases the problem a bit. But first, a little background on the issue.

When an AIR application is installed on Windows, it's installed via Windows Installer. This is a good thing; it allows leveraging all the capabilities of Windows Installer. For example, silently uninstalling an AIR application on Windows can be accomplished directly via the "msiexec" utility that is part of Windows. All you need to provide to msiexec is the product code of the application.

AIR applications don't inherently contain product codes—they're specific to Windows Installer—and you won't, for example, find one in your application descriptor. Furthermore, Windows Installer requires that product codes change—even for the same application—under certain circumstances. In order to play it safe, AIR generates a unique product code for each version of your application. This, in turn, means you need to know the product code associated with the specific installed version of the application in order to uninstall it. This is a hassle.

Fortunately, Windows Installer also associates an upgrade code with each application. An upgrade code is basically an application identifier that never changes and, given an upgrade code, you can look up the corresponding product code. The mapping from upgrade code to product code is stored in the registry at application install time. Like product codes, AIR generates an upgrade code for your application. Unlike product codes, upgrade codes are the same across all versions of your application and are easily determined via the OSID application that comes with the redistribution support.

Unfortunately, the only way to look up that mapping is via the MsiEnumRelatedProducts() system call, and the msiexec utility won't do it for you. (Theoretically you can look this mapping up yourself in the registry, but that turns out to be fairly complicated, and I'm not sure it can be done reliably.)

How much of a problem this is depends on the uninstall technology you're using, whether or not it can perform this lookup for you, and whether or not you're in a position to write a few lines of C code to perform the lookup. For anyone out of luck on all counts—or just curious—I've written a small utility called "msiu2p". You can download msiu2p here. (The zip package includes the executable and the source.)

Here's an example:

c:\ msiu2p {8DA920D5-C41C-42E0-BF31-87BA49984EE4}

{A2BCA9F1-566C-4805-97D1-7FDC93386723}

c:\

Of course this isn't useful just for AIR applications, either: It's a handy complement to msiexec for any application using Windows Installer.

We plan to improve AIR's intrinsic support for this kind of thing in an upcoming release. In the meantime, I hope this utility will help fill the gap for those who need it.

Posted by Oliver Goldman at 4:12 PM | Permalink | Comments (1)

In my previous post, I explained that installing an AIR application sometimes requires admin rights. This begs the question: Should AIR take pains to avoid those parts of application install that sometimes require admin rights? Some applications do support this, including recently Google Chrome.

We considered this when designing the AIR install experience and ultimately decided this would be a mis-feature. It breaks down to two cases:

1. You're the admin for the machine on which you're installing software. (This is the typical consumer scenario.) You don't need to install without admin rights because you've got them.
   
2. You're not the admin, and you don't have admin rights. You want a non-admin-rights install because otherwise you can't install the application. (This is a typical enterprise scenario.)
   

In this second case, however, your machine is locked down for a reason: the admin doesn't want you to install anything. If they knew you were avoiding this restriction by installing without admin rights, they'd probably close that loophole, too. See, for example, this article about stopping users from installing Google Chrome.

So any specific support in AIR for installing applications without admin rights would be temporary at best, as admins could still prevent it. Worse, it makes extra works for admins who have to jump through hoops to keep their machines locked down. Since we're interested in making sure AIR stays friendly for enterprise deployments, and this feature has no value for non-enterprises, well, it just doesn't seem to make much sense.

Posted by Oliver Goldman at 5:07 PM | Permalink | Comments (7)

Today I was asked not once but twice about whether or not installing an AIR application requires admin rights. If that's not a sign that the topic needs some explanation, I don't know what is.

Surprisingly, it's not a yes or no question. The problem is that you have to know what you mean by admin rights, which may not be as easy to know as you'd think it should be.

A more satisfactory answer can be had by coming at the problem the other way around: Which rights are required to install an AIR application?

In general, there are two requirements: You must have rights to write to the install location on disk, and you must have rights to update any other system state that's modified as part of the install—i.e., the registry on Windows.

The first item, install location, depends in part on the selected location. AIR defaults to a machine-wide location, which may or may not have restricted permissions. If you can't install there, you can certainly try installing elsewhere, such as in your own user folder. You're more likely to have rights to do that, although it's still not guaranteed.

On Windows, however, the registry entries created as part of the application install are always written to the machine-wide portion of the registry. If you don't have write access to c:\Program Files you probably don't have the necessary write access to the registry, either, and so you'll find that choose an alternate install location won't be sufficient to make things work. And no, there's no way to avoid writing these keys.

Mac OS is much friendlier in this regard: not only does it define ~/Applications as the per-user install location, but it requires nothing but write access to install an application.

So, does installing an AIR application require admin rights? Not always—but sometimes it does.

Posted by Oliver Goldman at 12:02 AM | Permalink | Comments (4)

Installation and deployment discussions often use the term "admin rights", as in, admin rights are required for this, or admin rights aren't required for that. But what are admin rights, really?

The answer is, it depends. For most purposes, admin rights can be loosely defined as being the set of rights granted to either a root user (Linux, Mac OS) or an administrator account (Windows).

Still, that leaves plenty of gray areas. First of all, rights can also be divided topically. For example, an account might have rights to install software, but not alter the network settings. Does that account have admin rights? Some of them, I guess.

Second, access can be granted in other ways. For example, file permissions might be set on your Mac OS machine such that any user can install software to /Applications. Does this mean all users on the machine have admin rights? That they're all admins on this machine? Or just that installing sofware on this machine isn't considered an administrative task?

To further complicate matters, even the task at hand might not always require the same rights. For example, installing software into a user's directory (i.e., Documents and Settings) might require a completely different set of permissions than installing it into a machine-wide location (i.e., Program Files). Or, the machine could be configured so that both operations require the same permissions.

The term gets used loosely because, most of the time, these gray areas can be safely ignored. But when someone asks if your software requires admin rights, well, it might pay to ask what they mean by that.

Posted by Oliver Goldman at 11:47 PM | Permalink | Comments (0)

Most certification authorities will issue certificates only to businesses. This can be a drag for individuals publishing applications on their own. If you're in that camp, you may want to take a look at ChosenSecurity's AIR code signing certificates, which are available to individuals.

No, I'm not receiving anything from ChosenSecurity for posting this.

Posted by Oliver Goldman at 11:35 PM | Permalink | Comments (0)

In my response to my earlier post about why uninstallers don't clean up user files, commenter dan suggests that uninstalling and then installing an application should erase application settings. He argues that this would at the very least help users who have applications that don't work because, for example, the application settings have become corrupt.

The fix is tenuous at best:

• It won't work if the application doesn't opt in. After all, some applications will want to save those settings.
  
• It won't work if AIR can't determine where the settings are stored. Yes, we provide a location for that—but it's a suggestion, and not obligatory.
  
• It requires the user to intervene (uninstall/reinstall) to fix a problem the application could address for itself.
  

The point about corrupt user settings is valid; this can happen and effectively disable an application. And I agree, asking users to find the file containing these settings and manually delete them is unreasonable. But the truly simple fix is to code your application so that it can detect and ignore corrupt settings. Get that right, and users may never even realize something went wrong.

Posted by Oliver Goldman at 10:29 PM | Permalink | Comments (2)

Peter Albert and Michael Labriola have written a new article for the Adobe Developer Center: Distributing AIR in the Enterprise. It describes how to deploy AIR and AIR-based applications in the enterprise via:

• Microsoft Systems Management Server,
  
• Microsoft System Center Configuration Manager, and
  
• IBM Tivoli Provisioning Manager Express.
  

Enjoy!

Posted by Oliver Goldman at 10:08 AM | Permalink | Comments (0)

There's one important code signing feature that didn't make it into my recent article on code signing in Adobe AIR: the ability to switch to a new certificate.

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.
  

See also help on the Adobe Developer Center.

Posted by Oliver Goldman at 3:38 PM | Permalink | Comments (0)

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.

Posted by Oliver Goldman at 11:25 AM | Permalink | Comments (1)

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.

Posted by Oliver Goldman at 11:15 AM | Permalink | Comments (5)

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:

1. Owned by the administrator and read-only to users. This category contains the applications themselves.
   
2. Owned by a user and writable only by that user. These are all of your files.
   
3. 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.

Posted by Oliver Goldman at 9:00 AM | Permalink | Comments (0)

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.

Posted by Oliver Goldman at 12:53 PM | Permalink | Comments (4)

Adobe AIR 1.1 is now available. The major focus of this release is localization, both of the AIR installation UI as well as support for localizing AIR applications.

It also contains a new certificate migration feature, which allows you to transition from using a self-sign certificate to a CA-issued certificate. More on this in a later post.

For all the details, see the AIR 1.1 FAQ. Based on your feedback, we've tried to do a better job of highlighting the bugs we've fixed, too.

Enjoy!

Posted by Oliver Goldman at 8:59 PM | Permalink | Comments (0)

I didn't even know that WordPress has plug-ins. Peter Elst, knows, though and built a WordPress AIR badge plugin that lets you create an AIR install badge for your application in a single tag. Now that's cool.

Posted by Oliver Goldman at 10:33 PM | Permalink | Comments (1)

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!

Posted by Oliver Goldman at 8:00 PM | Permalink | Comments (13)

[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.

Posted by Oliver Goldman at 7:57 PM | Permalink | Comments (21)

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.

1. 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.

2. 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.

3. 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.

4. 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.

Posted by Oliver Goldman at 7:38 PM | Permalink | Comments (1)

I've just finished my talk on the Brussels stop of the On AIR tour. I was discussing the importance of the application update mechanism in the context of dealing with security issues and mentioned the <customUpdateUI> feature. According to the show of hands in the audience, no one knows about this feature, which is a real shame.

The feature itself is simple. By default, if your application is already installed and an .air file for your application is opened, AIR will handle the situation. It will display appropriate UI; typically, you'll see the old and new version numbers and be asked if you wish to upgrade.

That's less than ideal for two reasons. First, most applications have their own update mechanisms, update UI, and so on. This default behavior circumvents all of that.

Second, it puts the decision about which version of the application is newer in the user's hands. Assuming you use a straightforward versioning scheme, this is typically not an issue. However, if an attacker can convince a user to install an older version of the application, then they may be able to use a security vulnerability you've already patched to compromise the user's machine.

To avoid these drawbacks, simply declare the <customUpdateUI> element in your descriptor. With that set, any activation of an .air file for your application will cause (a) your application to be started, if it's not already running and (b) the path to the .air file to be delivered to your application via an InvokeEvent. Your application simply needs to capture that event and handle it. You can likely handle it by re-using the logic for your own auto-update mechanism.

That's all there is to it. Full documentation is also available.. Give it a try; I hope to see more hands go up next time I ask who's seen this.

Posted by Oliver Goldman at 8:12 AM | Permalink | Comments (1)

The AIR browser API lets web applications detect, install, and launch AIR applications. There are some restrictions on its use, however:

• Applications have to opt-in to the detect and launch capability. This is done by specifying <allowsBrowserInvocation> in the application's descriptor.
  
• Installing and launching applications can only be performed in the context of a user event
  

"In the context of a user event" means that the method is called during an event handler for some event, such as a mouse click, that's initiated by a user action, such as clicking on a button. Note that this doesn't mean all mouse events qualify, as they can also be dispatched programmatically.

Why this restriction? To protect the user against malicious (or just really annoying) web pages. WIthout this restriction, pages could install and launch applications as soon as the page is loaded, over and over again, until you give up in disgust and quit using the Internet.

This restriction occasionally trips people up when using the browser API because it's tempting to wait for a user event, then call getApplicationVersion() to determine whether or not the application is installed, and finally call installApplication() or launchApplication(). But this won't work because the getApplicationVersion() call is asynchronous; when the specified callback function executes, the code is no longer part of the original user event.

Note that getApplicationVersion(), however, need not be called during a user event. The trick, then, is to call this method right away, when your web page loads. By the time the user clicks on the button, you'll already know whether you need to install or launch and can do either immediately within the context of the user event.

One final note: consider calling getApplicationVersion() periodically from a Timer. That way, if the application install state does change while the page is open, subsequent clicks on that button will continue to do the right thing.

Posted by Oliver Goldman at 8:05 PM | Permalink | Comments (4)

Grant Skinner of gskinner.com has developed a new AIR install badge for us. This badge has a host of capabilities not available in the sample badge included in the SDK—plus it looks cooler. A description and download link are posted on the AIR wiki.

Posted by Oliver Goldman at 2:17 PM | Permalink | Comments (0)

Over the course of our beta releases I've fielded many, many questions about whether or not it would be possible to redistribute AIR and, if so, how that would work. We've promised this would be possible, but haven't allowed it with the beta releases. Now that 1.0 has arrived, I'm pleased to be able to deliver on this promise.

If you're interested in taking advantage of this, instructions are now posted. You'll be asked to accept a distribution agreement and, upon approval, will receive the necessary files and instructions for redistribution.

A couple of quick highlights:

• You cannot redistribute the runtime from your own web site. For web-based install, please use the browser API and our badged install capability.
  
• Writing your own bootstrapper is not necessary. If you want to use the standard AIR installation UI, you can use the provided installer as-is.
  
• 
  

Enjoy!

Posted by Oliver Goldman at 10:38 AM | Permalink | Comments (1)

If you've released an application based on one of the AIR beta releases, here are a few things to keep in mind when making the transition to 1.0.

The Adobe AIR 1.0 release will install side-by-side with any beta releases already on the target machine. Applications which are bound to the beta releases will continue to run on those releases until the beta releases themselves expire. That's June 1, 2008 for Beta 2 and November 1, 2008 for Beta 3.

Users with either (or both) beta release installed will be automatically updated to 1.0 the first time they encounter an application bound to 1.0. This is true regardless of whether it's a new installation or an update. I described this in more detail in this earlier post on the auto-update mechanism.

If your application is auto-updating itself, keep in mind that you must maintain its identity between releases.

For users who first install 1.0 and then encounter an application bound to one of the beta releases AIR will not automatically install the beta release. Instead, the user will see a polite message informing them the application requires an unsupported version of AIR and they should check with the application's publisher for an update.

Users in this situation who can't obtain a copy of the application for 1.0--e.g., if the application hasn't yet been updated--can manually install the beta 3 release. They can also manually install the beta 2 release but the beta 2 release can only be installed before beta 3 and 1.0. Attempting to install beta 2 after any later release will, unfortunately, trash your installation.

Why don't we support automatically installing the betas after 1.0 is already installed? It hardly seemed like the best use of our resources.

Posted by Oliver Goldman at 4:22 PM | Permalink | Comments (2)

Adobe AIR requires that AIR files, which are used to distribute applications, be digitally signed. This doesn't just protect your application in transit: The certificate used for signing also establishes the identity of your application. Change certificates and you've created a different application.

Application identity is critical when using the Updater API, among other features. If you call the Updater API with an AIR file that wasn't signed with the same certificate as the caller, Adobe AIR will refuse to install the update. (Users will see an error message about a mis-configuration directing them back to you, the application's publisher.) This helps prevent anyone from hijacking your application update mechanism--but it also means you need to choose and stick with a single certificate for this application.

Users installing directly from the AIR file will be given the option of installing what appears to be a new application--not an update to the old one. If you have to switch certificates, you'll probably want to ask users to uninstall the old application.

What happens when your certificate expires? Updates will still work, as renewed certificates are allowed. It's the identity of the signer as found in the certificate, not the entire certificate, that's used to perform this validation. The identity in the certificate doesn't change across a renewal.
 

Posted by Oliver Goldman at 12:57 PM | Permalink | Comments (0)

Lately I've been asked several times about how to get an installed version of Adobe AIR updated. After all, applications can update themselves via the Updater API. But what if the new version of the application requires a new version of Adobe AIR itself?

The answer is that AIR will update itself--and has been updating itself since the beta 2 release. If you've got Adobe AIR Beta 2 installed and you encounter an application that is bound to the beta 3 release, installing that application will trigger an update of AIR itself to beta 3. This happens in all installation scenarios: via the Updater API, double-clicking on an .air file, and through Badge Install. [1]

The update happens fairly transparently; there isn't much in the way of additional UI that's shown. More time is spent on the progress bar, of course--the update has to be downloaded and decompressed. Users might notice that there's an additional check box in the UI indicating that the update is going to be applied. Finally, in some cases, an updated EULA may be shown and require agreement.

What happens to all those other beta 2-based applications on your machine? They'll keep running until beta 2 expires, as beta 3 installs side-by-side.

You can--and should--use the same mechanism to update your applications to the final 1.0 release when it ships. 1.0 installs side-by-side with the beta releases, so your beta applications can continue to run--again, until the betas expire.

Posted by Oliver Goldman at 11:05 PM | Permalink | Comments (0)

Adobe AIR 1.0 Beta 3 is now available. Among other new and interesting features is the ability to detect and launch AIR-based applications from within the browser--as promised.

Note that this is not an API for controlling the browser, despite its name. Rather, think of it as an AIR API that's projected into the browser. Just goes to show you how much naming depends on your perspective.

Details are in the documentation, but here's a couple of things to keep in mind:

• Applications are invisible to this API by default. If you want to make your application visible from the browser--and therefore to any website--you have to opt in via a declaration in your application descriptor.
  
• If you opt in, you are responsible for making sure your application can't be exploited by web sites using this feature. Don't use it lightly. The BrowserInvokeEvent you receive when invoked via this feature has properties to identify who invoked you so you can restrict responses to trusted sites.
  

Installing applications from the browser has been rolled into this same API and the new Beta 3 sample badge has been updated accordingly. Note that the older badges will not work with Beta 3.

Enjoy.

Posted by Oliver Goldman at 4:11 PM | Permalink | Comments (2)

AIR applications can update themselves via the Updater API. It's straightforward to use: you just provide an AIR file containing the new version of your application and the version number you're upgrading to. Downloading the AIR file and displaying any appropriate UI is left to the application.

When we designed this API, I thought we'd get a lot of questions about why the version number had to be provided. After all, the version was itself embedded in the AIR file. Surely we could just grab the version number from there, right?

Disappointingly, few have asked.

Disappointing because that argument exists to help you protect your application from downgrade attacks. Downgrade attacks work like this: some earlier version of your application has a vulnerability, but has since been patched. The attacker tricks your update mechanism into using the Update API to install that old version, thus re-introducing the vulnerability. Then they attack the vulnerability.

To protect against this attack, the application must validate before it begins the update that the version it's updating to is, in fact, a newer version. During the update process itself, AIR will validate that the version number you've validated and passed to the update call does in fact match the version in the AIR file. If they don't match exactly, the update will fail.

Why doesn't AIR check that the version is newer? Because we didn't want to impose a version numbering scheme on anyone.

Posted by Oliver Goldman at 8:17 PM | Permalink | Comments (0)

I've been asked a couple of times if it's possible to parameterize the application identifier, etc. for an AIR-based application during the installation process. The scenario is usually something like this: A developer has created an application that they publish through different vendors. Each vendor stamps some unique branding, etc. on the application but the underlying code is the same. The developer doesn't want to produce a different AIR file for each vendor. Instead, they'd like to parameterize things like the application identifier, application name, logo, etc. during the installation process.

The problem with this is that it's directly at odds with secure delivery of the applications. Secure delivery is designed to establish the trusted identity of the publisher of each application via digital signatures. If any part of the application can be changed at install time then it's (by definition) not covered by that signature, and we can no longer establish the authenticity of the application. Maybe you got assigned a correct parameter, or maybe you got a malicious one that will open you to an attack. How do you know?

In these scenarios it's the vendor, not the developer, who is actually publishing the application. They're the ones who should be signing the application; this will insure that it's their name that appears during application install. And of course they should only be signing it after any re-branding, etc. has been applied.

Too much work for the developer? It shouldn't be. Packaging can be fully automated via the adt tool provided for free in the SDK. Create a script that uses it to produce all of your unsigned, parameterized, intermediate AIR (.airi) files. Hand this file off to your vendor and have them sign it, again using adt, to produce the final AIR file for distribution. Voila.

Posted by Oliver Goldman at 3:37 PM | Permalink | Comments (0)

As I've mentioned before, install badges are a great way to get your AIR-based application and AIR itself installed on a users machine with minimal hassle. The feature is being used extensively by eBay, AOL, and others to distribute their applications.

If you're using the install badge, please update to the latest version. You can download it here. This version addresses a cross-site scripting vulnerability in the version previously posted to labs, as described in the FAQ.

We're also planning some significant improvements to this feature for 1.0. I'll fill you in when details are available.

Posted by Oliver Goldman at 11:42 PM | Permalink | Comments (0)

Starting with the beta 2 release, the AIR installers for both AIR itself and for applications can be configured to log actions taken during install. This is not an officially supported feature and we don't make any promises that the log file format won't change, or even that this won't be removed entirely. Nonetheless, you may find it useful.

To enabling logging, simply create a file named either ".airinstall.log" (for the AIR installer) or ".airappinstall.log" (for application install) in your home directory. If this file is present when the installer starts then the log will be written to it (overwriting any previous contents). This works on both Windows and Mac OS. Turn turn logging back off, remove the files.

If you encounter installation-related problems with beta 2 I recommend turning logging on. Even if you're not up to reading the contents yourself it'll be a great help to us to include them with any bug reports.

Posted by Oliver Goldman at 9:30 AM | Permalink | Comments (5)

I really do want to write some entries about handling async APIs as I recently promised, but I've been engaged in hand-to-hand combat with some installer issues recently, so for now--a post about installers.

Installation of both Adobe AIR itself and AIR applications is done via Windows Installer--more commonly referred to as MSI. Using MSI is the doing the "right thing", but it certainly isn't the easy thing.

One of the most frustrating aspects of MSI is that its internal model is opaque. I can only assume it's terribly complicated; it certainly isn't documented. And while usually the inner workings of a technology can be gleaned not only from documentation but also its API, the MSI API is itself rather convoluted. Whether that's because the underlying model is convoluted or just obscuring that model I just don't know.

(By the way, for a great discussion of internal models of operation and how they're surfaced in everyday things like refrigerators, check out Don Norman's classic, "The Design of Everyday Things".)

With that introduction, here's my best attempt at a partial explanation of how features are selected for installation or removal during an MSI install operation. At the very least this will serve to document what I just spent several hours figuring out.

Every feature has a level assigned to it, the level being a non-negative number. Unless you override the defaults, MSI will install every feature with a level of one. A feature with level zero is never installed, and in fact setting a feature level to zero can be a dangerous thing to do--but that's a topic for another post. Features with higher numbers can be installed by changing the INSTALLLEVEL property, but that's not what this post is about either so no more on that topic.

You can also change the set of installed features using a set of properties. There are many of these, but for my purposes I'll stick with just ADDLOCAL, REMOVE, and REINSTALL. Once you set one or more of these properties the level-based behavior above no longer applies. Instead, very feature listed in ADDLOCAL is installed, and every feature in REMOVE is--well, removed. Features in REINSTALL are essentially patched--if they're installed.

Now, you might be wondering about REINSTALL, since it sounded like we were talking about install scenarios--not patches. But--and here's one of those strange parts of the MSI model--in MSI, any "installation" can add, remove, or patch features. In other words, what you might naively call installs, patches, and uninstalls.

(To make things even weirder, other parts of MSI are inconsistent about this. For example, the "msiexec" command line tool does, as the model would predict, allow you to uninstall a product using the /i (install) option. But it also has a /x (uninstall) option. The latter would seem to suggest that the model included a notion of uninstalling, but I'm pretty sure it doesn't. The API, for example, doesn't have an uninstall function--products are typically uninstalled by calling MsiConfigureProduct. Go figure.)

Let me illustrate with a simple scenario. Suppose I have a product P with three features, F1, F2, and F3:

To install both features I can either (a) not set any properties, because they'll be installed by default or (b) set ADDLOCAL=F1,F2,F3.

If I want to install just F1 and not F2 or F3: ADDLOCAL=F1.

Finally, suppose F1 and F2 are installed (but not F3) and I wish to patch F1, install F3, but uninstall F2: ADDLOCAL=F3 REMOVE=F2 REINSTALL=F1.

So there you have the essence of the model; an install operation is really a set of install, uninstall, and patch operations. Of course there's more to it than that, as there are different ways to install features, etc. And that's why this entry is titled a "partial explanation."

A note in closing: The log files generated by msiexec are your friend for debugging MSI issues; use /lv*x to get the most information. If you're debugging issues related to feature selection like I describe here, look for entries with this form:

Feature: Runtime; Installed: Local; Request: Reinstall; Action: Reinstall

They'll give you a good idea of which operations MSI thinks you've requested, including the state of the feature before the operations begin.

Posted by Oliver Goldman at 1:51 AM | Permalink

We've posted an updated install badge. This update removes the debugging code we left in (oops) and some other minor bugs. For more, see my original post on the topic.

The badge will be updated again, but for now I recommend grabbing this newer version.

Posted by Oliver Goldman at 8:57 AM | Permalink | Comments (0)

The AIR (né Apollo) beta release includes a number of great new features, including:

• Support for PDF
  
• Embedded SQLite
  
• Drag-and-drop
  
• Transparent HTML
  

...and more.

But I want to call attention to one of my favorite features: Install Badges. Yes, I'm biased because I worked on it. But if I didn't work on this stuff, this blog wouldn't be half so interesting, would it?

Install badges are SWFs which you can embed on a web page and which, when activated, trigger the seamless installation of your application. It works whether or not AIR itself is already installed; if it isn't, it'll be installed right along with your application in a single flow.

Want to see it in action? Browse to the AIR Sample Applications page and install away.

Wanted to make your own? Download the AIR SDK, which contains a sample badge in both compiled and source form.

Caveat: Embarrasingly, some debug code was left in the badge as it shipped in the beta SDK. (Well, it is a beta, after all.) So you may want to open the .fla just to remove that, even if you're not interested in further customization.

Posted by Oliver Goldman at 10:52 AM | Permalink | Comments (11)

The installer for the Apollo alpha release was made available, for Windows, as an MSI file. MSI files are the native format of the Windows Installer service. They're essentially a single-file database containing the data required to install (and uninstall) an application.

It turns out that offering your installer download as an MSI file isn't a terribly good idea. Unfortunately, we didn't discover this until it was too late for the alpha release.

The first half of the problem arises because Windows Installer remembers the name of an MSI file when an application is installed, and it requires that subsequent installations of the same product use the same file name. (Windows Installer considers two products to be the "same" if the MSI file for both contain the same product GUID.)

The second half of the problem is your browser, which likely has a habit of renaming files that you download. For example, if you download the same file twice, it might helpfully append "(2)" to your second download to avoid overwriting the first.

Taken together, these two behaviors can make it surprisingly likely that you try to install the same product twice from MSI files with different names. If you trace the behavior of Windows Installer when attempting to open the second MSI file, you'll find that it starts by correctly opening the second file, regardless of its name. Later, however, it will try to re-open that file using the original name.

This behavior doesn't seem to be well documented, although I have found a reference in this Windows Installer Team Blog entry--look for Rule #14. I'm hard-pressed to argue that it's not a bug, but maybe there's a good reason for it that I just haven't thought of yet.

Unfortunately, all of this can make Apollo's installation experience look lousy. For example, see this blog about installing Apollo.

We've addressed all of this in the upcoming beta release by making the installer download for Windows an executable. It still contains an embedded MSI file and uses Windows Installer, but no one--not you, and not your browser--has the chance to give that MSI file the wrong name. Plus, it's now got a nifty UI!

Posted by Oliver Goldman at 8:44 AM | Permalink | Comments (2)