Archive for April, 2009

Should AIR Support Application Installs Without Admin Rights?

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.

What are Administrative Rights, Anyway?

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.

ChosenSecurity Individual Developer Certificates

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.