Slashdot Log In
Microsoft Designed UAC to Annoy Users
Posted by
ScuttleMonkey
on Fri Apr 11, 2008 08:12 PM
from the at-least-they-are-being-honest dept.
from the at-least-they-are-being-honest dept.
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."
Related Stories
Submission: Microsoft Designed UAC to Annoy Users by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Of course... (Score:5, Insightful)
Re:Of course... (Score:5, Funny)
Parent
Re:Of course... (Score:5, Interesting)
Odd that the same home PC at the time, running Linux, had no trouble at all enforcing it.
Parent
Re:Of course... (Score:5, Informative)
Yes. And before that it was a 386sx 16mhz. Worked fine. With X. And a web server running in the background, serving over dialup w/ static IP. Uphill. Both ways!
I'm serious about everything but the uphill both ways thing. I used that thing every day for at least a year. I don't remember it being slow, but I imagine it would seem so today.
Parent
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.
Parent
Re:Of course... (Score:5, Interesting)
Then I said it wrong. Please let me rephrase: "In the era of Windows 95, home PCs weren't considered to have enough CPU and RAM to enforce proper privilege separation while running a graphical user interface." Or did you manage to usefully run X11 on a 486 PC with 8 MB of RAM?
No that doesn't make sense either. How about "windows was never meant to be networked so multi user protection wasn't built in from the start"
Parent
Re:Of course... (Score:5, Informative)
Period PC hardware absolutely was capable of running X11. I bet quite a few idiots like myself did it at the time.
First, an 80486 was not really period hardware. The Pentium classic was on the market at the time that Windows 95 came out, clocked at 100MHz. It had been around for almost a year at that speed. This processor is a few percent as fast as modern CPUs.
Now, if you were to put Gnome or KDE on this hardware, it would be a pig. For me, I ran the Open Look Window Manager. It looks like this [xwinman.org], which I think looks a little bit worse than Windows for Workgroups. But, man, is it lean.
All rolled up, that window manager, using colour depth common in the period, is probably more than ten times faster than a modern desktop. Through the mists of time, I'd say that Ubuntu, with modern hardware, seems a good three or four times faster than that old unix box, which fits.
For what it's worth, the experience was about as fast as the Sun boxes I had used at university a few years before. IIRC, they were running microSPARC I processors at 40Mhz. I don't remember the RAM, though. They ran OpenLook as well,which is why I used it a few years later. I was used to it.
You should know that X11 was released in 1987. It's not like they wrote and debugged it by desk checking, yeah? It ran on workstations available 20 years ago. Moore's law says there were five doublings of transistors per unit area between 1987 and 1995. To say that hardware in 1995 was too slow to handle security, protection, and a GUI is false on its face.
Parent
Re:Of course... (Score:5, Informative)
Parent
Re:Installed for all users? (Score:5, Insightful)
Parent
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.
Parent
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.
Parent
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
Parent
Re:Of course... (Score:5, Informative)
Except of course Microsoft's Xenix, which Altos ported to the 8088 in 1982, and SCO offered for the IBM PC in 1983 (MS licensed Xenix source code OEMs and software companies rather than selling the finished product directly to end-users). A lot of people seem to forget that MS were UNIX licensees in 1979 and added several BSD elements to the V7 code they got from AT&T when designing Xenix. All of this happened quite a while before they bought QDOS to satisfy IBM's requirement for a CP/M-like system.
"Windows's legacy lies in DOS, which was designed to run on commodity hardware that completely lacked these capabilities."
Windows' legacy is actually the Lisa and Macintosh, which were what inspired MS to write it. It's a single user system because the Mac was a single user system, and MS chose to use DOS as a launcher because they were aiming it at users of machines that already had DOS and software for it on them. If they'd chosen to use a different OS with a different file structure that required different software, they'd have risked pissing off their potential customer base. Selling a graphical shell that ran on top of DOS but offered multi-user and and pre-emptive multitasking on the other hand would have pissed off IBM, whose contract with MS forbade them from offering those facilities in DOS or DOS-based software to ensure the PC didn't compete with their then lucrative minicomputer business. And as neither were necessary for a Mac-like experience, MS decided to take the route that rubbed the least people up the wrong way.
Parent
And Microsoft was the biggest offender. (Score:5, Insightful)
Parent
Re:And Microsoft was the biggest offender. (Score:5, Interesting)
> when your coders do not do so themselves.
It's shamefully pervasive. In my years of developing software for Windows, I've rarely seen other developers NOT running Windows as admin. --basically developing apps. completely blind as to what permissions they may or may not need. (I finally got religion 5-6 years ago after a nasty virus.) Now, every time I log in, I get several ugly little error messages due to HP drivers and other startup bits and pieces not having God access under a normal user account. I think Win developers --QA and project owners too-- need to feel some personal UAC pain.
Parent
Re:And Microsoft was the biggest offender. (Score:5, Insightful)
Parent
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.
Parent
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.
Parent
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'.
Parent
Re:Driver and login annoyances (Score:5, Informative)
Msconfig is your friend when disabling unneeded startup items. I especially loathe the auto-updaters that get installed by default if you don't know specific installer parameters. Sun java is class A example of that crap, it informs limited users about updates and recommends them to upgrade - only halfway through it throws error message.
Parent
Re:And Microsoft was the biggest offender. (Score:5, Interesting)
The problem is the user interface. As the OpenBSD people keep telling us, sane defaults are the most important thing in security. If you default to insecure, or you default to secure, but so irritating people turn off the security, then your system is not secure.
With respect to your specific problem, requiring elevated privileges for debugging actually does make sense, and I consider it a bug in other operating systems that it's not the case. A process that attaches to another as a debugger can inspect all of that process's memory, and even the contents of registers. If the process is something like your password manager, then it doesn't matter that it stores all of your passwords encrypted on disk and doesn't release them without a pass-phrase if the first piece of malware that gets on to your system can poke around in its memory and read them. Ideally, you would be able to simply flag regions of memory as off-limits to a debugger, but the next best thing is to require elevated privilege. Starting with 10.5, I believe OS X allows a process to set a flag preventing debuggers from attaching, but I've never tried it.
Parent
Re:And Microsoft was the biggest offender. (Score:5, Funny)
Why in hell would anyone want to implement Windows "security" on Unix?
Parent
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.
Parent
Re:And Microsoft was the biggest offender. (Score:5, Interesting)
However, if you're a windows user, and you just upgraded to vista, you see these warnings/questions. What's your first response?
1. Man, I wish these crappy coders would learn when to require root access
2. Stupid Vista... I should go back to XP
Upgrading the security model from a non-visible one to one that requires user attention can be a bitch. MS has a lot of difficult decisions to make these days.
Just see http://www.joelonsoftware.com/items/2008/03/17.html [joelonsoftware.com].
(Now, if only someone could show me how to embed nice links here...
P.S. I use Gentoo.
Parent
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.
Parent
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.
Parent
Re:you, my friend, made an incorrect assumption... (Score:5, Funny)
Parent
Re:Of course... (Score:5, Informative)
It does - if you're on a limited account.
It's only if you're logged in as administrator that you don't have to provide a password - you already did when you logged on.
Think of it this way - with UAC, even root has to sudo.
Parent
A difference so subtle, I nearly missed it (Score:5, Insightful)
Re:A difference so subtle, I nearly missed it (Score:5, Informative)
Parent
If this is true... (Score:5, Informative)
Bad idea all around if this was their intention at design.
Re:If this is true... (Score:5, Interesting)
Look, I'll be the first to decry Vista as a piece of shit, but despite all of Vista's flaws, trying to restrict access of programs is a good thing.
Personally, I think that MS is slowly learning. MS is in no danger of losing its business division so long as companies demand backwards compatibility, but in personal computing it is getting kicked around. MS looks old and faded while Apple has a solid product combined with a marketing machine of d00m (Microsoft always sucked at marketing). MS needs to make changes or else it is going to get run over by Apple. Lock in isn't going to last forever in the face of a comparable, if not outright better, product and vastly superior branding and marketing.
I mean hell, what do you think of when you think of Apple? Shinny plastic with a hipster in a coffee shop. What do you think of when you think of MS? A moldy office.
Parent
Re:If this is true... (Score:5, Interesting)
Parent
Just a typo.... (Score:5, Funny)
Parent
Re:If this is true... (Score:5, Interesting)
Windows is not *nix, the Windows developers learned from the mistakes of sudo.
Parent
oblig. (Score:5, Funny)
[Cancel] [Allow]
At last - an MS Success! (Score:5, Funny)
Microsoft and the United Aerospace Corporation (Score:4, Funny)
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...
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.
Re:Not that bad a strategy, really. (Score:4, Interesting)
Parent
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.
Frustration Detection patent (Score:4, Funny)
It does make sense, when you think about it, since they've found step 2 and patented a frustration detection system [slashdot.org].
I have to steal this comment from one of the posts from that story, but...
Step 1: Make frustration and annoying software
Step 2: Patent frustration detection system
Step 3: Profit.
C:\Program Files\ (Score:5, Interesting)
Funny, even now, I usually create a c:\programs\ directory for everything that doesn't have a proper installer. 10 years and counting.
IMO, the UAC did not have to be as annoying as it is. All they needed was a "allow admin stuff to happen for 5 minutes" dialog so that installing a program would only take one prompt. Too smart for their own good...
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).
Let me fix this for you... (Score:5, Funny)
There. All better.
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.
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:At last, a little truth from MS (Score:5, Insightful)
"Stupid is as stupid does", somebody once said.
Parent
Re:Turning off UAC doesn't require UAC confirmatio (Score:4, Informative)
UAC is not about confirming specific actions like changing registry keys. It is about giving Windows permissions to use admin-level privileges. For example, once you allow a command prompt to run with your admin token, it can then launch admin-level tasks without any new prompts.
Parent