Using Vista (or plan to use it)? Then try your hardest to run it as a non-administrative user first

In response to yesterday's blog about whether or not Vista's tightened security could mean additional friction in the Web experience that Vista users will encounter, my fellow blogger George Ou first responded that the average user doesn't default to a non-administrative user or "limited user account" (LUA) but also took the opportunity to say:

And if you're trying to install all this stuff as a non-admin, you're just asking for trouble. Sticking a bunch of crapware such as Yahoo IE bars and Lenovo junk is a good way to slow your machine to a crawl. Why go out of your way to make your PC run like junk?

George's comment covers a significant amount of ground that's worth breaking into smaller chunks and addressing. In this blog entry, I want to address the George's comment about how the average user doesn't default to a non-administrative user. In another, I'll deal with the the "junk" bit, particularly as it relates to Lenovo.

With Vista barely out of the gate, it's hard to say how true George's statement will be of Vista users. It was and still is very true of Windows XP users. If Vista usage turns out to be anything like XP usage, George will be right, but with one caveat: In Vista, when you establish the first user -- always an administrative user to start -- that user by default is, for all intents and purposes, already a lesser privileged user (LPU) running under an LUA. In other words, in Vista, there's basically an administrative LPU and a standard LPU. According to a Microsoft spokesperson:

