Linked by Thom Holwerda on Fri 11th Apr 2008 21:47 UTC
Windows User Account Control is easily one of the most hated features of Windows Vista, according to readers. The seemingly endless stream of UAC pop-ups, asking you to confirm this action or that action, just get in the way (and aren't particularly zippy, given the screen redraw). Others don't mind UAC, but there's no doubt it's a controversial 'feature' of the OS. At the RSA 2008 confab in San Francisco, Microsoft admitted that UAC was designed, in fact, to annoy. Microsoft's David Cross came out and said so: "The reason we put UAC into the platform was to annoy users. I'm serious," said Cross. Cross had more to say than just that: Microsoft is going to put more emphasis on whitelisting.
Thread beginning with comment 309322
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Not so bad
by PlatformAgnostic on Sat 12th Apr 2008 17:13 UTC in reply to "RE: Not so bad"
PlatformAgnostic
Member since:
2006-01-02

Screwing around with the Start Menu engenders UAC prompts because large parts of the start menu are stored on a system-wide basis. I did a thought experiment about how one would implement this on a per-user basis with a shared system view, but I couldn't think of anything great because you'd have to merge any changes to the global start menu groups into a potentially changed set of per-use groups. I just tend to use the start menu search feature and igore the particulars of my start menu's organization.

On the reliability and perf monitor, I think it should require admin access because the program needs information about the specific Disk, CPU, and Network activity of everything on the system. Allowing untrusted users to see this information would be classiied as an Information Disclosure Vulnerability.

Reply Parent Bookmark Score: 2

RE[3]: Not so bad
by gustl on Sat 12th Apr 2008 20:56 in reply to "RE[2]: Not so bad"
gustl Member since:
2006-01-19

I did a thought experiment about how one would implement this on a per-user basis with a shared system view, but I couldn't think of anything great ...


Well, how about how the Linux desktops do it (Gnome as well as KDE). They are TWO different desktops and manage to have the same menu entries no matter if you log into a Gnome session or a KDE session.
Additionally there are system-wide setings for the Start menu (changeable by root) and user-specific changes to that system-wide settings.

Therefore, when root installs a new program, the entry is made to the system-wide settings, and as no modification entry is in the user-specific setting, the new program is displayed.
It is very easy and works well. The same is done with mime-type settings (which kind of file to be opened with which application).

On the reliability and perf monitor, I think it should require admin access because the program needs information about the specific Disk, CPU, and Network activity of everything on the system. Allowing untrusted users to see this information would be classiied as an Information Disclosure Vulnerability.


Quite the opposite is the reality. In the company I work for we calculate stresses and safety factors of engine parts with FiniteElement software. We need to know which machine is under which load when we start another number-crunching job. Needing admin rights just to get the information is ridiculus. I agree that priority enhancing ones process or priority changes to an other users process require admin rights, but not for getting information. Security by obscurity does not work, so why even try that approach. If the system becomes insecure when somebody finds out about it's load, network, memory and disk status, it's security is not worth much.

Reply Parent Bookmark Score: 6

RE[4]: Not so bad
by PlatformAgnostic on Mon 14th Apr 2008 06:44 in reply to "RE[3]: Not so bad"
PlatformAgnostic Member since:
2006-01-02

I agree that there are some reasonable scenarios where you'd want someone who's non-admin to be able to access performance statistics. Thus there exist two built-in groups on my Vista Business installation: "Performance Log Users" and "Performance Monitor Users." I haven't tested those myself, but based on their names and description strings I believe that these groups give you what you want: the ability to grant non-admin users the right to view perf data for the whole machine.

Reply Parent Bookmark Score: 2

RE[3]: Not so bad
by bnolsen on Sun 13th Apr 2008 15:00 in reply to "RE[2]: Not so bad"
bnolsen Member since:
2006-01-06

Thanks for describing some few of the severe system design and implementation faults Microsoft has had for more than 10 years.

Explaining why isn't an excuse. They should have just fixed this crap years ago.

Reply Parent Bookmark Score: 2

RE[4]: Not so bad
by PlatformAgnostic on Mon 14th Apr 2008 06:49 in reply to "RE[3]: Not so bad"
PlatformAgnostic Member since:
2006-01-02

First of all, I don't exactly see what you consider to be a flaw (or how you'd design it differently). Second, I don't see your implementation of a time machine that I could use to fix flaws 10 years ago before apps took reasonable dependencies on whatever design decision you're complaining about.

Reply Parent Bookmark Score: 2

RE[3]: Not so bad
by google_ninja on Sun 13th Apr 2008 21:00 in reply to "RE[2]: Not so bad"
google_ninja Member since:
2006-02-05

On the reliability and perf monitor, I think it should require admin access because the program needs information about the specific Disk, CPU, and Network activity of everything on the system. Allowing untrusted users to see this information would be classiied as an Information Disclosure Vulnerability.


On Vista Business, maybe, on Server 2k8, definately. But Vista Home/Ultimate?

Reply Parent Bookmark Score: 2

RE[4]: Not so bad
by PlatformAgnostic on Mon 14th Apr 2008 06:55 in reply to "RE[3]: Not so bad"
PlatformAgnostic Member since:
2006-01-02

If you want to grant people that right, there are ways (see my earlier response).

On the Home vs. Business distinction, I think it's general practice to keep the SKUs of an OS as similar in shared configuration as possible so that it's clear what should happen when you move from one SKU to the other (like through Windows Anytime Upgrade).

Maybe the people who own that MMC snap-in will make some tweaks to make it accessible securely to less-privileged users, but that was apparently not a priority so far (it's far more important to have something which you can later tweak given the feedback of the first version than to not have that thing at all).

Reply Parent Bookmark Score: 2