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?

Comments

I kinda like the concept

[Frogbert]

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.

Re:I saw a different problem

[fwarren]

Take a look at what we call "good programming practices" in the Windows world. Look at the windows programming bibles. Look at how many programs written by Microsoft that are not designed to be administrative programs break on Vista.

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.

Waiting PASSIVELY is not a good solution.

[DrYak]

Waiting passively for the programmers to change their bad habits isn't the best strategy that could have be taken by microsoft.

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 ... admin work on the machine as intended. They found thousands of bad-behaving softwares that can work under this envrionment.

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 /. 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.
- 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