Archive for July, 2008

Cleaning Up Sensitive User Data

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.

Why Uninstallers Don’t Clean Up User Files

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.

Why Installers Don’t Do Per-User Setup

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.

AIR, ADT, Java, and Proxies

AIR applications, when accessing content via HTTP or HTTPS, always do so via the system proxy settings. On Windows that means they use the same settings as Internet Explorer. On Mac OS, those are the same settings as used by Safari. It’s hard to use a machine if the system proxy settings aren’t correct, so users typically have this set up early on and then don’t have to think twice about it—it just works.

The folks over at Sun who had to implement Java for Windows had other ideas, and gave Java its own proxy settings. If you have to explicitly enter your proxy settings for your operating system, you most likely will have to separately enter those settings to any JRE you’ve installed. In current versions of Java, these settings are accessed via the Java Control Panel.

ADT is, as explained earlier, written in Java. It also generally has to access the network when signing in order to obtain a secure timestamp; that server is accessed via an HTTP request. The end result? Developers often find that AIR applications can access the network just fine during development, but when it comes time to create an AIR file, packaging fails because a timestamp can’t be created.

If you run into this situation, be sure to check your Java proxy settings—and make sure you’re checking for the same JRE that ADT is using. (If you have more than one JRE, they may not be sharing proxy settings.) I do not recommend disabling timestamping, for reasons I’ll explain later.

Redistribution and Silent Install

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.