Slashdot Mirror
Vista's Troublesome UAC is Developer's Fault?
MythMoth wonders: "We've heard all about the pain and discomfort of working with Windows' User Account Control (UAC) switched on, but now Ian Griffiths is explaining that the developers are the problem — they brought it on themselves. In earlier articles we have heard that Microsoft think that everyone should do it like this — Ian does acknowledge that things are better in the Unix world, but is he right? Is the onus now on the developers to help fix a problem that they did not cause?"
Rather than ask the user for permission on every operation, what other ways could Microsoft have improved Vista's security?
I kind of like the concept of UAC. I mean the messages are so annoying that hopefully developers will start to avoid getting them pop up.
Hopefully this will cause applications to stay the hell out of the Windows directory, the registry and wherever else they seem to think would be a good place to sprinkle data randomly. I pine for the days of being able to uninstall a program fully from my system by deleting its folder. Or being able to simply copy a configuration file from one computer to the next and having all my settings preserved.
Perhaps I'm forgetting how bad that system was in the DOS days, and I'd welcome people reminding me, but it is looking pretty good at the moment.
Hmm, I'd say he's got a good point - there's simply not a culture of privilege awareness in Windows developers.
Perhaps Microsoft should set up an audit unit and start giving software a 'UAC-compatible' tick if a piece of software has minimised how much UAC approval is required if its turned on, allowing the publisher to put it on their box so that the customers can tell. Who knows, perhaps one day the UAC system might actually be viable.
Which goes to exactly what Ian was saying -- If you're really seeing UAC that often, you're doing something wrong (or you're using software from developers who did something wrong). As developers get their act together and stop requiring admin privileges for trivial things (hint: using %userprofile% and HKCU rather than %programfiles% and HKLM will solve 90% of your admin-privilege requirements when developing), UAC prompts should appear less and less often, and then only when you really expect them (you're doing system configuration stuff) or when there's a real issue that you should deny. Unfortunately, that world is probably 3+ years away as developers get with the program and rev their software, and in the meantime UAC will just become one more annoying dialog you have to click through to do anything.
With that said, I saw the UAC dialog exactly once today, and that was only because I had to upgrade my video drivers. I'm a professional software developer. I spend my time with Visual Studio and SQL Server, and I rarely have to deal with UAC prompts.
on Windows, on Unix and on OS X.
The problem on Windows is that it is a single user operating system with delusions of being a multi-user operating system.
The problem on Unix is that it is a time sharing operating system which people inexplicably use as a workstation operating system.
The problem on OS X is that there are no serious threats, so no-one has any idea if their security model does anything because it never gets tested.
And the problem with all three of them is that they assume that the program will always do what the user wants and therefore the program should inherit permissions from the user. On Windows that was never true. On Unix it was only true back when all users were developers and had enough time to read the source code to all the programs they ran and thus felt they could trust them. On OS X it was actually true because, again, no-one writes malware for OS X.
The security model should be, quite simply: the program has a manifest that declares what permissions it needs with a fine granularity. The permissions should be placed into a hierarchy. For example: writes to disk -> writes to user files -> writes to user files of type X. The user should be able to inspect these permissions to determine if they are acceptable. If they are not, then the user should be free to uncheck "required" permissions.. the program should still run but those functions of the program which invoke a required permission should cause a prompt. The prompt should give the option to deny the request, or fake the request so it appears to the program that it completed successfully.
And yes, developers should use this mode.. and they would, because it is actually useful instead of just being a pain.
How we know is more important than what we know.
Once people start to understand UAC and how it works, people will begin to harness it and accept it rather than shun away from it.
/priv" in a normal shell under the administrator logon. Now open up a shell using "Run as administrator" and type "whoami /priv".
.manifest file and place it in the same directory as the .exe. The manifest file is just an xml file that tells Vista that the .exe will require administrator privileges to run (queue UAC.) Google "vista manifest" or check this out for more information: http://channel9.msdn.com/Showpost.aspx?postid=2112 71
UAC allows administrators to be logged in 24/7 without having 20+ privileges until the actually need that power. 99% of the time UAC will strip the administrator privileges away from the administrator and grant them with 6 SeXXX privileges to work with. It does this by using two different tokens instead of one. The first is a normal user token, and the second is the real administrator token. When you see that screen where UAC asks for elevation, that's when Vista will grant you the administrator token. Don't believe me? Type "whoami
Vista isn't the shining example of everything secure, but it sure is lightyears ahead of XP and a real good step in the correct direction. Windows users will whine and gripe about it, but they will eventually have to go through the same stuff the *nix crowd did along time ago when people were logged in with root 24/7.
If you require Vista to elevate you with certain apps, then create a
Enjoy..
h
Valkyrie is about to die! Wizard needs food -- badly!
VS2005 does not require you to run with admin privileges. There are some scenarios that require this, but they're generally the exception rather than the rule. If you want to do something like create a new IIS website on your local machine from within VS you'll need to launch VS elevated, but this is because IIS requires administrative privileges to accomplish this task. For VS 2005, there wasn't much we could do about that. Let me know if you want more information about the topic. I was the developer division's go-to guy for UAC for a year.
No, but I used to work for Microsoft.
Note: I'm normally a Microsoft defender here, but I've spent too much of the last eight months dealing with Vista breaking-changes. Onto the rant...
This is such utter nonsense. UAC first came in, IIRC, in Beta 2 (May), but there were far too many problems with Vista over the beta/RC cycle to be workable. UAC was too annoying to leave turned on while trying to figure out the real bugs. UAC is still awful over remote desktop on a slower connection, as it blanks the screen. This cycle was nothing like the 2k or XP cycles with regards to beta and RC stability and direction.
One of our long-released apps went through this:
Beta 1:
Some draw issues, crashes on exit.
Beta 2:
Some draw issues, just fine.
RC1:
Some different draw issues, crashes a helper process on startup, then a second crash, completely, app dead.
RC2:
Some completely different draw issues (others gone), otherwise fine.
Release:
Same draw issues as RC2, crashes a helper process on startup, annoying help pop-up for any plug-in expecting old-school help to be available.
This was a released app for which the shipping bits did not change, at all, over the Vista cycle.
Now, it gets worse with UAC, because there are things that get more restrictive when the user gets sick of UAC and turns it off. The most obvious example is the "can't write to the TEMP folder" defect (by design? The designer is defective.). This kept several installers from working properly. If the user shuts UAC off, apps can no longer write to the TEMP directory and run their expanded installer app (winzip installer approach). This means that getting tired of UAC and pulling the plug on this behavior still interferes in the use of the system. In this case, it will hand the user a cryptic error message and no direction.
They went down this road with things like broken file-sharing and remote-desktop access with no-password accounts in XP, and it continues throughout Vista. Users of Microsoft products are regular victims of hidden behaviors, where seemingly simple changes can have much-delayed distant results.
Microsoft once cared a great deal about backwards compatibility. Now they seem to expect all software vendors to re-code, re-compile, re-test, and re-deploy for an OS change, and that OS was a moving target for the year preceding its release.
We're handling it, but what happens to the software that was orphaned by companies that died (or moved to a different platform)?
That's not fair, to expect Office 97 to run fine on Vista. Well actually it is. If you had followed all of Microsoft's best practices, and work the platform as designed....you end up right where we are at today.
Were Microsoft programs ever written to be run as a low privileged user working only with the users folder in "Documents and Settings" and only writing to HKCU. With the installer designed to be run once as an Administrator to write files to "Program Files" and HKLM?
Yes, you could always run a low privileged account and change permissions on certain registry keys. But face it, these are a hack. Until recently, Microsoft never wrote software that way. They never seriously advocated it either. If they did, professional software such as Quickbooks 2001 or 2005 would run just fine on Vista.
Hell, the whole registry thing was a bad idea. In the Linux world, when you move to a new box, you can copy an rc file or folder from /etc and your rc file from your home directory and the program is configured to run properly on the new machine. Bash_rc for example. Most well behaved programs make few if any changes to other programs rc files. Very few of those even need any files from /etc, usually just one file or folder from your user directory is enough.
Most of the time in Windows you can not even copy out the relevant section from HKLM and HKCU because of the shoddy programing practices as taught and evangelized by Microsoft. So many entries in the registry are spread out over so many places, the program won't run if you copy just one section from the registry. A good example is Outlook Express. You cant just copy out "Outlook Express" keys from HKCU and the data files and expect it to run.
If I had to point my finger at developers for bad practices. I will be pointing my finger towards Redmond Washington.
vi +
Waiting passively for the programmers to change their bad habits isn't the best strategy that could have be taken by microsoft.
... admin work on the machine as intended. They found thousands of bad-behaving softwares that can work under this envrionment.
:
: : /. developpers will be slow to change. They don't write code "perfect by the book", code that "somewhat works" is enough for most of them. Read sites like this if you don't believe.
:
As you state those problems stems from bad programming habits. Developers that have taken the habit of writing critical data just like in the old DOS days : wherever it pleases them, ignoring the fact that some place are supposed to be reserved for admins only.
It has worked up to WinXP because either there wasn't any protection (older DOS based Windowses) or all users did run as admins by default (newer NT based Windowses). Now that VISTA finally tries to correct this and approach something that looks like Unix' habits - using admin-level privileges for doing
BUT THEY'VE TAKEN THE WRONG ROUTE AROUND THE PROBLEM !!!
With such problems you have three solutions
- IGNORE THEM. Let the bad-behaving software just crash or display error message. That would attract attention to the fact that those software are broken. BUT ! Most users will believe that errors appear because Vista is buggy. The new version will get a bad reputation (as if the rest wasn't enough) and no users would like to switch. Microsoft would loose valuable market shares.
-> So that's why microsoft doesn't do it.
This behavious only works on Unices because most of the other software function correctly and users guess that the problems comes from the badly-behaving software and they try to download a corrected newer version or a better alternative.
- ASK USER'S PERMISSION. Do some 'sudo'-style privilege escalation for every single action that would require admin rights. And hope that developer will notice and produce more Vista-compatible softwares.
-> This is what microsoft has done, BUT THIS IS FUNDAMENTALLY WRONG.
Because concerning users
- It floods them with a mass of annoying blocking popups asking for privileges. The users ends-up first answering OK to everything (and the Unix style protection is completly lost) and then they disable the whole UAC to stop the flow of popups. So it is as if it wasn't introduced in vista in the first place.
And concerning developers
- As pointed by other
- Changing may be difficult for them, because it would require re-doing the whole program architecture. Or it could pose problem to migration between the older bad-behaving version and the newer vista-compatible version, and there's a huge users pool that the developpers want to avoid pissing because of a non-trivial migration.
- And finally, they aren't compelled to change this, because users are running with UAC disabled anyway.
The last solution would be
- VIRTUALIZE IT. Put all old-world (pre-Vista) software in a sandbox, a chroot jail, or whatever it is called in Windows. Whenever some pre-Vista software tries to access stuff it shouldn't in a normal user context, just do it - but on a dummy local copy to both avoid damaging the system and avoid annoying the user. That's the route that Apple has went were pre-OSX apps are ran inside some kind of emulator. But that is easier for them because of the radical shift in architecture : older software rely on a such different API, that it had to be emulated anyway, throwing a sandbox in the mix was only an added bonus.
Microsoft could do it as easily, because, fundamentally, Vista is XP with a shiny interface and some DRM thrown in. It would have annoyed users : They used to ran perfectly well behaving software writen for NT-Kernel under XP and suddenly, under Vista which uses mostly the same internal structure they have to run the same software inside a sandbox.
Microsoft SHOULD have spent a lot of time planning well the transit
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]