Reducing Elevation Prompts in RC1

Article
06/01/2006

First, let me introduce myself, my name is Steve Hiskey, and I am the Lead Program Manager for User Account Control in the Windows Security Core group. Although there are many groups at Microsoft that are contributing to UAC, the Windows Security Core group has primary ownership. We own the feature and take the heat if something is wrong.

One of the primary goals of the UAC effort is that the user should see a reduction in UAC elevation prompts over time. We expected that the user would see a bunch of elevation prompts when they are first setting up the system, but that the prompt frequency would dramatically reduce over time, usually after the first few days, and after that they would only appear for infrequent events such as adding new software.

However, as many of you have witnessed, there are a LOT of UAC elevation prompts in Feb CTP and still more than we would like in Beta 2. Therefore, I would like to take a moment and discuss the issue and give some details on what we are going to combat the problem.

I get asked a series of standard questions when I deal with this problem, so let’s take that format:

Question 1: Why does Windows ask me for permission when I JUST double clicked on the executable or clicked on the shielded object?

The issue here is extensibility of Windows. Windows prides itself it on being pluggable and extendable. For example, to facilitate the accessibility extensions, Windows needs to be able to send keystrokes on the user’s behalf so that a Windows user can talk to an input device and have that be translated into keystrokes that drive a dialog or type an email message. This also allows interesting and useful scenarios such as “show me how” buttons inside help dialogs.

However, that means that malware, running as a Standard User, can download an administrative application, and send keystrokes through Windows to simulate the user invoking the application. As a result, Windows cannot tell if YOU launched the application or if malware launched the application.

The hope here is that the user won’t need to launch many administrative applications. If we fix every “runtime” issue where an application is asking for administrative privileges without a real need and leave elevation to JUST adding applications to the machine or doing impactful changes, it should not happen too often.

Once that is true, we can then move to educating the users to know that “good” elevations are ones that they initiated and “bad” elevations are ones that suddenly appear without their explicit action. We want the users to think “if an elevation dialog appears while I am reading my email, and I didn’t perform any action that would require elevation, always cancel those dialogs.”

Question 2: How come I cannot mark OS binaries to silently elevate? Why do I have to keep consenting to elevate things like Windows Update?

The problem with marking Windows binaries to “silently elevate” is that we feel it will lead to “worms” or self propagating malware. If, for example, the user marks MMC.exe (the Microsoft Management Console) as “silent elevate” so that the device setup dialogs don’t prompt for elevation, malware running as Standard User would be able to use that setting to launch MMC with a set of command line parameters that accomplish tasks that we don’t want to happen silently, such as adding a new admin account to the system. As another example, if you mark Format.com as a “silent elevator,” malware can then do a format of the OS drive.

The rationale for people wanting to mark OS components to silently elevate is based on the belief that the elevation dialog is being presented too often for OS components. We will discuss how we are going to reduce these elevations later in this blog.

Question 3: How is my Parentally Controlled child supposed to elevate every day to run Anti-Virus and Spyware cleaners?

Answer: They are not supposed to. Anti-virus applications designed for Windows Vista should be services that are installed by an administrator and run automatically even when a user is not logged on. Ideally, anti-virus applications even include file-system extensions (filter drivers) that can watch every write to the file system, no matter who is logged on.

In fact, there should be ZERO elevations as part of the login operation. We are working hard with ISVs (both inside Microsoft and external) to make this happen.

The Plan

That being said, we still have work to do. There are simply too many elevations. So let’s take some time to discuss what changes the Windows Vista team is putting in place.

1) Make changes in the OS to create safe scenarios for the Standard User to accomplish tasks that used require an elevation prompt.

2) Apply application compatibility fixes (“shims”) for the applications that need help running as Standard User.

3) Work with ISVs to update the applications that can’t be shimmed and to design the future applications so that the next generation run well as Standard User.

Changes in the OS

To continue improving the OS to reduce the elevation prompts, we are working from Beta 2 to RC1 to add new functionality to allow the Standard User to perform actions that used to require elevation.

For example, in RC1, the Standard User will be able to “go get and install all critical updates” without elevating. The Admin and the Standard User could “install updates and shutdown” in Beta 2, but they were not allowed to “get them now” without an elevation prompt. We didn’t open up the Windows Update Service to be generically “driven” by a Standard User application to do this. For example, there will still be an elevation dialog to remove an update or to “take update #1 and #3, but not update #2.” New code was added to allow the service to be called by a Standard User to “install all critical updates.” Malware calling this entry point in the service can “make the system safer” but cannot roll back updates etc.

We are also going through the OS and modifying functionality to take a “non elevating default”. For example in the case of the “Public vs Private” network choice, the default choice will become “Public“ to save an elevation.

In RC1, we are going through the OS point by point on each elevation to make a determination if the elevation is a “bad” elevation where we think the Standard User can safely accomplish the task. You should see significant improvement in RC1 in the number of elevations that you see.

“Shim” the applications

Note a “Shim” is a set of rules and code that can be applied to a specific application or a group of applications. An example shim would be “when the app foo.exe asks for the Windows version, tell it what it wants to hear, ‘Windows XP,’ so that the app continues to work past its broken version check.”

Some applications, such as a popular web-camera application and Microsoft Messenger Auto Update application, were elevating every time the user logged on. We have shimmed these applications to work as Standard User in Beta 2.

We have a VERY high percentage of successfully shimming applications to run well as Standard User. We just have to know about them. Tell us about them by replying to this blog and by using Windows Vista Beta 2 on your PC. We have instrumentation in place that tells us anonymously what is causing prompts to appear for users. We look at this data every week so we know the most important issues to work on.

We are also working hard on a generic “shotgun” shim that can be run by the end user and will hopefully fix a large percentage of applications. We will blog more on this in the coming weeks.

Work with ISVs

We are attempting to reach as many ISVs as part of Beta 2 as possible. We have written developer guidance, provided a tool to debug applications on XP and Windows Vista and are starting an outreach program that will help ISVs and Enterprise customers debug their applications with a traveling lab.

Here are some links to get you started if you are an ISV or if you have a favorite ISV that you want to send them to:

· Link to the Standard User Analysis tool blog

· Windows Vista Readiness Labs at TechEd 06

· UAC developer white paper

Conclusion

