Engineering Windows 7

Welcome to our blog dedicated to the engineering of Microsoft Windows 7

UAC Feedback and Follow-Up

UAC Feedback and Follow-Up

When we started the “E7” blog we were both excited and also a bit uneasy. The excitement is obvious. The unease is because at some point we knew we would mess up. We weren’t sure if we would mess up because we were blogging about a poorly designed feature or mess up because we were blogging poorly about a well-designed feature. To some it appears as though with the topic of UAC we’ve managed to do both. Our dialog is at that point where many do not feel listened to and also many feel various viewpoints are not well-informed. That’s not the dialog we set out to have and we’re going to do our best to improve.

This post is an attempt to get both the blog right and the feature right. We don’t like where we are in terms of how folks are feeling and we don’t feel good – Windows 7 is too much fun and folks are having too much fun for us to be having the dialog we’re having. We hope this post allows us to get back to having fun!

To start we’ll just show representative comments from the spectrum of feedback. We’ll then talk about the changes we’re making and also make sure we’re all on the same page regarding how we move forward. In terms of comments we’ve heard the following:

@sroussey says:

You have 95% of the people out there think you got it wrong, even if they are the ones that got it wrong. The problem is that they are the one's that buy and recommend your product. So do you give them a false sense of increased security by implementing the change (not unlike security by obscurity) and making them happy, or do you just fortify the real security boundaries?

And @Thack says:


Thanks for sharing your thoughts.  I understand your points.

Now, I want add my voice to the call for one very simple change:

Treat the UAC prompting level as a special case, such that ANY change to it, whether from the user or a program, generates a UAC prompt, regardless of the type of account the user has, and regardless of the current prompting level.

That is all we are asking.  No other changes.  Leave the default level as it is, and keep UAC as it is.  We're just talking about the very specific case of CHANGES to the UAC prompting level.

It will NOT be a big nuisance - most people only ever change the UAC level once (if at all).

Despite your assurances, I REALLY WANT TO KNOW if anything tries to alter the UAC prompting level. 

The fact that nobody has yet demonstrated how the putative malware can get into your machine is NO argument.  Somebody WILL get past those other boundaries eventually.

Even if you aren't convinced by my argument, then the PR argument must be a no-brainer for Microsoft.

PLEASE, Jon, it's just a small change that will gain a LOT of user confidence and a LOT of good PR.


With this feedback and a lot more we are going to deliver two changes to the Release Candidate that we’ll all see. First, the UAC control panel will run in a high integrity process, which requires elevation. That was already in the works before this discussion and doing this prevents all the mechanics around SendKeys and the like from working. Second, changing the level of the UAC will also prompt for confirmation.

@mdaria510 says:

Sometimes, inconsistency with your own ideals is a good thing. Make an exception, if only to put people's fears to rest.

That sums up where we are heading. The first change was a bug fix and we actually have a couple of others similar to that—this is a beta still, even if many of us are running it full time. The second change is due directly to the feedback we’re seeing. This “inconsistency” in the model is exactly the path we’re taking. The way we‘re going to think about this that the UAC setting is something like a password, and to change your password you need to enter your old password.

The feedback is that UAC is special, because it can be used to disable silently future warnings if that change is not elevated and so to change the UAC setting an elevation will be required.  To the points in the comments, we also don’t want to create a sense or expectation of security that is not there—you should still not download code and run it unless you trust the source. HTML, EXE, VBS, BAT, CMD and more are all code and all have the potential to alter the environment (user settings, user files) running as a standard user or an administrator. We’re focused on helping people make sure that code doesn’t get on the machine without consent and many third party tools can help more as well. We want people to be comfortable with the new UAC control and the new default setting, so we’ll make the changes outlined above as the feedback has been clear.

While we’re discussing this we want to make sure we’re all on the same page going forward in terms of how we will evaluate the security of Windows 7. Aside from the UAC setting, the discussion of the vulnerability aspects of the Windows 7 Beta  have each started with getting code on the machine, which the mechanisms of Windows have prevented in the cases shown. We have also heard of security concerns that involve multiple steps to demonstrate a potential exploit. It is important to look at the first step—if the first step is “first get code running on the machine” then nothing after that is material, whether it is changing settings or anything else.  We will treat very seriously the ability to get code on a machine and run without consent. As Jon’s post highlighted briefly, the work in Windows 7 is about the increased protections in place to secure your PC from acquiring and running code without your consent, and of course we continue to make sure Windows code is secure from both tampering or circumventing the protections in the system.

We want to reiterate the security of the system overall. Windows 7 is SD3+C and is designed to be more secure that Vista—that’s our priority. None of us want to have Windows 7 be perceived as being less secure than Vista in any way, because our design point is to make sure it is more secure that Windows Vista, by default.

We said we thought we were bound to make a mistake in the process of designing and blogging about Windows 7. We want to continue the dialog and hopefully everyone recognizes that engineering, perhaps especially engineering Windows 7, is sometimes going to be a lively discussion with a broad spectrum of viewpoints expressed. We don’t want the discussion to stop being so lively or the viewpoints to stop being expressed, but we do want the chance to learn and to be honest about what we learned and hope for the same in return. This blog has almost been like building an extra product for us, and we’re having a fantastic experience. Let’s all get back to work and to the dialog about Engineering Windows 7. And of course most importantly, we will continue to hear all points of view and share our point of view and work together to deliver a Windows 7 product that we can all feel good about.