When you sign into any machine as an administrator on Windows Vista, you receive two authentication tokens; one for a standard user and one for an administrative user. You run [Windows Vista] using the standard user token until you do something that requires administrative rights. At that point you are asked to elevate to the administrative token. So while running as a standard user is the better way to go, running as an administrative user no longer carries some of the risks it used to because of [Windows Vista's User Account Control (UAC)] and this "split token" arrangement.

Furthermore, based on what I've seen so far, Microsoft's Vista team has gone out of it's way to make sure that running under an LUA (administrative or standard) isn't the "asking for trouble" that George makes it out to be and quite frankly, while there's no perfect solution, I think they've done a very good job.

When running under an LUA, the likelihood that a system can be victimized by what Microsoft often refers to as "drive-by malware" is significantly reduced. There's no silver bullet to securing systems and networks against the many threats that loom. Instead, securing systems and networks involves a layered approach where the whole is greater than the sum of its parts. In other words, whereas each layer of security (for example, running antivirus software) offers some modicum of protection by itself, that protection is greatly enhanced when it's combined with other security layers (eg: running a system under an LUA).

Adequately securing PCs (the practice of which itself is a layer in securing local area networks and the Internet) involves many layers. The more layers, the more complex things get. One challenge to an operating system developer like Microsoft is how to introduce those layers and encourage users to take advantage of them without introducing a commensurate amount of user experience friction: friction that might otherwise disincent people from using those layer(s) in the first place. As one such layer, running XP as a lesser privileged user (LPU) was a good example of this friction because of how many popular software titles required administrative access to the operating system in order to work. Those applications simply broke. It was friction of the worst kind and a serious disincentive to run XP in a more secure mode.

Additionally, LPUs in XP were restricted from changing settings they should reasonably have had access to like notebook power settings and time zone (some of this is corrected in Vista, but not all). The affected software titles covered a range of use cases from business to gaming to Internet communications. I heeded Microsoft's advice and tried very hard to secure the XP PC in my house that my 16 year old son used for gaming by establishing him as an LPU. The PC became unusable until I gave his user ID administrative rights.

While software developers haven't completely caught up to the LPU way of doing things in Windows, the situation has improved. Not only have developers figured out a way to respect the LUA/Administrator boundary, Microsoft has applied some technical measures to handle certain situations where third parties might need administrative access even though the PC is being run in an LPU mode. Whereas before, an LPU's attempt to write to administrator-access-only disk space stopped certain applications from working, Vista redirects such disk-writes to a safe area on a per-user basis in a way that an application's subsequent attempts to read that data actually work. Another measure involves an escalation function that was demonstrated in the screen gallery I published yesterday.

Vista includes an escalation function for certain tasks like installing software. If you're running as an LPU and you need to install software -- an ActiveX control to support some Web site's experience for example -- the installation's attempt at gaining administrative access won't bring the user experience to a grinding halt. Instead, in an effort to temporarily grant an LPU the necessary administrative rights in order to complete the software's installation, standard LPUs are prompted for an administrative password (see below).

In contrast, all that's required of the dual-token administrative LPU is a mouse-click (in other words, no password). So in either case (administrative or standard LPU), an attempt to install new software is greeted with an escalation dialog. The only difference in an administrative LPU context is that the user isn't asked for a password.

Nevertheless, the Vista user experience that I just described constitutes friction when compared to how things worked on XP. When running with administrative rights as most users did with XP, nothing like this ever happened. The result created something security experts refer to as "surface area"; areas of exposure that malware developers often look to exploit.

Microsoft could have taken any number of approaches to dealing with that surface area in Vista. For example, it could have left things the way they were in XP. Or, Microsoft could have swung the pendulum in the complete opposite direction by forcing non-administrative users to logout and then log back in as an administrator. But we as users have to be honest with ourselves. Working as most of us did with XP was living dangerously. From a user experience point of view, application installation involved no friction. But the same was true for certain classes of malware (again, what Microsoft often refers to as "drive-by malware"). And the whole point of the functionality embodied in Vista's User Account Control feature is to maximize friction to malware while minimizing friction to end users.

Should we as users be allowed to live dangerously or is Microsoft right to toss some friction into the user experience in order to keep us from being our own worst enemies? Part of the answer is the fact that, in tossing-in some friction, Microsoft isn't just keeping each user from being his or her own worst enemy. Historically, the worst exploits have deputized unsecured systems in the process of spreading themselves across the Internet and doing their damage. So, provided any friction that Microsoft introduces is effective, it will also keeping us from being the enemies of other Internet users as well.

Will Microsoft's chosen path prove to effective? On one hand, my answer is yes. On the other, perhaps Microsoft could have done more. Critics of Microsoft say that repeated escalations will desensitize users to the point that they'll just click through them anyway without really paying attention to what they're doing (one reason I actually favor the password-required path). Where I used to live in New York, there was an intersection that was notorious for fatal, head on collisions. Nobody could put their finger on the reason why and there were no obvious answers on what to do about it. In every single case, the accidents were caused by incredibly wreckless driving. For whatever reasons, this particular intersection was a magnet to wreckless drivers whose turn had come to cause a fatal accident.

The local authorities took action. They posted signs that said things like "SLOW" and "DANGEROUS INTERSECTION AHEAD." Even though the accidents almost never had to do with intersecting traffic, they put a traffic light in the intersection (friction). Some people were smart enough to heed the warnings and slow down knowing that they might have to stop for a traffic light. If they're dead now, they probably didn't die in that intersection. Other people didn't heed the warnings. They didn't slow down. Some of them are dead or permanently maimed. Were the authorities wrong to add the friction they did? Not in my mind.

Likewise, I think Microsoft found the right balance in its approach. Yes, the escalation dialogs constitute additional friction. And, it's just a wee bit more (a password) if you're logged in as a standard LPU versus if you're logged in as an administrative one. But it's not sufficiently different from how other operating systems (the Mac, Linux, Unix, etc.) handle the same problem to warrant criticism of Microsoft's approach in Vista. And, if you ask me, going the standard LPU/password required route is not enough friction to disincent users from heeding the advice of running as a standard LPU. In either case (the standard or administrative LPU), there's enough friction to stop drive-by malware provided that end-users heed the warnings. Drive-by malware shouldn't be able to install itself without the end-users' consent.

<sidebar>As a side note, and perhaps as fodder for another blog, defining "install" is worth some attention. There are certain Windows applications that can be copied to and run from standard LPU's My Documents area or even a USB key. In an effort to keep rogue code from running, Vista seems to focus on applications that use Windows' formal installation APIs to load themselves on to a PC. But what about executable code that doesn't go through those APIs? Should Windows Vista equally pass attempts to run unknown applications through it's User Account Control feature?</sidebar>

Will some users become desensitized? Perhaps. But like the wreckless drivers that are dead now, if they're not smart enough to pay a very small price in order to let others help keep them out of harms way, the cards will fall where they will. Often times, not in their favor.

Going back to the question of whether Microsoft's approach will prove effective, I wrote, "On the other [hand], perhaps Microsoft could have done more." Right now, I'm running Vista on a Lenovo X60 Tablet as a standard LPU and so far, that choice has not interfered with my user experience enough to warrant usage as an administrative LPU where a password isn't required for certain administrative operations. Fellow blogger Ed Bott pointed out to me how running as a standard LPU in Vista will block access to some other functions like Vista's device manager without a request for escalation. In other words, gaining access to the device manager requires logging out of the standard LPU and logging-in as an administrator. That's pretty significant friction. For this and other reasons, Bott thinks it's OK to run Vista as an "administrative LPU" as long as the PC isn't shared with someone else.

Going back to yesterday's blog, running as an LPU made no difference between the two different paths I took to get Adobe's Flash plug-in installed on my computer. By the time I got to the escalation dialog, the user experience was exactly the same. It was what came before that dialog -- an experience that's largely in the hands of Web site developers -- that was the gating factor. But to run Vista under a standard LUA, I had to deliberately choose to do so. I don't know about other PC manufacturers, but neither the Lenovo X60 nor Vista arrived in a way that encouraged me to run that way. To run as an standard LPU, I had to go out of my way to do it and I did.

Here is where the lion's share of the responsibilty to educate users about the differences between a standard user and an administrative user rests on the shoulders of Microsoft and system manufacturers. During Vista's installation routines where the initial user IDs are created, there exists a perfect opportunity to educate users on the benefits of LUAs and the differences between the dual-token administrator and a standard Vista user. The same goes for the out-of-box experience that most system manufacturers are in control of. But those and other opportunities to educate users are being missed.