Reducing the number of elevation prompts that a user sees is our primary job from now until RC1. We know that it is causing frustration (and bad press articles) are we are working to turn that around. We have to make a good experience, even for people that don’t understand why they are safer with the prompts. It would not be helpful to security if people turned off UAC because they found it too annoying.

We hope that the reality will become:

1. You rarely see an elevation prompt.

2. You understand that if you see an elevation prompt, it is because you just asked the system to run setup on something

3. You understand that if you did NOT initiate the action that caused the elevation prompt, that you should cancel the elevation.

4. You understand that signed apps are better than unsigned apps because they give you more information about the reason for the elevation.

The home user may see prompts during their initial setup as they reload their applications, but after that, they should only see OS elevation prompts when they do something that changes the system… such as changing Parental Control settings etc.

Don’t give up on the feature yet!

We are working to change the way EVERYBODY runs Windows. As we move towards RC1, we are dealing with the number of elevation prompts as our Job #1. Help us out by playing with the Beta 2, and tell us about your elevations by adding comments to this blog so that we can make them go away.

Call to Action

Install Beta 2! Give us feedback in the blog comments to this blog!

· Tell us about the applications you are using that elevate every time you use them. I am not talking about admin applications here such as your disk-maintenance tools. But if your favorite photo editor elevates every time you use it, we want to know so we can shim it to work as Standard User or, failing that, we will work with the ISV to get the application fixed.

· Tell us about applications that elevate every time you log in. We need to fix or remove every one of these scenarios.

· Tell us about your most annoying OS elevations that you wish would go away.

Thanks,

Steve

Comments

Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
zzz - The shims Steve is referring to don't allow an app to do administrative things. The example he gave is about telling the buggy app what it wants to hear. Another type of shim that will be used a lot is file and registry virtualization - where file/reg operations are silently redirected, from the system-wide locations the app is trying to access, to a per-user virtualized store. Malware can still try to do bad things, but: 1) It can't modify the way the OS runs; and 2) It can't affect other users on the computer.

We fully expect that malware will adapt to the new realities, and take lower-privilege contexts into account. However, malware running with normal user privileges will be far easier to detect and remove than malware that has full admin rights. One prime example is that it will not be able to install kernel-mode rootkits.
Anonymous
June 01, 2006
Not to be nitpicky, but you might want to edit this entry to be more readable... the text size is way too small to be read on the "Normal" text size setting in IE.
Anonymous
June 01, 2006
Why is Windows so complicated? I mean, when Unix/Linux can so very easily handle admin/user accounts, why can't Windows implement something that works as easily.

