Last Updated: 2009-01-31 21:47:42 UTC
by Swa Frantzen (Version: 2)
While it is still a beta program, and as such not very interesting to report on yet, there is a little buzz about a Windows 7 security sacrifice to usability.
Basically Windows 7 beta "fixed" the annoying Vista security prompts by allowing the user to set it up (and set so by default) that the UAC only prompts for "Notify me only when programs try to make changes to my computer" and "Don't notify me when I make changes to Windows settings". The tricky bit of course is to be able to differentiate between what a program initiates and what the user initiates (the user is after all always controlling a piece of software).
It seems the Windows 7 beta isn't very good at making that critical difference as it got beaten already.
The authors have a workaround ready: change the setting to always prompt, (iow.: bring the annoying prompt from Vista back)
The entire thing is a bit typical for an approach where there is put a lot of value on what the user does. While for home situations it might make sense at some level; for corporate situations where control is needed putting the user in charge of security it hardly ever is considered a good solution as the user can be tricked by various means into choosing the wrong course of action.
Perhaps a solution would be in radically different ways of working between a "home" edition and a "business" edition (far more than the incomprehensible marketing and fancy gui sauce it is today), with a series of settings and ways to allow control over them that are radically different. In the end the home users often are alone, so separation of duties etc. is very hard to implement properly. While those same separate roles are already in place in places that need a more secure setup, but they get hampered by the permissive nature of the software designed for home use.
Still if you look at the past few years worth of severity ratings in MS0X-0XX bulletins, you'll notice a consistent trend to rate the severity of a problem significantly lower if the user had to confirm something. This isn't just for the OS, but just as well for e.g. the office suite. Now if you want to know how a regular user reacts to these prompts: watch them without them being aware of your interest and see them click to get the pop-up that's blocking them from doing what they want to do -without reading-, just finding the ok/continue/next/approve/... and clicking as fast as possible on it.
So what's the real value of a reactive user approval ?
- They typically don't even read the warnings at all, just want to get to the good bits
- They are vulnerable to allow it even if they would know better due to social engineering
So how do other OSes handle this ?
The traditional unix solution is to have regular users and "root" separate the tasks: the regular user typically cannot change settings, only root can do that and one has to either:
- log in as root (best practices block this avenue)
- become root using su (optionally only allowed for users in the wheel group, requires knowledge of the root password)
- execute a command using sudo for users with the needed privileges (not needing to know the root password)
Note that all of these require an up front action by the user to get more rights, and no initiative is given to applications that prompt users for more rights.
A modern Mac OS X machine has that same unix pedigree (sudo works perfectly fine on a mac, root by default has no password so the other two avenues are closed), but also has an added graphical equivalent of sudo that walks the far more dangerous path of prompting the user for its password as needed, allowing software to take initiative and leaving the user with a judgment call to make.
Have you seen other security default settings in Windows 7 beta you don't agree with ? Let us know!
UPDATE: A reader wishing to be anonymous pointed to the follow-up story by the original reporters. Basically it boils down that they say Miscrosoft persists in this and worst of all: that Microsoft doesn't consider it a vulnerability.
Swa Frantzen -- Section 66