Reducing Elevation Prompts in RC1
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.
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.
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.
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