(I don't use Linux every day. I use Windows and I like using it, I like the applications, the games and everything about it - except Windows Vista)
Anonymous
June 01, 2006
Visual Basic 6 requires elevation to work properly. At first I tried to check the "Run as administrator" checkbox, but the elevation prompt was so annoying that I disabled UAC.

The elevation prompt was also takin 2-3 seconds to display, and causing my screen to flicker.
Anonymous
June 01, 2006
Robert...you are always nitpicky.. :P
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
We fixed deleting Desktop Icons in the current RC1 builds. Unfortunately, the Beta 2 build still has the (many) step user experience. It is an interesting dilemma on how ISVs should write their installers to place icons though. The advantage to putting the icon on the all-users desktop is that any NEW user will also get the icon. We (windows) need to add some sort of “hide” technology to have it both ways… and we haven’t done that yet.
TaskMgr now defaults to a non-elevated version … and has a button on it to ‘show all users’ which requires elevation. We hope that handles most of the issues people have as they look to TaskMgr to tell them why they are out of memory etc.
I will check into the “Set” operation… but allowing a Standard User to modify the environment for all users or all apps is dangerous. My guess is that it is where it is for a good reason.

Steve
Anonymous
June 01, 2006
pseudo#:

if user isin administrators then have installers place new start menu icons in all users start menu

else

have installers place icons only in the current user menu
Anonymous
June 01, 2006
Interesting explanation of the changes (and some of the reasonings behind the prompts). Could your future posts reflect some of the decisions made on certain prompts? (like the example you gave of executing an exe). That should give ISVs and developers a good idea if certain (similar) actions in their case needs to be elevated.
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
Not 100% sure if it is just myself not knowing how to configure Vista properly or not, however I get asked quite frequently to elevate to delete things from the desktop. For example, when I first installed, I changed the file settings so that it shows all files (including hidden). When I did that, it displayed two copies of the desktop.ini files. So i attempted to delete them, and found that I required administrator access to do that (which i thought i had, being in the administrators group), and then i had to elevate to delete from my accounts desktop.

There has been a heap of others, including problems accessing registry but I'm sure these will be resolved in time.

Thanks!
Anonymous
June 01, 2006
The ability for standard users to do a Windows Update is a bit worrisome. In a home environment, do you really want your kids to be able to perform an update? I think that "allow standard users to do windows update" should be disabled by default; let admins (parents) explicitly say that standard users can update. Maybe, after the user elevates Update for the first time, ask them if they want to open this up for all users in the future.

(For the various business SKUs, this should definitely be off by default.)

My comments above are about standard user. Maybe, make it so that standard users can't do it without elevating, but members of the administrators group (i.e. protected admins) can.
Anonymous
June 01, 2006
I agree with Gaurav's remark #8, there should be a visual way to know that a given window is elevated. I know, it's spoofable, but all it tells you is you should be more careful with that window. Unfortunately it is probably too late in the development cycle for such a big change.
Anonymous
June 01, 2006
Expanding on Gaurav's remark #2... read-only mode would be great for many of these uses. This is what was wrong with the Clock for so long: it assumed you wanted to change the time instead of view a calendar.

The MMC approach is like using a hammer on a pushpin: elevating the entire MMC shell instead of elevating individual actions within it. Though, if you were doing a bunch of administrative work in MMC, you wouldn't want to have to keep elevating little things here and there. (Of course, in that case if you know you're going to be doing a lot of administrative stuff, you could've manually run it elevated from the start.)
Anonymous
June 01, 2006
PatriotB: Re Windows Update - what risk do you see with a Standard User (e.g., the kids) being able to install the current set of critical updates without asking for help?
Anonymous
June 02, 2006
I must say I like this feature though any and all reductions in unneeded prompts is a must and thank you for working on it.

The one major app I have to keep running elevated myself because it has issues running as standard is Photoshop CS2. It always has trouble accessing preference files after the first load without privileges.
Also for general compatibility, I've noticed the vitalization of program files for preferences is working great in say mIRC, but for some reason it fails with HydraIRC. From what I can work out, vitalization is writing the compatibility files but then HydraIRC is making some sort of read request to original ones which vitalization isn't catching.

For general ideas, I like the idea of marking elevated applications and services.
Another problem I've seen is opening say notepad to open a file stored in a administration area such as Program Files and then trying to save it. There's no easy way currently to open a file in an elevated version of an application. You have to open the app elevated, then File > Open the file you want to edit. (Drag drop from Explorer to application seems to crash Explorer). Could open with elevated application be added as an option to the Open With... dialog?
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
When logged in as an administrator, the default elevation setting is to request confirmation but not require a password, no? Since malware can imitate user input, for any reasonably sophisticated malicious program isn't this functionally identical to having no prompt?
Anonymous
June 02, 2006
Why on earth would any sane person knowingly allow a computer program to impersonate themselves or others? An app that can type into an e-mail application and send the as if I had sent it? Can you say spamming that is totally out of control? If someone gains access to a computer and places code that does this, is the spam blocker now supposed to be able to discern human typing versus machine typing? I can see the AV software prompt now:: "I'm sorry, your typing interval is too regular therefore please retype the last paragragh so that I know you are a real person."

I now have the best reason in the world to dodge Windows Vista. Security in it is worse than XP.
Anonymous
June 02, 2006
As far as how apps should install desktop icons for all users, this is what I propose:

Assume the app install is running elevated.

If the user requests the app to be installed only for that user, the desktop icon should be placed in that user's desktop directory.

If the user requests the app to be installed for ALL users, then the install app should enumerate all of the existing users and place the desktop icon in each user's desktop directory. The install app should also place the desktop icon in the "Default User" desktop directory, so that it will be copied to the desktop directory of any new users.

On uninstall, the app should do the inverse: If it was installed for ALL users, it should enmerate the users and remove itself from all of their desktops, as well from the "Default User".

Isn't that the right way to make this work?
Anonymous
June 02, 2006
Automatic updates should be on by default and only allow a person logged on as full Administrator to change that.

BTW.

Half the time trying to enter this page from Slashdot, Community Server gives an error.

Doesn't CS scale or is there a problem with MSDN blogs?
Anonymous
June 02, 2006
"An app that can type into an e-mail application and send the as if I had sent it? Can you say spamming that is totally out of control?"

Can you say "speech-to-text for accessibility"? Keep on raging against that machine, though.
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
Re: Thursday, June 01, 2006 5:18 PM by User Account Control Team

Please consider whether the "all users" desktop and start menu could stay as they are.
An additional "new users" desktop and start menu could then be created and ISVs encouraged to use them (or them used by default).

On creation of a new user, the contents of "new users" is then copied.

For example, if a short cut to Outlook was on the desktop, some users may want to delete it, other users may want to rename it, or move it, or change the parameters...
This would keep "adding" the items by default - but allow all properties to be changed - not just being hidden.
Anonymous
June 02, 2006
Why is it that everytime you steal a feature from OSX, you twist it in such a way that it loses most of its benifits. If your going to try to make windows look like OSX, at least just steal the features straight up, your "improvements" just wreck things.
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
Install Beta 2! Give us feedback in the blog comments to this blog!

Beta 2 is still not available to the public, only to IT professionals and developers. It would be awesome to have a real public beta for everyone like linux distros do, and of course, the beta should be free of charge and use.
Anonymous
June 02, 2006
Ultimately it seems that the reason for this UAC prompt is that you want the user to understand that: "if you did NOT initiate the action that caused the elevation prompt, that you should cancel the elevation. "

Or you could look at the problem this way: UAC's purpose is to help the user distingish if the actions being taken are as a result of their actions, or as a result of a malicious program impersonating them.

So my question is this, why is there no way to differentiate the type of input? At a most basic level, a chain of actions or events should have a root cause associated with them. If a user is responsible for actions then HAL input would be the root cause, where as a program would have a different cause.

It would make prompts for deleting things like the desktop shortcuts a non-issue. The OS knows that the user is taking the action.

I've not spent a whole lot of time thinking about the issue but it seems at first brush that the underlying problem is that the OS does not know the source of the command, and ultimately the OS cannot trust any input, so it must question everything. Build a chain of trust and part of this issue is solved.
Anonymous
June 02, 2006
UAC Should not pop up if I'm running as an admininstrator, only on a user account. If I log on as root in linux, the assumption is made that I did it for a reason. If I log in as non-privledged, then I need to use SU/UAC to give admin credentials.

It's nonsense that while I'm logged in as administrator, a prompt tells me I need administrative access.. Guess what?? I have it so leave me alone.
Anonymous
June 02, 2006
Re: Why does Windows ask me for permission when I JUST double clicked on the executable or clicked on the shielded object?

...why couldn't the source of the event that caused the application to start be tracked; e.g. if the application was started by a user clicking a mouse that is directly attached to the local machine, consider it a trusted source and just run the app; if it comes from a remote source, then pop up the dialog?
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
Hi,
I recently came to know UAP was extended to apply to Network based communication. It also adds in some new requirements like machines in same domain can successfully communicate but others cannot.
I am looking for more info on this design/strategy and any limitations it causes.
Any workarounds on solutions would be great.
Anonymous
June 02, 2006
Firstly, great for working on keeping the feature in and enabled. It should help with a lot of issues.

Secondly, on a more philosophical/design level, while "elevation requests when user hasn't obviously triggered = bad" makes sense, I'd be worried if the average user was told/encouraged to believe/acclimatised towards believing that elevetion requests during certain tasks/on user action are always good. That could make it too easy for malicious insertion during commonly elevated tasks - it does some of the social engineering for the attacker.
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
One major annoyance with me is that I have a second partition (hard drive) for where all my pictures and data are, and when I do a clean install of Vista and try to fix those pictures in Photo Gallery, it tells me that the pictures are read-only. I know this is related to UAC because when I turn UAC off, the pictures can be fixed.

This is a major annoyance for many people...

Thanks.

(And yes, I'm a beta tester and I've bugged this to no avail.)
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
When software installed it should digitally signed either by a trusted source like MSFT or the user themselves. Any OS resource should only be allowed if the source is code that is trusted. Any malware won't be trusted so it won't have access to those resources no matter what. Why wasn't this avenue of securing the OS pursued?
Anonymous
June 02, 2006
This is really great news! It is very good to know that your team is listening, and understands the level of overkill that has been created by the current system, and the serious potential for actually allowing a malware attack due to Users merely clicking out of frustration or laxity to continue on.

I think your plan is a good place to start, to build a system that will be both "User Friendly" and provide the kind of security you are after.

I will be happy to assist with feedback, as I am sure many others will as well, and look forward to seeing the improvements in this area in the future builds.

Thank you. :-)

