Microsoft Designed UAC to Annoy Users

I Don't Believe in Imaginary Property writes "At the 2008 RSA security conference, Microsoft's David Cross was quoted as saying, 'The reason we put UAC into the platform was 'to annoy users. I'm serious.' The logic behind this statement is that it should encourage application vendors to eliminate as many unnecessary privilege escalations as possible by causing users to complain about all the UAC 'Cancel or Allow' prompts. Of course, they probably didn't expect that Microsoft would instead get most of the complaints for training users to ignore meaningless security warnings."

Comments

Of course...

[evanbd]

If they'd done this from the start, no one would be complaining. In Linux or UNIX, if a program wants elevated privileges, it requires user intervention. The result is that programs don't expect to have superuser privileges if they don't actually need them, and everyone is happy because the only things that have to be done as root are things you'd expect to require root access.

Re:Of course...

[CyberLife]

To extend your point, the reason UNIX systems don't have UAC-style privilege elevation is due to its history. UNIX came into being, and was largely developed, during an era in which virtually all computers were large, multi-user systems that sat in a back room. An administrator would have to be sitting at a terminal 24/7 just in case somebody came knocking -- quite an unreasonable expectation. As a result, programmers had to get used to the idea of restricted abilities.

With the desktop computer model, the situation is quite different. Classically-speaking, the user is sitting right at the machine and is the only one using it. They are the administrator as well as the user. There is no expectation of security since nobody else is involved. Windows derives much of its architecture and style from this method of computing.

Modern-day computing is rapidly moving back toward the shared-computer model. This is occurring somewhat on the front-end (e.g. individual user accounts on a desktop machine for different users), but mostly it's happening on the back-end. Internet servers are very reminiscent of the mainframe-era multi-user model. This is why UNIX is such a good fit for such tasks -- it was designed specifically for it, whereas Windows has had to play catch-up. UAC is a good example of single-user thinking applied to a multi-user problem.

Re:Of course...

[Anonymous Coward]

That's about it in a nutshell, but it is a little more complicated than that.

UNIX legacy lies in Multics which was designed to work along side big iron hardware with hierarchical protection domains that provide the mechanism to restrict the access of a process to resources. UNIX, being directly derived from Multics, benefitted from this lineage by having such robust security throughout it's design at the expense of not being able to run on commodity hardware.

Windows's legacy lies in DOS, which was designed to run on commodity hardware that completely lacked these capabilities. Without hierarchical protection rings the OS had absolutely no ability to enforce any form of resource management. Even if there were enough hardware resources to allow for the OS to have more than a few resident functions in memory, every application still had full and complete control over all of the hardware, and a lot of them made the most of it for performance reasons. It didn't matter how many users there were; security was simply not an option.

When Windows NT was being developed the correct choice was made to completely isolate the older processes to an emulator. Unfortunately this meant that any process written within the last 5 years ran like garbage. Towards the end of the 16-bit era programmers got very creative in overcoming both the limitations of DOS and squeezing every last cycle out of the hardware. This made emulation exceedingly difficult and prone to failure. Companies were sticking to Windows 3.x rather than jumping to NT because of the failure to support legacy applications perfectly.

When Microsoft developed Windows 95 they reversed that decision and kept the 16-bit DOS core, both for compatibility with legacy applications (particularly games), development time and performance. This enabled the large DOS library to work without a hitch on Windows 95 at the sacrifice of locking down the security model. Without that programmers were able to and continued to shirk the basic security guidelines set forth by Microsoft and write applications that required full access, if not direct kernel access.

Microsoft is trying to have their cake and eat it too. UAC is three things:

First, it tries to prepare the user for life as a non-admin. Everyone is used to being admin, and if being admin means not having to think about security then people will continue to be admin. However, if admin isn't really admin unless you really mean it, then admin feels like a normal user. The disadvantage to this is that users will become jaded to the prompt, particularly at this stage when it's fairly prevalent.

Second, it does force the application developers to make correct decisions and follow the written guidelines. An application that does so will never, ever see a UAC prompt and will run perfectly fine under UAC, and under a normal user context. These guidelines have been a part of the Windows Logo process since Windows NT was first released. Hopefully, as more application developers catch on the UAC prompts will become significantly more infrequent, and applications that require escalation for specific tasks will follow the procedures to inform the user of this fast and request escalation internally only for that task.

Third, it tries to silently handle programs that do stupid things by "virtualizing" their actions. The vast majority of applications that require administrative access only do so because they try to write either to the %PROGRAMFILES% directory or the HKEY_LOCAL_MACHINE hive of the registry. So, with UAC enabled, attempts to write to these locations are silently redirected to the user's profile. The task succeeds, the application is happy and the user is happy.

You could argue that the route Apple took was better. I wouldn't disagree, but these kinds of business decisions are complex. Apple basically gets to say "fuck you" to everyone every ten years and they largely live with it. I'm not sure the people would be so forgiving with Microsoft, even if doi

And Microsoft was the biggest offender.

[khasim]

You cannot force someone else to follow a particular coding practice when your coders do not do so themselves.

Re:And Microsoft was the biggest offender.

[repka]

Any particular examples? Application designed following guidelines of win95 (e.g. Office) will work properly in Vista and will not even require folder/registry virtualization (btw, I assume a lot of effort went into this feature to minimize UAC prompts and it for some reason is rarely mentioned among usual rants about them).

