Microsoft Designed UAC to Annoy Users 571
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."
Of course... (Score:5, Insightful)
A difference so subtle, I nearly missed it (Score:5, Insightful)
Re:Of course... (Score:3, Insightful)
Re:If this is true... (Score:3, Insightful)
That assumes that 3rd party developers care at all about the customer experience, which if you look at Norton/McAfee, is very dubious.
And then give the customers something reasonable, like how sudo works on *nix.
And Microsoft was the biggest offender. (Score:5, Insightful)
If I had to sudo to run each app in Linux... (Score:5, Insightful)
MS needs to drag both its users and those who write windows applications along to the limited security model we all need each other to be using for the good of the internet. It was always going to be painful.
The one criticism that I have of the system/model in practice is the start menu - and that is all MS! I try to organize my start menu and I see several dialogs. I would be much more on-board with only one Cancel or Allow for an operation like that...
Re:At last, a little truth from MS (Score:5, Insightful)
"Stupid is as stupid does", somebody once said.
Not that bad a strategy, really. (Score:5, Insightful)
It's actually pretty logical that if you make running these retarded apps annoying, you can force the vendors to fix them.
But MS faces a big obstacle in that strategy--the fact that moving back to XP fixes the problem as well, from the user's perspective. And of course, the fact that doing so also makes today's computers 3x more responsive.
It's a shame... I would love a world where Vista caught on but UAC didn't have to pop up ever unless something truly administrator-ish were really going on. Then all my users could be Users.
What a half-assed way to go about it. (Score:5, Insightful)
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.
Re:If this is true... (Score:2, Insightful)
A big reason for Windows sucking is the third party applications. Look at what XP did with the tray: introduced this little arrow that hides infrequently used icons because every marketing assmunch realized they could brand the user's computer and most of the users wouldn't be able to do anything about it. Meanwhile, it became common to see half the task bar being eaten by the tray and 25 stupid icons just sitting there. (Sun doing that with Java says a lot about the platform.) It is the tragedy of the commons playing out on the user's desktop, and the users are the ones losing. Meanwhile, nobody seems to care, it is business as usual.
With regard to UAC, I'm curious to what you think is a better solution. Not that I like the current one, but I rate it as the least-worst option that I can think of, other than virtualization.
Turning off UAC doesn't require UAC confirmation (Score:0, Insightful)
Turning off UAC doesn't involve a UAC-mediated privilege elevation.
WTF? Even if UAC has the narrow goal of guarding against malware rather than a malicious user sitting at the console, doesn't this completely defeat the purpose?
(It seems that it does require a reboot, but that's hardly a barrier. Some piece of malware can just silently flip a registry key to turn off UAC, and then wait until the next time you reboot to finish 0wning you.)
So (Score:2, Insightful)
Just go to the "application vendors" (Score:2, Insightful)
Re:At last, a little truth from MS (Score:4, Insightful)
UAC does none of those things in the real world. It is a horrible security mechanism, it slows down every day usage of most PCs, it causes endless annoyance to users. If this feature was designed solely for the purpose of alerting 3rd party devs to the numerous unnecessary privilege escalations they are using, it almost would be worth it/make sense. If not, it is proof that MS has absolutely no clue what users want, need, or what is a good feature.
Re:If this is true... (Score:4, Insightful)
Microsoft is right this time (Score:4, Insightful)
Microsoft is right. Most applications should never have administrator privileges, not even during installation. It's way past time to tighten the screws.
Good idea, bad implementation (Score:5, Insightful)
The basic idea's sound. The problem is that, given the implementation, users view the problem as being UAC and/or Vista, not the apps. After all, the apps work just fine if you turn those annoying dialogs off or go back to XP. If the users don't view the app as the cause of the problem, they won't pressure the app vendor to do anything about it. Idea fails.
I prefer the Unix approach. The OS doesn't pop up any dialog, or offer the user any choice. If an app does something it doesn't have privileges for, it gets an ENOPRIV returned from that call and isn't allowed to do that. How the app handles it from there is up to the app, but there's no easy way to make the errors go away at the system level (most modern Unixes are set up to make it inconvenient to log in or run programs as root, and only root can install a program setuid-root).
Re:C:\Program Files\ (Score:2, Insightful)
c:\progra~1\ would be the workaround there, fyi
Dos programs used to handle it like that with (and my memory is a bit fuzzy here) FAT32 methinks. The legacy is still in there even though the modern cmd.exe can handle long names in quotes. Now, if only they could learn how to properly escape special characters...
If you're stuck with a browse box and no option to type in the path manually I guess you're pretty much out of luck...I'd kill for decent symbolic linking in Windows, shortcuts are like a bad joke
Re:Of course... (Score:5, Insightful)
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:you, my friend, made an incorrect assumption... (Score:4, Insightful)
...who don't listen. (Score:4, Insightful)
Printing is irreversible too (Score:4, Insightful)
But do you have to enter your root password every time you print? I think not.
Re:Installed for all users? (Score:5, Insightful)
Re:And Microsoft was the biggest offender. (Score:5, Insightful)
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:At last, a little truth from MS (Score:4, Insightful)
UAC is not a bad idea (Score:4, Insightful)
UAC is not a bad idea. True, they could have gone the gksudo way and allow a window of time before asking for permission again. And then they could ask for a password instead of getting people in the habit of clicking away past warning windows. But still, it's not a bad thing.
They also had to stop programs from storing settings and user stuff under the write-restricted "Program Files" folder.
Now, annoying users intentionally to exert pressure on software vendors is just twisted.
UNIX/Linux users may want to have a little thought about what things would be like without the SUID facility ('ping', anyone?), and, on the other hand, the security implications of SUID. I was shocked when I read the example at page 249 of the UNIX Haters' Handbook, which illustrates the problem of blindly trusting your PATH with a simple example in which you can trick your system administrator into providing you with a root shell binary. Tried it. It works.
Not that this has prevented me from ditching Windows Vista in favour of Ubuntu on my laptop (desktop to follow when Ubuntu 8.04 is released).
totally ineffective (Score:3, Insightful)
Re:Of course... (Score:5, Insightful)
UNIX being "such a good fit for such tasks" is completely off-base and irrelevant to the discussion. The software that runs on the OS determines my interactions, and the "privileges" being imparted to registered users, such as allowing me to post a message and have my account name appear above it, are not at all imparted by the multi-user sensibilities of the OS the web server is running off of.
I guarantee Slashdot could run off Windows or Linux boxes and you or I wouldn't know the difference.
Re:And Microsoft was the biggest offender. (Score:4, Insightful)
While what you said is true, it can be simplified: You cannot force someone else to follow a particular coding practice.
For a variety of reasons Windows users grew accustomed to running as full administrators. Large vendors (aka customers) made assumptions when developing for Windows. These assumptions cause problems for a Windows end user (aka the customer) trying to use the large vendor's (aka the other customer's) program. If the user calls the vendor the answer is "run as admin". This conflict is only bad for Microsoft because the end user will put usability over security every day and the large vendor may get sick of dealing with "Windows bugs" and choose a different OS to develop (develop, develop, develop) for.
Microsoft was really damned if they did and damned if they didn't. It may well be their own fault (due to the original design of DOS) but unless you have a time machine nobody can change that. It seems to me that, while I find UAC to be annoying as hell, they probably did the right thing. By making it pervasive it will help get the Windows security paradigm changed faster than if it was just a gentle suggestion. At the very least they are trying to put it back on the software vendors to focus on security when creating their products--something good for everybody.
Re:And Microsoft was the biggest offender. (Score:2, Insightful)
1) Who is the purveyor of the most popular development tools for use on Windows? Microsoft.
2) Who is the purveyor of the most popular development training materials for use by budding Windows developers? Microsoft.
3) Who certifies Microsoft Certified Developers? Duh. Microsoft.
4) Who is supposed to be leading their ISVs by example? Microsoft.
5) What's the common denominator here? Microsoft.
Microsoft is responsible for making their platform insecure. They are responsible for training developers to use unnecessary security elevations. And they do it themselves.
If Microsoft, like a drug addict, would just admit that their past and present security failings are their own fault, they would be one step closer to recovery.
Re:What a half-assed way to go about it. (Score:4, Insightful)
'don't warn me about this again' - presuming an app was trusted once at install-time, it's just going to go write the 'oh, the user allowed me permanantly, it's ok' setting wherever it turns out that is stored. Then they have no incentive to fix their design issues.
The problem isn't UAC, it's the fact that windows developers aren't writing for the standard user.
Re:And Microsoft was the biggest offender. (Score:5, Insightful)
Difference between Unix and Windows in security (Score:5, Insightful)
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.
Re:What a half-assed way to go about it. (Score:4, Insightful)
Having spent most of my professional life at small companies, when I started working at larger ones in the last few years I was appalled, disgusted, and amazed to see that MOST of the employees spent their time worrying only about CYA, as opposed to doing a good job.
What a bunch of fucking pussies.
Re:And Microsoft was the biggest offender. (Score:5, Insightful)
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 [microsoft.com]
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.
tag:nagware (Score:5, Insightful)
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.
Re:Of course... (Score:5, Insightful)
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
Re:And Microsoft was the biggest offender. (Score:4, Insightful)
Re:And Microsoft was the biggest offender. (Score:3, Insightful)
Re:A difference so subtle, I nearly missed it (Score:3, Insightful)
Re:Of course... (Score:5, Insightful)
Windows was snappy and fast. OS/2 lumbered along (it spent a lot of time swapping, since 8MB was not really enough for it). Linux was zippy fast, unless you started X -- X worked, but was pretty darn slow.
Compared to the Sun workstations at school which each had 10 NCD X-terminals slaved to them, Linux/X on this machine was fast. But compared to everything else, it was slooooow.
Re:you, my friend, made an incorrect assumption... (Score:3, Insightful)
UAC is crap (Score:5, Insightful)
From a cynical POV, I think all UAC is for is to allow Microsoft to blame users for security problems (ah you turned UAC off - so it's YOUR fault).
If Microsoft was really interested in security they would have done more and better sandboxing of applications.
My suggestion is to have a manageable number of default templates for sandboxing applications. If the app is unsigned by a user-trusted entity, the user gets a pop up which tells the user what type of sandbox the application wants to run in.
It would be far easier to train Joe Schmoe to not run a "flash game" which asks for "Full User Privileges" or even "Full System Privileges" (with all the scary warnings etc) and to only run a "flash game" that asks for a "Guest Game" sandbox. After all there is no need for most legitimate flash games to access "My Documents" or your web browser bookmarks, or even your microphone/webcam.
The idea is even if a program wanted to do something nasty, if it is running in a sandbox, it can't, and if a program requests an unusual sandbox so that it can do something nasty, it is easier for a user to know something strange is going on.
This would also be a lot less work than UAC. Don't need to make 10 decisions one after another when you run the app.
There could be custom sandbox templates that are validated and signed by a mutually trusted authority. So that new apps that require fancy privileges can run in fancy sandboxes without annoying prompts that bother Joe Schmoe.
As for Linux and OSX, they aren't really more secure than Windows, with both these OSes if Joe Schmoe is about to run something new, he doesn't even know what the program is really going to do till he runs it. It is like expecting Joe Schmoe to solve the halting problem and without him being able to read the source code either - "Is this program going to halt, or is it going to take over my computer?". So my suggestions are just as applicable to them.
Re:If this is true... (Score:1, Insightful)
Right: nothing. Almost.
One thing, disabled by default, is the SAS (you known, Ctrl+Alt+Del). If enabled, it requires the user to press it, which only the UAC dialog is able to ignore. Almost, since it doesn't matter - do your dialog in DirectX or OpenGL with a transparent surface, and you'll still be able to force your dialog to always be on the top.
Also, some third party components like VMware allow you to trap SAS on behalf of the system, or your malware.
Once having aqquired the admin password, I can use CreateProcessAsTokenW() to elevate to admin privileges.
What comes then is a matter of configuration: By default I can do anything I want, since once I'm running with admin rights while being logged in as a user UAC thinks that I've already elevated and doesn't ask any more.
But even if it is configured to ask again, there are some actions which don't trigger requests, for example the usage of the SE_BACKUPRESTORE_PRIVILEGE - which allows me to write to the raw disk as well as override all ACLs; that is a complete compromise.
The cause are two big problems:
- SAS doesn't worl because DirectX and OpenGL are considered as too privileged.
- The UAC provides no means to authenticate itself. Why not letting a user choose a picture at install time which is then stored at a safe location with only NT-AUTHORIYT\SYSTEM being able to read, such that only the UAC dialog is able to present it to the user?
Re:That's patently untrue. (Score:1, Insightful)
Sounds perfectly reasonable to me.
e.g.
"Go to school"
"Don't drive the car"
"Don't try to have sex with mom"
"Don't do that or you'll end up like me"
Tons of different rules for children and adults. Welcome to the real world. Minors aren't the same as adults.
Re:Of course... (Score:3, Insightful)
Having a GUI interface had nothing to do it.
UAC is a blame shifting tool (Score:5, Insightful)
UAC nags you for every little piece of rubbish. 99.999% of those requests are ok. Well, not ok, if programmers would not require godmode for every stupid little setup change... but they're not harmful. It's the other 0.001% that matter.
Now, the average user turns off UAC. For a simple reason: Imagine some tool you don't know much besides operating it asks you "The futzgrabber in the argamajig wants to mirfl. Cancel or allow?" What do you do? After some try and error, you learn that the thing does what you want when you click allow. You start wondering why the heck you have to click allow. And the next logic step is to turn the pointless thing off altogether.
And here's where the tool works as designed. Because if you get infected, MS can just shrug and say "Hey, we gave you the tool to avoid it. See, UAC would have told you this wants to do something bad, but you turned UAC off. Your fault."
Instead of finding a way to give the user a secure system, MS just shifted the blame. You can't blame Windows now anymore if you get infected. It has a tool that would have told you you're going to get infected, but you turned it off. Shift the blame for the infection to the user, away from the system. That's all UAC is about.
Re:UAC is a blame shifting tool (Score:5, Insightful)
Let me offer another example: if Linda from Accounting makes for 75% of my daily tech support problems, the most obvious solution for that is not replacing all 2nd floor printers, rewiring Accounting and reinstalling her Windows. It's eliminating Linda.
Re:And Microsoft was the biggest offender. (Score:4, Insightful)
Re:UAC is a blame shifting tool (Score:4, Insightful)
Be wary when trying to eliminate someone who is obviously a moron, chances are good that he or she still has his or her job for a very good, non-work related reason.
Re:UAC is a blame shifting tool (Score:5, Insightful)
The problem is that the bulk of the 3rd party software developers in the ecosystem use practices that violate the published guidelines and best-practices for the platform, and often use techniques that are indistinguishable from malware.
Alot of hand waving about how bad UAC is, it maligns the users, etc etc. And then 'something should be done about it', but no substantive suggestions along those lines.
Propose a valid alternative that doesnt involve time travel, and your argument might have some weight.
And whats this stuff about 'blame'? There's no blame, just costs. How would you suggest Microsoft makes incompetent 3rd party developers pay the cost for their sloppy code writing without involving the user in any way?
What MS has done here is to force the costs of sloppy coding by 3rd party developers to become visible, whereas prior to UAC, if you didnt run as non-admin, you never saw those costs. They were invisibile. MS just made them visible. So now users are bearing the costs of sloppy coding by 3rd party developers, in the hope that the pressure will then be passed on to these devs.
Unfortunately, MS doesnt have any direct relationship with these vendors, there's no place to have leverage, to make the 3rd party devs do 'the right thing'.
Overall, it sounds to me like you're just posting here to join in the 'look how much Micro$oft is teh suck' bandwagon, but without actually contributing anything to the conversation. Suggest an alternative thats more substantive than 'something should be done'.