Jan :)
Anonymous
June 02, 2006
Is Microsoft reinventing the wheel with Windows Vista?

I mean, we have filesystems, policy controls etc etc that can be used to control on who runs what.

The Unix world has done this for years..
Anonymous
June 02, 2006
Ok, a little on topic...the registry needs work. How about eliminating the hive for non system data or each app gets a hive that's mapped in for keys only it needs and writes to! You know, back to the individual ini file, only transparent to the app. Shared keys, like type registration stuff that the system needs, are linked to the app that created them. You know... I install app A, I uninstall app A, app A leaves all its type info and private data laying around, system deletes the apps hive and ALL registry info created by it.
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
I've been using Beta 2 for more then a week now and in order to fully understand it I've installed it on the 3 machines I use the most. In my personal opinion the dialog boxes frustrate me less and less the more I use the OS. They seem to just become a part of the greater machine. This is (I hope) more users will start to feel as time goes on. Some users (those who flame first) don't understand that while installing software it's 50% MSFT's new UAC and 50% bad software written for Vista (all 2 of them). So along with "teaching" users that when you want something changed you must approve it, you must teach software venders to abide by the rules of the land. (no writing to sensitive kernel areas) While this will definately be rough waters for both users and software vendors it will lead to a much better OS foundation. Now this all doesn't matter since once you install/remove software your productivity shouldn't be effected with dialogs to delete a shortcut.
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The problem seems to be that the administrative tools were designed from the ground up with the assumption that all users have admin rights.

UNIX, for instance uses the SUID bit to determine if a program should run as its owner or the user executing it; programs that are designed to run set-UID take this into account and examine the "effective" and "actual" uid/gid to determine the current user (and thus permission to carry out task XYZ). It seems that the Windows admin tools need to be redesigned to work properly in an environment like this.

As for people worrying about people sending heaps of spam via the sendkeys APIs... you are morons. This functionality has existed since the beginning of Windows; Google WM_CHAR and WM_KEYDOWN to see what I'm talking about. That's just how the GUI works; the OS passes messages to apps when events happen, and apps can post those same messages to other apps. This is a feature, not a bug.
Anonymous
June 02, 2006
Why don't you guys do something about the All Users folder?

The reason why people (and I running XP as a non-admin) have trouble deleting an icon from the desktop is because the icon is placed in the All Users profile.

So why not instead synchronize the %USERPROFILE% dir with %ALLUSERSPROFILE% partially when something is changed inside the ALLUSERSPROFILE? When a new icon is added to ALLUSERSPROFILE/Desktop copy it to all users, but then remember to which users you've copied it and don't ever do it again.

Dejan
Anonymous
June 02, 2006
You must be very careful as too many prompts will cause users to simply click them all 'yes' out of frustration which defeats their purpose. If I may be blunt this seems to be an asinine way to solve the problem.
Anonymous
June 02, 2006
re: "As a result, Windows cannot tell if YOU launched the application or if malware launched the application."

Give me a break. So instead of all this insanity perhaps we should let Windows know how the application was launched? We can't tell if keys were pressed on the keyboard or a mouse button was clicked? Are these not hardware events?
Anonymous
June 02, 2006
You probably considered this already, but I was wondering about the following scenario:

What if only trusted drivers and/or app are allowed to inject UI events in the Windows queue. For example, say signed HID drivers are allowed by default. The user is allowed to assign trustany other driver they wish.

Other than that, any untrusted app would require a previlidge escalation to inject UI events.

Just wondering why this scenario is not workable?
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
Hi,

I think your UAC feature need a second way to work...

I didn't read all the comments and i don't know if already suggested :

What about an "UAC helper" sitting in the task bar and allow to temporary elevate all the user's action ?

In my mind, a green icon says : you're in user mode, and a red icon says : you're in admin mode and reminds you every (user set a timing... says 15 minutes by default ?) X minutes...

I think it's better because user often perform admin tasks in "group" ("i want to update my drivers", or "i want to install some programs", or "i want to install my new printer and his programs" or "i want to delete some files" (doh...)), not once at a time.

hummm ? Who says "sudo reversed" ? ;-)

.
Anonymous
June 02, 2006
Wouldn't it be easier to just authenticate keystrokes and clicks on the computer's side rather than through user interaction? I doubt it's beyond Microsoft's ingenuity to just mark "virtual keystrokes" as such and prevent false "real keystrokes" by making some kind of encrypted keystroke protocol...
Anonymous
June 02, 2006
I would like that, in Windows Live Messenger, when the safetly scanner scans the pc,i should be
not be prompted by it , to elevate privelages.
yeah pls fix that.
Anonymous
June 02, 2006
THe Biggest Agrevation users have on a PC is too many popups that prevent them from working.

With UAC, windows now comes with its own built in "ad-bot"

UAC will be a failure, and is nothing more than an annoying person going "are you sure you want to do that?" over and over again

AXE THIS
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
To David Richardson:

There IS an audit trail for UAC. We added a field "elevation type" to the process creation event (event ID 4688 in the security log). You can use the auditpol.exe tool to turn on this feature, and then look in the security log.

auditpol.exe /set /subcategory:"Process Creation" /success:enable

Whenever a process is created, we will generate an audit record in the security log and record the elevation type.

Elevation type will be a numeric code: 1, 2, or 3.

Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account.

Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.

Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.

Eric
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
To everybody working on UAC: keep up the good work on trying to enforce a sane security policy in Vista as opposed to practically none before. For sure, UAC is breaking apps and habits which were bad to begin with; all this complaining about dialogs is Karmic payback for MS not putting a sensible policy in NT to begin with. I imagine your group is under a lot of pressure to make allowances; please RESIST them. Such comprimises really do comprimise the system, but I'm preaching to the choir by now.
Anonymous
June 02, 2006
In response to stan's comment: "And after that, do like we do.. if you want to make an admin job, log in as root (or just ask for the root password to run that program with root privileges). If you dont do it, you will get no permission."