I consider the opposite: Microsoft spends too much effort for app-compat. Would Win2k have defaulted users to be "restricted", while win98/ME were viable alternatives (i.e. MS could still cash in on their sale) for compatibility, this effort could have been much more successful and, nowadays, when you try to get Intuit Quickbooks to start under limited user (you don't have much choice in college setting), you didn't have to give write access to whole CLASSES_ROOT registry branch (don't get me started on this...).

So in short, yes, I believe UAC is a great compromise, which forces lousy coders to reconsider their approach to the stuff they ship.

Re:And Microsoft was the biggest offender.

[Anonymous Coward]

I doubt it'll happen, though. It seems like the most widely-disseminated "Vista tweak" is how to turn off UAC. Regular users (including your average Windowsland programmer and others who might consider themselves technologically sophisticated) don't see UAC as a feature, they see it as a bug.

Re:And Microsoft was the biggest offender.

[Silver Gryphon]

Interestingly enough, Visual Studio 2005 and 2008 under Vista can't access a project stored in a local IIS website unless running as admin. You're explicitly prompted to run the entire session under Administrator account. The alternative is to change your project storage to disk instead of IIS -- maybe not a bad idea, but contradicting their new HTTP based projects of 2002/2003 (as Web services were promoted then too, now web services are actively discouraged for security and scalability reasons. Lessons learned, I guess.)

Clicking "Run as administrator" is easier and just reinforces the "click through all these dialogs" mentality. I think MS went too far in some of the dialogs; their new push to give detailed explanations is counterproductive, as I don't want to read an essay at that particular time.

http://msdn2.microsoft.com/en-us/library/aa964620(VS.80).aspx

Still, I agree -- running as admin is dangerous; Linux and Unix had a great approach from their beginnings. Windows needs to catch up to that, and it'll involve a massive effort on the part of the users and developers. Having Ubuntu Linux prompt similar to UAC helps reinforce the principle of running with lowered privileges, and shows that Windows isn't any more evil now that it has UAC, it's just that things were so non-secure before that it's hard as hell to conform to the new guidelines.

Re:At last, a little truth from MS

[unlametheweak]

No they didn't design UAC to annoy users. This was a crass statement made by a Microsoft employee. No company would design something to annoy users. This was a poor use of self-deprecating rhetoric that will be exploited to the extreme. It's a dumb statement for a Microsoftie to make, and really dumb for the media to exploit.

"Stupid is as stupid does", somebody once said.

What a half-assed way to go about it.

[dpbsmith]

This approach could have worked. But if they really meant for it to work, then developers would have been required to embed usable contact information in the application. When the UAC prompt came up it would explain that this was a result of an action taken by the application, and that if it seemed unnecessary to you, you should click a button and send feedback to the developer.

It would also identify and tag the particular circumstances so that there could be a option, "don't warn me about this again."

This latter option would have been particularly useful during the beta phase.

After a couple of years, Microsoft might then assume that developers had been given adequate warning and adequate feedback, and the option to ignore warnings could have been retracted.

What Microsoft did doesn't sound as if they serously wanted the approach to work. They just wanted to be able to say that users "didn't want" security, just the way Detroit said for decades that car buyers "didn't want" safety.

Difference between Unix and Windows in security

[guruevi]

I have been asked and wondering why Microsoft has such a bad track record in security and user access control especially since recent Windows have been built on NT which comes from OS/2 and VMX. According to me it's fairly simple: group permissions. Look at a default Linux/Unix-style installation, you have about 20 groups to start out with. If you're a desktop user, usually you're a member of audio, video, games, cdrom and user. On a Windows machine you're either a User or an Administrator. The way the Linux kernel and it's modules are built, if you need direct access to hardware, you can either be root (not good) or you can access it through it's /dev entry which has group permissions.

So if you want to play music, you can access the hardware (albeit through a kernel module) by making yourself member of the group audio. In Windows however, if you need direct access, you can either use DirectX or a process (daemon) or become an Administrator so you can get to the kernel. There is no group Audio that has only access to the Audio-part of the kernel. As soon as you need direct access for real-time anything, you can't really add yourself to any group to do so.

This of course goes way back before desktops were running NT versions (like 2000 or XP). Before, Windows was running on top of DOS, developers could just code directly into the hardware (just load dos4gw), there is no access control in DOS. DOS was also not meant to be running any services or be connected to a network that's where the whole thing with virusses got started, anything that was running could simply request a hook into the BIOS, under the hood, protected memory was regulated with emm386 while Windows 95-ME all used the faster, less secure himem.sys. Microsoft merged together the NT and DOS and made it into 2000 and XP. There were no extra permissions added for desktop users, the pure server model was coded around to allow for desktop speed and real-time access to hardware, never giving any thought that actually running all services that hook into hardware as Administrator would give problems.

tag:nagware

[Jurily]

What they didn't anticipate though, is people screening out the warnings. Yes, it's important for you, the developer. No, it's not important for the user, who only wants to Get Stuff Done (tm).

If the same yes/no question pops up every 10 minutes, don't expect a different answer when it says "Do you want to install spyware, adware, a couple of trojans, and [whatever they actually wanted to install]?".

Remember, users don't read. Not because they're incapable, they have more important things to do.