The difference between liking and hating UAC?
Totally unscientifically, I have carried out a poll of people who like UAC (okay, a few security geeks like myself), and those who hate UAC - mostly my wife.
Something struck me as both a surprising common factor, and also a rather obvious explanation of why the two opinions are so polarised.
[Note for the pedants - yes, I'm using the term "UAC" here to mean "Elevation" - there are other portions of UAC that I'm not discussing, such as Protected Mode in Internet Explorer, and so on.]
We use UAC for different purposes
The UAC-lover seems to have 'got least-privilege religion' at least several years ago, and runs most of the time as a standard, restricted user. Most UAC-lovers do not seem to be "Administering the system all the time" types.
As a result, they use UAC as a means to elevate privilege on those occasions when they need to do something administrative, or when they need to run a program that has not yet been coded to run with least privilege.
When they're doing something administrative, they're comparing the UAC "Over-the-shoulder" (OTS) prompt against the methods that used to be available to them:
- Log off and back on - to do this, you have to close out all your applications, saving the documents you were working on, log off, log on as the administrator account, do the admin thing, log off, and log back on as your regular account.
- Fast User Switching (FUS) - not available on a domain, and anything but fast. The only advantage it has over logging out and back in is that you maintain your application state in the restricted user - the documents are still open, the programs are still running, etc.
- RunAs - this used to be how you elevate in Windows prior to Vista, but now you have to find another tool to do the same job for you, because RunAs won't elevate your session even if you provide it with administrator credentials. [I use Jesper's Elevate Explorer Tools from the Windows Server 2008 Security Resource Kit.]
Given these as alternatives, it's no wonder that UAC and OTS elevation prompts are considered better.
The UAC-hater is fundamentally disinterested in least-privilege, at least as it applies to users. Least-privilege is an obvious and good programming strategy, a program shouldn't ask for more privileges than it needs, but to this user, that's something that the programmers should care about.
This user wants to be instantly, and automatically, elevated whenever she calls on a feature that would require it. This is how she's used to running the computer, because she's always called on to do administrative tasks - and she's careful and knowledgeable enough to have avoided causing damage through doing so.
To this user, UAC is an impediment to that process - now, instead of merely running the administrative tool she wants, she has to ask to be allowed to run it as administrator.
With UAC set to automatically elevate for administrators, however, she's far happier. Still not perfectly happy, because there are still occasions when she has to ask specifically to run elevated - when the program is capable of running as non-administrator, for instance. Such programs run as non-administrator by default, and don't elevate themselves. These programs are irritating to such a user.
Typically, such programs appear to break when run with UAC disabled (or set to automatically elevate) - they fail to run, sometimes with bizarre error messages, often just crashing through failure to execute some action that the developers expected would succeed.
Other causes of breakage could be when an application is registered to a user, and the licence information is written to a file in the Program Files folder - when you're running under UAC's protection, files in the Program Files folder may be virtualised (i.e. the program thinks it's accessing the file in the Program Files folder, but it's really accessing a file in the user's home directory tree), and when you're running elevated, those same file accesses are not virtualised.
So, voila, instant loss of licence information, saved settings, or any number of other files that the program expected to find in Program Files.
What can we learn from this?
So, the message is clear - for installations with administrators who like the system to let them be administrators, don't disable UAC, make UAC elevate silently for administrators instead.
This system works, too, for the restricted users. It allows them to operate as restricted users, except when they absolutely know they need to elevate. Over-the-shoulder elevation prompting is still available for them, should they need it.
What still needs to be fixed?
What this option doesn't do is cover what appears to be Microsoft's reason for creating the elevation prompts in the first place. Without UAC prompting at random points, the administrators in control of a system have no clear sign that they've just fired up "Mary Kate and Ashley's Dance Party of the Century" only to be forced to run it as an administrator.
Even supposing you figure out that there's a program you're using which doesn't adequately run in restricted user mode, or which doesn't elevate itself where necessary, where can you go to get assistance from the developers of the application?
Microsoft's own support is an example of how off-putting such a process can be. Microsoft Money refused to update on one of our systems, and I eventually determined it was because the update needed to be elevated, but was expecting to find some files that were virtualised by UAC. It failed with a meaningless error message. To call support costs $25 for Microsoft to even pick up the phone - and if the support tech believes that this is an "advanced" issue, he may charge about ten times that much. Perhaps later, after they realise the problem is their own fault, Microsoft will refund you the money - but many small businesses and individual users don't have that sort of money to loan to Microsoft, or other vendors.
So, is there any good way to persuade developers to quit their bone-headed "start with most privilege" behaviour? Maybe Visual Studio and compilation tools should refuse to run in an administrator session. Okay, so perhaps that's not tenable, because there are development projects that do require you to be an administrator, because you're developing something administrative - but what measure would make developers do the right thing for security (and for their users) naturally?
File and registry virtualisation appears to be a messy kludge on top of the sledge-hammer of UAC elevation, whose primary design goal appears to be to irritate end-users enough to persuade developers to stop doing the kind of things that requires virtualisation as a workaround, and the kind of things that requires administrator accounts in the first place.
Perhaps it's time that, instead of kludging for these bad developers, Microsoft simply said "It stops. Now." - if it's not registered (at install time, or by manifest) as an administration tool, it doesn't get administrative access - or virtualised access to HKLM or Program Files. Yes, that will mean admins will have two links to regedit, and similar tools - one to run in an administrator's session, giving access to HKLM, another to run in their user's session, giving access to HKCU.