If you log in as a regular user, this is exactly what happens. If you launch something requiring admin privileges, you have the ability to either provide the credentials, or cancel.

You can also mark -any- program to "Run as administrator" in compatibility properties, and you are presented with the same dialog to provide admin credentials.

I always run as non-admin, and only elevate when needed, and this is a much easier task on Vista than XP. The UAC prompt makes the process seamless.
Anonymous
June 02, 2006
Wow -- is this how developers at Microsoft get feedback? Through blogs? Steve, asking users for feedback through a blog is dangerous because, in general, only the most computer savvy are reading blogs and using Beta software, such as Vista. The audience of this blog is going to provide limited insight given the breadth of customers that will eventually use Vista. Sometimes I wish developers at Microsoft would let market research guide their decisions; rather, than a blog post answered by techies.
Anonymous
June 02, 2006
PingBack from http://tech.cybernetnews.com/2006/06/02/vistas-user-account-control-eases-up/
Anonymous
June 02, 2006
Why not ask confirmation when an application tries to send UI events to other windows? Programs that do this legitimately aren't that common, are they?
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
It sounds to me like the real problem is that Vista can't distinguish between real mouseclicks/key presses and virtual ones sent by software. If it could tell the difference, then there would be no need for these elevation prompts to come up repeatedly when the user deliberately initiated the action. Stop treating us like monkeys, MS!

I can tell you right now, that if UACs behavior doesn't improve radically, no one is going to willingly use it.

Trying to patch up every instance, for every piece of software and situation is going to be a neverending process. If you don't fix the core behavior, you'll never get it to work properly. Is MS going to have a UAC team shimming and patching for the rest of Vista's existence? And if shimming is possible, what's to stop malware developers from exploiting this?
Anonymous
June 03, 2006
Hi

I'm actually looking at a demo of UAC and I'm really hangry about it (sorry W. Moses, nothing against you).

1 - For the first time in the history of OS, I can't predict if I can do something by looking at the ACLs if I can open a file, run a programm or editing a registry key !

2 - For the first time I can't guess if I'm administrator of the machine by looking at membership. Why calling a group administrators if it's not. What will be consequences for people who setup / maintain / troubleshot ?

3 - As far as I know UAC block program it know not function so for exemple :
REGEDIT is blocked (even if we wanted to consult !!!)
REG.EXE in a command prompt is not blocked
So no impact on spy / viruses which uses their own path.

Basically that show that Microsoft is just making an interface for hidding things and for rejecting responsability : "you have been infected, huhu you removed UAC, that's why !!!"