--Jon and Steven

Leave a Comment
  • Please add 3 and 1 and type the answer here:
  • Post
  • The fix of running on higher integrity level for the UAC applet should be extended to all other processes that are part of the whitelist and as such don't require elevation.

    In this way it wouldn't be possible to replicate a similar attack through TaskManager, MMC.exe, etc.

  • @p_rynhart

    What scenario would they be preventing? Allowing an elevated program to do things that elevated programs are allowed to do?

  • @a688

    If a third party installer is downloaded to the desktop and launched then UAC will kick in and prompt for elevation on the secure desktop.  Yet, this can all be circumvented within 30 seconds by starting up Task Manager.

    This doesn't seem right to me (particularly when UAC is set to require a password along with "Notify me when programs try to make changes to my computer").



  • On my W7 beta 1 machine I have no option in the task manager create new task window to elevate its rights.

    But I agree if there's a series of steps which a program running with UAC on could elevate to admin rights without prompting from UAC, it needs to be eliminated.

  • Could someone please explain to me why regedit.exe requires elevation under the default UAC settings whereas taskmgr.exe does not ?

    It seems to me that neither are directly related to "Windows Settings" (which is the text associated with the UAC slider).

    taskmgr.exe concerns terminating processes, starting/stopping services, etc.  "Windows Settings" (in my view) concerns changes to font dpi, adding/removing programs etc.

    In my opinion, taskmgr.exe should require elevation the moment that a shield icon is pressed in this application (with the default UAC settings).

    On the contrary, why does UAC force me to use a full administrative token to invoke regedit ?  What if I only wanted to make changes to HKCU ?  I should be able to open this application using my "standard user" token.

    Things seem very inconsistent.



  • Oh, finnally we were starting to worry that you wern't listning.

    My thoughts exactly expressed here

  • p_rynhart:

    If a third party installer is downloaded to the desktop and launched then UAC will kick in and prompt for elevation on the secure desktop.  Yet, this can all be circumvented within 30 seconds by starting up Task Manager.


    Care to elaborate further what you mean. I don't see how it can be circumvented by starting the task manager. One way or the other you need to be elevated. If the taskmanager is elevated it cannot be touched by the non elevated installer (which it will be, but without a prompt).

    Try this and you will see that your non elevated app cannot touch it anylonger

    Set WshShell = WScript.CreateObject("WScript.Shell")












  • p_rynhart:

    On the contrary, why does UAC force me to use a full administrative token to invoke regedit ?  What if I only wanted to make changes to HKCU ?  I should be able to open this application using my "standard user" token.


    User reg, powershell or any other command line tool.

    But I agree that it would be nice if they rewrote regedit to be aware of different ACLs. Then again it is alot of work for no real day to day benefit. I would rather have them work on other more userful features. Especially since there are other ways.

    All in all, I wish they would instead remove the entire registry and push every app to a xcopy solution.

  • Steven and Jon,

    THANK YOU! I'm glad you guys are listening. You just insured that I will be purchasing at least two copies of Windows 7 Professional with an Ultimate upgrade.

    Thanks for listening to the bloggers, testers, and concerned users. This is why I'm a Windows user. You'd never get this kind of open and honest discourse from Apple. Thanks guys.

  • Thank you very much for making those changes based on user input, even though you disagree with them.  That is almost worth more than the value of the change, IMO.

    I would like to point out, that with full UAC enabled, Windows Explorer still likes to prompt twice before changes to protected files or folders are made.  This double prompt also sometimes changes security settings when accessing someone else's files.  I would like some way of running an explorer process with admin permissions (right now it seems to lower its privileges when you run it as administrator).  I also would not mind if you made a distinction in the title of an elevated explorer window so it is easier to remember to close it.

    Since Taskmgr.exe was brought up, it would be nice if this was also a high integrity process.  It would also be nice if it could be marked as page-last process.



  • @niclas.lindgren and Charles

    Niclas is correct.  After taskmgr.exe is relaunched with a full administrative token it becomes a high integrity process.  Thank you for your script Niclas.

    However, it still seems inconsistent to me that regedit.exe should involve a UAC dialog whereas taskmgr.exe (when using an administrative token) should not.



  • My main issue with UAC is not the prompts (though they can be annoying) it's the behavior changes that occur without any prompts to elevate. i.e. some (possibly) bad stuff I'm asked to confirm first, other (possibly) bad stuff is just forbidden.

  • p_rynhart - I use taskmgr daily whereas I might need to use regedit once a month. I don't have much issue with needing to a UAC prompt to run that program.

    Plus, regedit.exe can execute a dangerous .reg file via a parameter where taskmgr takes no parameters (that I'm aware)

  • @ababiec

    Surely frequency of use shouldn't be the sole determiner as to whether an application should trigger a UAC prompt.



  • Google Reader doesn't show this post. Your RSS feeds must not be being updated properly.

Page 2 of 14 (198 items) 12345»