Recently in design decisions Category

New to the AIR 1.5.2 release (and the corresponding Flash Player, 10.0.32) is the LocalConnection.isPerUser property. Note that you'll need to update your application's namespace to .../1.5.2 to access this property. Here's why you should do that.

LocalConnection provides local (i.e., on the same machine) communication between SWFs and AIR applications. It operates via a shared memory segment that's visible to all processes that use the mechanism.When LocalConnection was first implemented on Mac OS, it used a memory segment that is visible to all processes running on the machine. This was reasonable at the time, but problematic now that Mac OS is a multi-user operating system. The unfortunate result is that LocalConnection can be used to communicate across user accounts on Mac OS.

To address this a new, per-user implementation has been implemented on Mac OS. You should always use this mode; it's safer. To do that, set LocalConnection.isPerUser = true on every LocalConnection object you create.

Unfortunately, AIR can't do this for you transparently. The problem is that, if it did, you could get into a situation where version skew breaks use of LocalConnection. For example, this can occur if an application is running on AIR 1.5.2 and attempts to communicate with a SWF in the browser running on Flash Player 9. Until both sides are updated, there's no way to use the isPerUser = true option. By adding an API and making this an option, we've given you a chance to migrate to this option without breaking anything along the way.

This issue is specific to Mac OS. Windows and Linux use a user-scoped LocalConnection in all cases, regardless of the isPerUser setting. You can safely set LocalConnection.isPerUser = true everywhere and be confident that the Windows and Linux behavior won't change.

Final note: The default setting of this property is likely to change to true in a future release, in order to be consistent with our general philosophy of defaulting to safe behavior.

Lately I've fielded a couple of different queries about long pauses in applications using the EncryptedLocalStore (ELS) and DRM capabilities in Adobe AIR. Two questions on the same topic in one week is usually a good indication that some additional explanation is required, so here it is.

As you are probably aware, AIR applications are protected during deployment by digital signatures. These signatures are checked at installation time in order to verify that the application has not been tampered with and, when possible, to reliably display the application's publisher.

The signatures are preserved by the installation process but are not normally checked when an application is running. However, there are two exceptions to this: the signature is validated when the application uses the ELS or DRM APIs. This is done to prevent attacks on the application's protected data that operate by modifying the application itself--any such modification would invalidate the signature.

When we designed this mechanism, we targeted applications in the 1 MB to 10 MB size range. This is important because checking the signature requires computing hashes over the entire application. For these sizes we determined that we could compute hashes over the entire application without significant delay, and so we went with the straightforward implementation that does just that. Larger applications, however--and I've seen examples of applications over 1 GB in size--will suffer painful delays during these signature validation pauses.

Our current recommendation is that you avoid making applications this big. That may sound trite, but every large application I've seen so far was that big because it included assets, such as videos, that consumed the majority of the space. Moving these kinds of non-code-containing assets out of the application itself--for example, downloading them separately into the application storage directory--is a straightforward way to reduce the application to a tractable size.

For completeness, I'll note that it is possible to design a validation mechanism that works incrementally. For example, Mac OS uses a clever scheme that hashes each page of the executable separately; the kernel can then amortize validation cost across each page as it is first referenced. (If the page is never referenced, it doesn't matter if it has been modified.) At this time, however, we have no plans to adopt such a scheme for AIR.

One final note: This signature validation usually occurs just once, the first time either the ELS or DRM capabilities are used. However, if you set "stronglyBound" to true when using the ELS API, signature validation will occur on every access. I don't recommend using this stronglyBound feature, for this and other reasons.

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.

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.

For AIR applications bound to version 1.5 and later, the default behavior of the method HTMLLoader.loadString() has changed. This may impact your application; here's the how and why of the change. (For Flex users, the following discussion also applies to setting the HTML.htmlText property.)

AIR applications are desktop applications and, consistent with that fact, AIR does not prevent you from doing dangerous things like fetching remote content and running it locally. However, it's rare that such things are desirable and, when they are, they should be done explicitly and carefully. AIR APIs are therefore generally designed to make doing safe things easy and dangerous things hard.

Prior to the AIR 1.5 behavior, HTML content loaded via HTMLLoader.loadString() was placed in the application sandbox. This content has full access to the local machine. Whether or not this is reasonable depends on where you get the string that you load from and what that string contains. Since it's easy for that string to come from untrusted sources, this provides an easy path for injecting untrusted code into your application.

To address this, starting in AIR 1.5, loadString() defaults to loading content into the browser sandbox. This is the safe thing to do since untrusted code, when running in the browser sandbox, is unable to operate with the same permissions as are otherwise granted to your application.

If you want the old behavior, you can set HTMLLoader.placeLoadStringContentInApplicationSandbox = true. If you do this, remember that you are taking on responsibility for dynamically loading code into the application sandbox and all of the risks that entails. Ethan Malasky's blog has some great posts in this area. Still, I don't generally recommend it—it's hard to get right.

One final note: This change will not break your existing applications. The new behavior is bound to the namespace used in your application descriptor file. Applications using the 1.0 or 1.1 namespaces will operate as before. You will have to take this change into account when you update to the 1.5 (or later) namespace.