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 2 and 8 and type the answer here:
  • Post
  • Thank you very much. This is awesome!

  • Thanks for this, Steven and Jon. I took the liberty of blockquoting you guys directly.

  • Thank you. This is a _great_ example of listening to customers, reacting to their concerns and finally providing what they need. In fact, this is just par for the course for what the Windows team is delivering with Windows 7: A sophisticated general purpose OS that suits the needs of a great many people and one that has been designed, from the very beginning, with their feedback front and center. Outstanding work, Windows team! Thank you.


    Channel 9

  • Sounds good.

    You definitely need to work on your communication about these though.  The exploits relied on the UAC page not being elevated - the critical part was the SendKeys, not the lack of UAC mesage; clear communication about the bug rather than long explanations about "this is by design" would've done a lot to defuse this situation.

    I would also suggest that a change of mindset in terms of the idea that "once an app gets code running on the machine, it's game over".  People shouldn't have to give an installer full access to their system just to try out a new browser, media player, or photography app.  Yes, if its an app running with the user's permissions, it'll be able to destroy the user's data; but it shouldn't be able to render the machine unusable or access other people's files on the machine.  

    The concept of "partially trusted" code is hardly a new one.  Will there be vulnerability that permit unprivileged processes to elevate?  Of course.  Those are bugs, and should be fixed like any other security issue.

    Google Chrome is an excellent of example of an app installation which doesn't require full admin permissions.  I would suggest you should be encouraging these scenarios and figuring out how to make them more secure.  It would be awesome if an app could be installed without being granted full control to a system (as per Google Chrome/ClickOnce) *and* have its binaries be secure against tampering by other non-elevated apps (as Program Files-installed apps are).

    Thanks for listening...

  • Thank you not only for listening but also for the awesome communication.  

  • John and Steven,

    I think nobody here expects that you make design decisions in realtime based on feedback in this blog. In fact it even makes me feel a little uneasy.

    This sounds paradoxical but especially with security you want somebody on the other side, who knows, what she is doing and does not give in to user demand too easily.

    Also if people knew about the sendkey fix in the making, the discussion here would probably have been far more relaxed.

    What I would like to here now is a clear technical statement what kind of security I get from the UAC as it is in vista versus using a standard user account versus using the windows 7 default UAC settings.

    Are you planning to protect other dialogs in windows 7 from simulated user input?

    Regarding telemetry to measure system security: The point here is to realize that malware to exploit the new UAC settings has to be written first and this is likely to happen only, when windows 7 becomes mainstream.

  • I am blown away (pleasantly surprised) that you're making this change.

    I feel that this topic would really benefit from an in-depth interview on Channel9.  Ideally you'd have someone like Mark Russinovich playing devil's advocate and asking you tough questions. There are 2 issues that I would ideally like to see discussed:

    1. I thought the whole point of UAC is to limit the damage that malware can do if it somehow gets to run.  So it seems besides the point to argue that malware can't really get into the computer without the user's consent.  If you are so sure that malware cannot possibly get into a Windows7 machine, then why bother having UAC at all ?

    2. Before this latest change in UAC behavior, the following scenario was thought to be possible:

    * user has configured UAC to "Notify only when..."

    * malware somehow gets to run

    * malware can use some kind of trick to change UAC settings without the user finding out

    * malware can do whatever it wants

    Was that scenario possible ? And if so, did that render the "Notify only when..." setting useless ?  If not, why not ?

    Thanks !

  • wow jon and steve, i'm blown away by how gracious you have been in the discussion!

    Also thank you for changing UAC settings to now require elevation. that was all i was after (and i bet many others) However regarding your quote; "That was already in the works before this discussion", its a pity this wasn't communicated earlier

  • Hello Steven and Jon!

    First of all I would just like to add that this blog has been fantastic so far and it feels as if Microsoft is opening up in a way never "felt" before. Now don't get me wrong, I know Microsoft has always been listening, the problem before has been that it hasn't really been visible to the general customer that you are actually listening. Everyone part of any program (be it connect, OEM or other channels) know this, because they get responses to their questions. Here, for the first time, you can combat the blogosphere and give your view before it is too late. And I think you do a really good job (and many others at Microsoft strengthen this view of openness, like Mark Russinovich, Larry Osterman, Scott Guthrie, Tim Sneath etc etc).

    I expect you to make mistakes, what counts is how you recover from them, that is how we all learn, if you are not failing you are not trying hard enough.

    I would say that one big strengths in being a good communicator is when you set aside prestige, see the facts, and handle a heated conversation the way you just did.

    Secondly I wouldn't mind the possibility of tagging certain system changes as "always prompt no matter what the current elevation is", and UAC level be one of those. I do understand that UAC prompt isn't the first line of defense. Part from being all what it is , to me it is also a glorified notifier that can make me aware of what programs are trying to do. Because even if I trust a program source, even from notable large companies such as Sun and Adobe, they sometimes tend to change things in their installers that I don't particularly agree with. To be able to be notified of such changes even when the setup program is elevated would make me feel more in control and less reliant on monitoring tools.

    I can't resist to mention this as well. For setups it would also be very handy with a complete diff log on the system, all changes made by a setup process to the system. Sysinternals tools give you this, but inbox tools that always captures would be very nice. It would also help the community give feedback to program developers to start placing their files in a xcopy manner.

    Keep up the great work and make Windows 7 all that it can be!



  • @ncgloy:

    That's a great idea! :)


  • UAC should be set to Always Notify. Protect us from System Changes. I was thrilled in a bad way to find Windows 7 left by default that option to a lower level...

    That's the purpose of UAC.

    I don't see anyone complaining on Other OS about Credential Mechanism.

    Do you really want to please Whinning XP users at all ? I bet not !

    Keep Up the excellent Work there !

  • Absolutely delighted!  Thank you for listening, and I genuinely do believe that the changes you've outlined are the right way forward.  Furthermore, you've been more than gracious in all this.

    Technical and security aspects aside, you've just done one hell of a good thing for Microsoft's PR.

    And don't worry, I don't think any of your audience are about to get complacent about security as a result of this change to UAC prompting.

    Finally, I just want to say that W7 is shaping up to be one hell of a good product.  Congratulations are due to all you guys 'n' gals.

  • I just wanted to discuss this quotation a little further:

    "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."

    Isn't it slightly naive to say "nothing after that is material"?  There's an implied assumption that ALL you need to worry about is that first step.

    But wouldn't it be fair to say that, even with your very best efforts, one day some malware might come along that DOES overcome that first step.  In that case you want it to face another barrier, and another.

    So I think it's kinda risky to dismiss those scenarios which begin "first get code running on the machine".  They are not silly scenarios, or contrived.  They are simply saying "If the first barrier has fallen, how well do the remaining barriers work?".

    And I think it is legitimate to explore those scenarios, even though they OUGHT not to arise, and you've designed against them.

    Just my thoughts!  :-)

  • Hi Jon and Steven,

    I'm pleased to see that the changes you describe are being made.

    While I appreciate that UAC is not a security boundary, it is still (IMHO) too easy to elevate an arbitrary binary in Windows 7 with the default UAC settings.  Consider the following example:

    1) A user is a member of an administrator's group and is using Windows 7 with the default UAC settings.

    2) Click Start. In the search box enter "taskmgr" to open Task Manager using a standard user token (i.e. without administrative rights).

    3. Click the Processes tab.

    4. Click "Show processes from all users". Task Manager will elevate without triggering a

    UAC prompt.

    5. Click the File Menu and Select "New Task (Run...)"

    6. Place a tick in "Create this task with administrative privileges". Enter the name of an arbitrary executable (trusted or untrusted) to be executed on the system with full administrative rights.

    7. The binary will be launched with full administrative rights. No UAC prompts will be


    I would like to see a UAC prompt added at some point in the above chain to prevent this scenario.  Just because UAC is not a security boundary does not necessarily mean that the trivial cases such as this (and the UAC "SendKeys" case that has recently been fixed) should be overlooked.



  • @ncgloy: The real way scenario is:

    * user has configured UAC to "Notify only when..."

    * malware somehow gets to run and malware can do whatever it wants

    However, in reality, malware often does install new malware based on commands as part of a botnet, and these new items could have been silently installed later with the way Win7 beta is now. The change noted in this blog will help prevent that. But only for certain scenarios. But I'm all for roadblocks, even those that are not completely effective.

    Anyhow, until all software is managed code and the UAC knows and Windows can enforce sandbox parameters for an app install, we have to deal with these ways to manage black box software.

    Kudus on handling a big business item, and a minor technical one. Nothing worse than someone with a little bit of knowledge making prognostications, than one with a bullhorn and a mob at his feet.

Page 1 of 14 (198 items) 12345»