In last month's commentary, "Can UAC Be Smarter?" InstantDoc ID 95432, I summarized a controversy about how Windows installs applications. I explained that the standard Windows model for application development prefers that applications store their files in Program Files and store their installation settings in HKEY_LOCAL_MACHINE\SOFTWARE. Because both of these locations require administrator-level access (which only administrators can install) to modify them, Windows applications are made not only to meet Microsoft's guidelines but also to live within the realities of default folder and registry permissions in Windows.
Does this make sense? Should you have to be an administrator to install an application, particularly in light of the fact that most enterprises are currently trying to arrange their desktops so that they needn't give their users admin powers? For many IT managers, the answer is "yes," because one of the questions that I hear frequently is "How do I restrict users from installing applications?" One reason why many think that only admins should be able to install applications is that the applications include patches, device drivers, and the like, and installing those is scary indeed.
The problem with the "you-must-have-administrative permissions-to-install-applications" perspective is that many shops still give administrative power to all of their users, and that there are lots of very simple, innocuous applications that people inevitably end up wanting, downloading, and installing. Average users tend to flex their administrative muscles frequently enough that they don't think twice about it.
On a Vista system, User Account Control (UAC) tries to keep us aware of when we're lending our administrative power to an installation by asking us to confirm whether we intended to click that Install button. I think that the concept of UAC is good, but if we have to click Confirm every minute or so, then UAC will become of no value, as we'll learn to reflexively click Confirm every time. Making us don our administrative cape and cowl every time we want to install an innocuous application could make us into trigger-happy Confirm-clickers, who could be gulled by a malware author into installing something unexpectedly nasty.
Yes, installing some classes of applications is risky, but that doesn't have to be true for all classes of applications. For example, I used to play a fun, but-politically incorrect market-simulation game for Windows called "DopeWars." The game required no installation as it was just a single small .exe file--copy it to disk, double-click it, and it runs. The game saved previous high scores in the registry in the HKEY_CURRENT_USER key, which a non-administrator could modify.
So, why not define a class of applications in Windows that are constrained by a set of rules that makes them much less of a risk to system integrity? We might call these junior applications "applets," but that name is taken, so how about "apploids?" Anyone could install an apploid, but apploids would work only under certain circumstances.
First, the apploids would have to work while having their program files housed entirely in a user profile folder designated for apploids and storing their settings only in HKEY_CURRENT_USER. Whenever you'd start an apploid, Windows would ensure that its executable file came from the apploids folder in your profile or refuse to start that application.
Second, installing apploid programs couldn't include installing any kernel-mode code, including device drivers. Although they could of course call existing DLLs and Windows APIs. Apploids wouldn't be able to start up any other executables except for ones located in the apploids directory.
Third, the apploids couldn't communicate over the network. Any attempt to open a socket would cause the system to terminate the application.
Finally, when used on a Vista system, the apploids would be assigned the user's lower-power token (i.e., standard-user token) so that the half-dozen or so ways of telling Vista to grant them the higher-power "administrative" token would fail for an apploid.
Would this be too restrictive? I don't think so. The conditions that I've laid out here would allow apploid status for many games and Windows utilities such as Calculator, Notepad, and WordPad. Perhaps a model like this might allow developing, deploying, and supporting a large number of applications.