So basically I'll sugest continue my efforts to train people (and me) :
1 - to set :
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem]
to
"EnableLUA"=dword:00000000
(that's disable UAC which is just useless and anoying)

2 - set ACLs correctly (on files and registry)

3 - users and admins must use users level accounts and RUNAS for needs.

Laurent Gébeau [MVP]
(actually at an EMEA Vista event in Amsterdam)
laurent.gebeau.at.toutwindows.com
Anonymous
June 03, 2006
Ok, there have been lots of comments about "distinguishing" between human-originated commands, and malware-originated commands. How would you propose there be a difference?

When it comes down to it, launching an executable is done via the CreateProcess API. Are you guys proposing that CreateProcess somehow looks all the way up the callstack until it finds "oh, the root of this is some Input function"? What if the app doesn't call CreateProcess from the same thread as the input came in on? E.g. Thread A gets some input, and sends a message to Thread B to launch a process. What do you do in this situation?

As a side note, I think a lot of what people would "ideally" want, would have been possible if NGSCB (Palladium) would have been implemented. But there was such an outcry from people about this, that MS decided not to go forward with it. You can't have it both ways.
Anonymous
June 03, 2006
"Wow -- is this how developers at Microsoft get feedback? Through blogs? Steve, asking users for feedback through a blog is dangerous because, in general, only the most computer savvy are reading blogs and using Beta software, such as Vista."

Blogs is probably the last place that any "real" feedback comes from. Consider all of these other sources of feedback:

- Technology Adoption Program (TAP) participants
- Corporate clients
- Thousands of beta testers
- Usability labs/inperson studies
- Feedback from third party ISV's
- Feedback from OEMs

I'd say feedback left on blogs is, while accepted, hardly the place where decision-making feedback comes from. You're right in that blog readers are not a typical representation of a product's audience. Microsoft has other ways of getting a real feel for how the product works across a wide spectrum of users.
Anonymous
June 03, 2006
"windows, whether it likes to admit it or not, is still an 8-bit os, with 16-bit capability built on top of it, and 32-bit capability built on top of that"

Ok, I don't know why I'm bothering trying to respond to this, but here goes...

NT was developed as a 32-bit OS from the start. Period. No 16-bit code in it, and certainly no 8-bit code.

Actually, at its core, all of NT is "bitness-agnostic", meaning that depending on compiler switches, you can build for either 32-bit x86, 64-bit x64, or 64-bit Itanium. And I've read on other blog posts that one of the requirements for code to get into Longhorn was that it had to be compileable to any of these three platforms.

So get educated.

And a last bit about the registry... Why do so many people have a problem with it? It's a heirarchical database of values. Much like a file system is a hierarchical database of files. So if your proposal is that instead of a registry database, we have a slew of individual files: it's just as easy (or, difficult) for a file system to get corrupted as it is for the registry to get corrupted. (Talking NT here, not 9x.)
Anonymous
June 03, 2006
I just removed a hundred fonts. It took an hour and eleventyseven volumes of cusswords at that blasted black plague.

I am SO frustrated that I will probably use Arial 10 for everything forever.
Anonymous
June 03, 2006
The comment has been removed
Anonymous
June 04, 2006
If we speak about Windows security, many people will tell you that Windows is unsecure operating system....
Anonymous
June 04, 2006
It's pretty silly to keep using accessibility as an excuse for not fixing the vulnerabilities due to malware sending keystrokes, reading the screen contents, etc.

The vast majority of apps are not accessibility tools. So allowing all apps to send keystrokes, and continually bothering the user just in case a piece of malware did this, is a clear failure to observe least privilege/authority.

Instead, the apps that actually need to be able to send keystrokes, read the screen, etc. (accessibility tools, macro players, automated GUI testing tools, and screen grabbers) should be marked, so that only they can do those things.
Anonymous
June 04, 2006
The comment has been removed
Anonymous
June 04, 2006
The comment has been removed
Anonymous
June 04, 2006
I normally don't run as administrator in XP, and I think that making it easier to run as non-administrator is good.

My concern is that in order to install a program I basically has to give it almost full access to my machine, which means that it can install malware as well (or more innocently take over file-associations, add desktop short-cuts, and replace the firewall).

The elevation prompt does not seem to give me any protection for this scenario, since I obviously intended to install something.

As I see it there are two solutions for this:

1. Having the ability to install programs as non-administrator (either with a special group such as Power User, or by modifying all installers to be able to perform a per-user install instead).

I believe this would make sense for many programs (e.g. games for home-users), but as far as I understand this is not the way Vista is going.

2. The elevation prompt will inform you exactly what areas of file system, registry, etc will be open for writing, and/or you could manually select this.
[Or inform you specially if those parts already exists.]

If this would too much of a change in the operating system, you might develop a shim that first virtualizes the areas, runs the install, and then copies those parts when the operation is complete.

---
Obviously it is possible that I am missing some other solution to this problem.

/Hans
Anonymous
June 05, 2006
The comment has been removed
Anonymous
June 05, 2006
The comment has been removed
Anonymous
June 05, 2006
The comment has been removed
Anonymous
June 05, 2006
I have been preparing the MMORPG I am responsible for (www.prisonserver.com) to work correctly under LUA, and found a weird situation, that I already fixed in my installers and exes.

If an old fasioned win32 exe, in my case the game client, is started under LUA everything is OK, no popups, no elevations, all right.

If a Windows XP GUI based exe, in my case the game updater, is started under LUA, an elevations is requested, and sometimes when exiting the program the system complains that the program is not correctly installed.

The FIX in this weird case is to update the XP MANIFEST used to enable Windows XP looks for controls and windows, by adding an entry to the manifest requesting NO elevation whatsoever (you know, the requestedExecutionLevel level="asInvoker" stuff).

It seems that for LUA, a plain win32 exe is ok to run, but any exe with an XP manifest embedded is wrongfully considered as admin stuff, always requesting elevation.

It doesn't have much sense anyway :)

Best regards.
Anonymous
June 05, 2006
@Toni Pomar:

Toni, you should read an earlier post to this blog, especially item #1:
http://blogs.msdn.com/uac/archive/2006/01/13/512776.aspx

What's happening to your game updater is that Vista heuristically detects that it is an installer/updater, and thus requires elevation to launch it.

You're correct that manifesting your app with a requestedExecutionLevel is the right way to explicitly tell Vista whether elevation is required or not. If your app has a manifest that specifies a requestedExecutionLevel, it won't be subject to heuristic detection. You can read here for more details:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp

(Note: Whether an app is "old fashioned win32" or "GUI" should not have any effect on the heuristic detection.)

Now that you know /why/ you were getting the elevation prompt, I encourage you to be sure that "asInvoker" is really what you want for your game updater. If, indeed, your game and updater really are limited-user aware and can perform updates without writing to protected areas like %ProgramFiles% or HKLM, then kudos to you for a job well done. On the other hand, if your updater does write to those locations, then "RequireAdministrator" should be your choice.

Best of luck.
- Adam
Anonymous
June 05, 2006
@Adam Stritzel:

In fact the game does a local user install instead of a system wide install, precisely because of win 2000/XP non-admin. You know, having to add to "Power Users" group everyone that must be able to play (ergo able to autoupdate) the game is not a kind solution for the average home user.

About the heuristic detection, in fact the game client and the auto updater share all the network code (well, the game client is even more "ugly" in that than the updater), so seeing that the former has no problems with LUA and the other one has I did a simple test.

1.- Removing the XP manifest from the updater, no problem, no elevation request.

2.- Putting the XP manifest again, the elevation request is back (and so does the "shield" icon over the program icon).

3.- Adding the "asInvoker" token everything is ok again, just like without any manifest (case 1).

Did it with a couple of simple exes and the same happened.

From my point of view it seems like "asInvoker" is the default setting for plain win32 exes, but when a manifest is detected inside the exe for some reason "RequireAdministrator" seems to be the default setting unless specified, as I did when added the "asInvoker" stuff in my game executables.

Shouldn't be "asInvoker" the default for any kind of program, with or without manifest? Is the manifest parser doing a mess with default values?

This would remove tons of unneeded elevation requests.

In fact, even the installer for the game now has a suitable manifest so everything is smoothly installed for the local user with no elevation at all. Elevation when running the installer meant that "program files" and stuff was pointing by default to the global "all users" START menu, instead of the local user START menu. That meant that when trying to delete the game icons when uninstalling, that didn't provoke an elevation, the uninstaller ended up looking the wrong place (and having not enough privileges to delete the icons anyway).

Best regards.
Anonymous
June 05, 2006
@Adam Stritzel:

In fact the game does a local user install instead of a system wide install, precisely because of win 2000/XP non-admin. You know, having to add to "Power Users" group everyone that must be able to play (ergo able to autoupdate) the game is not a kind solution for the average home user.

About the heuristic detection, in fact the game client and the auto updater share all the network code (well, the game client is even more "ugly" in that than the updater), so seeing that the former has no problems with LUA and the other one has I did a simple test.

1.- Removing the XP manifest from the updater, no problem, no elevation request.

2.- Putting the XP manifest again, the elevation request is back (and so does the "shield" icon over the program icon).

3.- Adding the "asInvoker" token everything is ok again, just like without any manifest (case 1).

Did it with a couple of simple exes and the same happened.

From my point of view it seems like "asInvoker" is the default setting for plain win32 exes, but when a manifest is detected inside the exe for some reason "RequireAdministrator" seems to be the default setting unless specified, as I did when added the "asInvoker" stuff in my game executables.

Shouldn't be "asInvoker" the default for any kind of program, with or without manifest? Is the manifest parser doing a mess with default values?

This would remove tons of unneeded elevation requests.

In fact, even the installer for the game now has a suitable manifest so everything is smoothly installed for the local user with no elevation at all. Elevation when running the installer meant that "program files" and stuff was pointing by default to the global "all users" START menu, instead of the local user START menu. That meant that when trying to delete the game icons when uninstalling, that didn't provoke an elevation, the uninstaller ended up looking the wrong place (and having not enough privileges to delete the icons anyway).

Best regards.
Anonymous
June 06, 2006
The comment has been removed
Anonymous
June 06, 2006
I have been running with a pre-beta 2 build for sometime - and last night decided it was time to flatten...
Anonymous
June 07, 2006
I love Windows Vista.
One thing that opele complain about is the security prompts that come up when...
Anonymous
June 09, 2006
Interesting article Steve. Good to know you are working on making Vista a little less chatty!

Thanks for all your (and your team's) help recently with my uiAccess issue. Your diligent assistance was very much appreciated.

Marcus
Anonymous
June 09, 2006
PingBack from http://www.mjtnet.com/blog/2006/06/09/vista-too-chatty/
Anonymous
June 09, 2006
The first change is the Administrator/superuser account needs a password set during installation so superuser escalation will require a password to be typed in instead of simply clicking OK or Continue. Subsequently, the password must be typed in whenever this level of access is required. As it stands, Microsoft needs to revamp the rest of the model. I want a Control Panel applet that will let me choose the level of invasiveness. Here is my proposal:

1. Off - If I’m logged in as an Administrator, then it will work as current Windows machines.

2. Default - The current default settings as shipped in Vista Beta 2. The user would be hand held even while in his/her profile (aka home) directory. Deleting, editing and installing any files would all require the annoying pop-up dialog confirming action.

3. Limited Power User - Following the Linux model as shown in Red Hat of yesteryear, Ubuntu and others with a modification or two. All system files, installation of software available to the system, and any modification outside of the user’s profile directory would require superuser escalation. However, the user’s “%Profile%/Application Data” and “%Profile%/Local Settings/Application Data” directories would be protected. Any modification taking place would require escalation to superuser. In this scenario, I could attempt to wipe my profile, but things like my Outlook PST file and other settings would not be destroyed.

4. Power User - Same as Limited Power User, but the two Application Data directories would not be protected. In other words, I could wipe my user directory without ill effects on the rest of the system. I could create a new user and not experience any problems. This mode would also give me an option of maintaining superuser access for a set amount of time. When this is active, a tiny icon would show up in the systray with a user-configurable timeout to return back to “limited” access to the rest of the system files.

From a usability stand point, it would be nice to be able to elevate applications on the fly via another button on the top right of the window. It could also change colors based on the level of access the application has.
Anonymous
June 10, 2006
Basically - Reduce most of them, so that when you actually see an UAC prompt, you know that it is something to pay attention to.

Example: when accesing manage this computer, you get the UAC - Why? You havent dont anything at this stage. Nothing but viewing. No change has happened yet... There is so many, that i do not know where to start, and thus rather turn it around! Focus on the siutations where it is VITAL to have the UAC, and not the opposite!
Anonymous
June 11, 2006
Another point worth looking at is the ubiquitous "Add and remove programs" panel.

In windows 2000/XP a big opportunity was lost to really separate user accounts even from the applications installation poit of view. I mean, the limited accounts under 2000/XP, and now the UAC system under Vista, are the perfect environment for the concept of "local applications", thats applications installed only for one user. With a bit of care, it is perfectly possible for an application (like the online game I develop/maintain does) to install only for the current user, as the user has its own environment (local start menu, local desktop, local account folder, local documents folder, whatever), but one missing point in all this is the aging old "Add and remove programs" control panel, that inherits its global system-wide nature, instead of giving local installers a "local installed apps list" to be added to. whenever you want to supply a "local" installer to the unprivileged user you have to ignore completely that admin-only list and always supply a custom "uninstall" icon or option in the application.

Wouldn't it be the logical step to add this kind of "local add/remove programs list" to every user? This way no admin rights are needed to access such a list, giving the local apps the "neat" and "compliant" way to be managed and uninstalled by the unprivileged user.

Best regards
Anonymous
June 11, 2006
Whatever you do DO NOT "shim" too much! The GOAL is to get Programmers to write code correctly - NOT make room for poor programming!

Try offering a lot shims to the home versions (Basic + Premium) and less to the business version(Bus., Ent., Ult.).

Again, DON'T SHIM TOO MUCH; BE RESPONSIBLE!
Anonymous
June 11, 2006
I agree with Sobakus that it would be nice if "Add/remove program" also used e.g. HKCUMicrosoftWindowsCurrentVersionUninstall (and some default install-directory for local installs since "Program files" is only for system-wide programs).

[Obviously so that it can be restricted with group-policies.]

That would reduce the number of elevation prompts in the simplest way: by removing the need for elevated privileges.

However, as far as I understand this is not the way Vista is going.

Best regards,
Hans
Anonymous
June 11, 2006
The comment has been removed
Anonymous
June 12, 2006
The comment has been removed
Anonymous
June 12, 2006
The comment has been removed
Anonymous
June 12, 2006
The comment has been removed
Anonymous
June 13, 2006
The comment has been removed
Anonymous
June 13, 2006
The comment has been removed
Anonymous
June 13, 2006
Some complaints:
1. It's resource hog
2. Boot and install takes forever (hopefully better for final version)
3. The New Explorer is a mess to navigate in
4. Release DX10 for XP and skip Vista.
Anonymous
June 13, 2006
Can you shim visual pinball + pinmame
Anonymous
June 13, 2006
The comment has been removed
Anonymous
June 13, 2006
Windows Vista でアプリケーションが動作しないときは
Anonymous
June 13, 2006
The comment has been removed
Anonymous
June 14, 2006
Very Informative
Anonymous
June 14, 2006
The comment has been removed
Anonymous
June 15, 2006
The comment has been removed
Anonymous
June 15, 2006
The comment has been removed
Anonymous
June 15, 2006
L'UAC (User Account Control) est l'une des nouvelles fonctionnalités de Windows Vista les plus controversées...
Anonymous
June 20, 2006
In my earlier post, when I said MAPI, I meant Microsoft SAPI - Microsoft Windows Speech API
Anonymous
June 20, 2006
I promised Arthur that I would tell people about the Microsoft Unified Communications and RTC user group,...
Anonymous
June 20, 2006
The comment has been removed
Anonymous
June 21, 2006
The comment has been removed
Anonymous
June 28, 2006
The client for Hamachi VPN (http://www.hamachi.cc) requires elevation on every login as it needs the ability to configure its own network interface.
Anonymous
July 03, 2006
Keyboard key presses and mouse click events. Surely you can tell if a user has doubled clicked or pressed a key at the device level locally within an application? I am really suprised that with the level of access, i.e. Kernel source that you can not do this? What is the real issue. You must know if an application is inserting data into a queue instead of a real device?
Anonymous
July 04, 2006
To make a long discussion short: It is a basic principle that security will only work if it is reasonably easy to use. Otherwise, users will simply turn it off or work around it or get used to "always click yes".

This said, as an ISV I find it extremely hard to have our apps not require special privileges, mainly because .NET, VB or other external resouces like CAPICOM require it. Yes, it is a good idea to change all that but this will take some time. It will not happen until Vista ships.

Bottomline for us is: yes, warn the user if there is an app that wants privileges, yes warn the user if it is from an unidentified publisher. BUT: Find a way no matter how to identify the binary fingerprint of that app, and once an admin approved this app, let it run.

Anything beyond that may be theoretically more secure but will be much less secure in the real world because it renders the whole UAC unusable.
Anonymous
July 05, 2006
Tobias: You said, "as an ISV I find it extremely hard to have our apps not require special privileges, mainly because .NET, VB or other external resouces like CAPICOM require it." I don't understand that statement at all - on its face it just sounds completely wrong. Can you please elaborate? Thanks.
Anonymous
July 11, 2006
After fixing some elevation request problems I had by embedding the correct manifests in the executable files (thanks to Adam Stritzel for a very clear explanation about the manifest problems I had) I just came up with a very annoying problem with those manifests.

I just ported my projects to Visual 2005 from Visual 2003 and the first thing I tested is the "manifest tool" included in the IDE. It is a very convenient and easy tool for manifest embedding BUT I can't use it at all.

I seems that when the manifest is embedded with that tool AND the manifest includes a <security> section (required to specify requested privileges under Windows Vista and avoid annoying elevation prompts) the manifest is formated in such a way that the resulting EXE crashes (in fact completely reboots) Windows XP after running the exe a couple of times.

It looks like some kind of overflow bug in the manifest parser in XP.

The solution is to actually disable the manifest tool in vc 2005 and instead embed the manifest by hand editing the .rc file of the project.

The only difference I've seen in both cases is that the manifest tool adds some padding text after the manifest (something like "PADDINGX" repeated a lot of times) and by embedding it by hand throug the .rc file there is a simmilar padding but full of zeroes instead of ASCII text.

I hope this helps someone with weird crashes and reboots under XP. I had a couple of them before thinking about something weird happening with my exe and found this link
http://codecomments.com/Visual_Studio/message980461.html.

Best regards
Anonymous
July 24, 2006
Thousands of people from around the world have been hard at work to ensure that Windows Vista is the...
Anonymous
July 24, 2006
my app uses globally named objects for multiple instances synchronization and communication. this was an MS recommended way in the past, but with the forthcoming Vista it seems to be deprecated:

CreateMutex() and CreateFileMapping() worked with globally named objects on 2000XP (even with restricted accounts) and Vista Feb CTP release.

with Vista build 5384, an UAC elevation is requested as admin rights are needed.

now what is the future of this?

there is an unanswered thread at MSDN forums: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=327551&SiteID=1
Anonymous
July 26, 2006
I've been somewhat lax in my postings on least privilege of late, in part because I've been pretty pleased...
Anonymous
August 14, 2006
I use eTrust EZ antivirus, it places part of the program in the systemtray, so every time i login i get these elevation prombts. The same thing happens with ATI Traytool, it loads with windows and gives....an elevation prombt. that makes 3 everytime i login.
The app. "Newsleecher" only runs well with admin privelages, so well everytime an EP.
Anonymous
August 22, 2006
Like many older apps (Quicken, Sidekick98 etc), our apps install the data/config files in the same folder as the executable in the c:program files<appname> folder. If I install one of the apps in Vista Beta 2 with UAC ON, the empty data/config files are installed in the program files (PF) folder and in the user's virtual PF folder. All works ok and I enter data in the app.

Sometime later, I switch UAC OFF to avoid the prompts and run the app again. The data is no longer there because the app in now reading the data files in the app's PF folder not the apps virtual PF folder. I switch UAC ON again and the data miraculously re-appears!

Since we cannot prevent users re-installing their older apps in their new Vista PCs or changing the UAC setting, this feature will undoubtedly lead to significant customer angst and significant customer support workload for us. We are talking about pilot flight data here so this is not an insignificant problem.
Anonymous
September 01, 2006
What is wrong with a simpel return ERR for the api functions? If the program lacks the permissions it simply should be told so.
Anonymous
September 05, 2006
We’d like to thank all of the Windows Vista beta testers for using and giving us feedback on User Account...
Anonymous
September 07, 2006
We’d like to thank all of the Windows Vista beta testers for using and giving us feedback on User Account...
Anonymous
September 07, 2006
renaming a hd (set label) acts different than renaming a network connection.

on hd:
1) "attention you must be admin"
2) "click yes if you can read"
on network connetcion:
1) "click yes if you can read"

Steffen
Anonymous
September 08, 2006
PingBack from http://vista.pcplace.biz/2006/09/09/rc1-user-account-controls-blog-talk-about-uac-improvements/
Anonymous
September 21, 2006
Adding a new folder to the c:inetpubwwwroot folder (or any other folder where users do not have write permission) can be a bit of a trial.

1) Right click on empty space, select New>Folder. Vista replies "You need to confirm this operation".
2) Click Continue - Vista goes to the secure desktop and asks "Windows needs your permission to continue".
3) Click Continue - the New Folder appears, with the text selected ready for the new name. Type in the new name and press return.
4) Vista replies "You'll need to provide administrator permission to rename this folder".
5) Click Continue - Vista goes to the secure desktop and asks "Windows needs your permission to continue".
6) Click Continue - Finally the new folder is in place.

You have to respond to four dialogs to perform one operation!

Charles
Anonymous
September 22, 2006
The comment has been removed
Anonymous
September 26, 2006
ok I fixed it,
to regain access to the file :
turn ON UAC,
then access to change owner is available...
otherwise it's not available
which is strange?
Anonymous
October 02, 2006
PingBack from http://www.shahine.com/omar/FlickeringAndDimmingInVista.aspx
Anonymous
October 03, 2006
I just had a similar problem like jul (read above): With UAC turned off you don't have permission to change security of files and folders in some cases (e.g. after denying access for all users). I don't know if this is maybe a bug, because I can't see the intension behind it...

Partager via

Reducing Elevation Prompts in RC1

Comments

Ressources supplémentaires