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 1 and 7 and type the answer here:
  • Post
  • There is a reason why every other operating system uses a UNIX permission structure - it's because UNIX is truly secure by design.

    Perhaps Microsoft should think about that as they redesign the security wheel for the millionth time.

    Microsoft, do what you do best for once; copy someone else's design.

    Your users' won't even notice the difference:,139023769,339294810,00.htm

  • Second post ever: if it's important enough to post about, it's important enough to say thank you!

    Some will point to this as an example of how you guys are finally listening.  In fact, this is an example of how you all have been listening for years and we appreciate it and it shows.

    It is also an example of you talking, though.  Without that, we would not know that you were listening.  You always said you were and of course you were but no one can see it unless you show it.  For that I also thank you.

    I am running the Beta but I can't wait for RTM so the rest of my family can enjoy the benefits as well.

  • >>

    Microsoft, do what you do best for once; copy someone else's design.


    We shouldn't think the folks at Microsoft are fools, or talk to them like they are.

    When Microsoft realised they had to seriously revamp Windows to make it secure, they looked at a vast range of options, including making it work much like Unix.  

    However, they were SEVERELY constrained by the need to maintain backward compatibility.  No other OS in history has such an enormous ecosystem of assorted software (and hardware) to support.

    The NT security model, which was pretty good and was designed in from the beginning by Dave Cutler, had never properly been enforced by Microsoft.  Thus there was a truly vast amount of software out there which completely ignored the security guidelines.

    Obviously Microsoft could (and probably would have preferred) to redo Windows security from the ground up, possibly like the Unix model.  But to do so would nobble vast swathes of software out in the field, and piss off tens of millions of users.

    So they've had to engineer a somewhat more complicated solution, which may not be as simple and elegant as Unix security, but which has demonstrably worked well.  And it continues to be improved.

    All the while, the impact on old, non-compliant software has been remarkably limited and manageable.

    Although I fully agree that Microsoft painted themselves into this corner, I think they've done a pretty impressive job of sorting it out.

    Let's give the guys a break.

  • David Of Michelangelo

    It is said that when the work was nearly completed, the gonfalonier Piero della Repubblica Fiorentina Soderini went from Michelangelo to admire the statue. After long observed with interest, he turned to the teacher saying that in his opinion, the nose of David was too big. Michelangelo then seized a handful of powdered marble and a chisel with which to pretend to correct the alleged error. slow slow 'at a time he dropped the powder from the hand, then asking the opinion of gonfalonier, who met, finally declared the perfection

  • that's my question about programmatically changing UAC and protecting the UAC setting answered perfectly ;-) It *is* inconsistent and having UAC changes always require elevation may not in truth offer any more protection, but I think you're right to see it as a change worth making. Having the UAC control panel as a high integrity process makes a lot of sense; perhaps you could share your thinking around which (if any) other elements are in high integrity processes, to help people understand what's security boundary and what's making the user aware?

    @Patrick It would be bad practice for Microsoft to change the resources given to a program on request; giving a standard token when an admin token was requested would lead to a lot of unexpected behaviour. how would you troubleshoot that? would you believe that the program was at fault or that Windows was? Would the user remember a week later that they had told Windows to deny the admin token (if you could phrase it in a way that would be intelligible to every user)? UAC has pushed software developers to running with standard accounts and tokens because users have complained about elevation. I run with UAC set to warn and I see far fewer elevations - not because of changes in Windows but because of changes in software.

    @wtroost It's my understanding that a high proportion of UAC prompts are from IE addons - because that's where a lot of malware attacks.

  • @Thack

    Microsoft's software for better or worse (mostly worse) runs on 85% of consumer and business computers. There is no room for the half-ass security techniques they have used over the years. The numerous breaches resulting in the compromise of consumer private data should be all the motivation Microsoft needs to make the hard choices and do a redesign. Microsoft constantly uses their monopoly (remember convicted monopolists) to maintain their dominance on the desktop. They can just as easily use it to force software developers to redesign their applications to continue to run on the Microsoft platform. If software companies continue to want their software to run on 85% of the computers out there, they will do the required work. Such a change would result in much needed economic stimulus as well from all the programmers required to make the changes and all the new consultants needed to help technology customers with the change. It's not as big of a deal as you make it out to be. Apple was able to make the change twice with little to no recourse. The same would be true for Microsoft. And Microsoft now has the advantage of virtualization technology almost being ubiquitous. Apple had to do it without this technology. No more excuses for Microsoft are allowed; not in this day and age of technology.

  • Great news.  It is unfortunate they didn't reveal the plan earlier (if indeed it's been in the works for a while) since it would have avoided some of this.  I think the blog posts could be a bit more up-front and use a few less buzzwords, delivering answers to important questions instead of sounding like a lecture.  However great blog overall :D

    @ PedroAsani

    For the same reason chip-makers underclock and core-cripple chips to sell "lower end" products (even though manufacture cost is the same).  If Microsoft had only one OS product, selling it for the price of a Home edition, they miss out on the extra dollars of those willing to pay more.  That said, a simpler structure would be far better, particularly the starter/basic versions should be axed.  If Professional is truly a superset of Home, then Pro and Ultimate could also be combined.  In short, I agree with you in principle, but eliminating all but one sku would be a bad business decision.

  • I just had a thought, instead of just requiring the user to click "Continue", why not force them to enter their password.  I know I've been victim to just clicking "Continue" because I wasn't paying attention.  Requiring a user to enter their password really makes them think before they do something.  What I find is also weird, if you have UAC set above default, buttons that would normally require a consent, still have the shield on them even though they don't produce a prompt.

  • I'm glad to hear you've decided to change your mind on this issue.

    Let's about some new features (some we haven't heard from for months like WARP) now :) !

  • @marypcb

    > It would be bad practice for Microsoft to change

    > the resources given to a program on request;

    > giving a standard token when an admin token was

    > requested would lead to a lot of unexpected

    > behaviour.

    I was not referring to applications/installers specificially marked with "requireAdministrator" in their manifest - but to setup progams (e.g.) that Windows 7/Vista assumes require full administrative privileges.

    Surely some mechanism should be available for a user-based install ?  I don't see this as being any different to the "Protect my Computer and data from unauthorsied program activity" option which is available in the Windows XP runas dialog.  Note that in the case of XP, the trust level is even lower (i.e. a constrained token as opposed to a Standard User token).



  • @What I find is also weird, if you have UAC set above default, buttons that would normally require a consent, still have the shield on them even though they don't produce a prompt.

    That's because the button is telling you that what you do will cause the dialog to elevate when you select it, even though you have chosen to hide the elevation process.

  • This change, while an improvement, is still not enough.  NOTHING should be able to silently elevate EVER.  Because you have NO reliable way of knowing it is originating from the user!

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

    Here's an EASY way to get code running on the machine which Win7's defenses will have no control over: Say you install a third party product such as a browser which runs at medium IL.  Then, some remote code execution vulnerability is found in the browser.  You go to a site that takes advantage of this exploit to run arbitrary code.  This arbitrary code does all the SendKeys/etc that it wants and elevate all over the place.

    You even allude to this by having the UAC setting say that it should be used by people who only visit familiar websites.  

    You'll NEVER find all the "safe" vs "unsafe" apps which should allow elevation, because the app itself isn't what has power to do danger, it's the user's *administrative token*.

    Windows 7 is NOT secure out of the box if it ships with the setting at anything LESS than Always Notify.  The fact that the first account is always an administrator is even more troubling, especially since your own telemetry shows that most machines only have one account.

    I'm as big a Microsoft fan as they come, but this is a HUGE mistake.  I cannot believe that all the smart security minds at Microsoft (Crispin Cowan, Adam Shostack, Michael Howard) would give their okay on this.

  • @PatriotB

    Exactly. You are only listening to the feedback, you want do hear, Microsoft.

    Btw., do the contributers to this blog get their free copy of windows 7 for help designing your product? :-)

  • What you really should have done is leave the basics concept of UAC as it is and tweak the details of UAC to avoid double prompts, avoid prompts for uncritical changes like changing DIP and avoid prompts, before an actual change is made.

  • well, I'm looking into all opinions and have few comments:

    Windows 7 developers have to make some compromises. But the truth is, that UAC will do only, that normal non technical users will understand less, what is going on. I will repeat some other words about build 7000:

    1. no easy info for user, that something is working with admin privileges (no different window color or title with "(admin account)" or something like that)

    2. Task Manager should display info about all processes by default (when run without admin privileges, it will naturally not display everything about some of them - like currently Process Explorer from SysInternals)

    3. default tools should work with non admin privileges - like chkdsk, which in such situation should be able at least to show some info about partition

    Currently Microsoft will be maybe less interested in making more deep changes, but imagine such situation:

    1. startup files, kernel, some drivers, etc. are working in admin ring.

    2. whatever you try to run installer for some runtimes (like .Net) or antivirus, it must be signed and user is always asked by something like UAC to run it.

    3. when you run application (installer or executable), it runs in own sandbox (with some virtual system directories in real subdirectory of Program Files containing files and libraries). it doesn't have access to system directory or other apps, it can share only some Registry keys with other (for example responsible for registering some extensions). When application try to add driver to driver database, user is always asked by something like UAC.

    4. when you want to increase priviligies of application, you are always asked by something like UAC to run it.

    5. when you do some actions (changing time), you are always asked to do it.

    6. admins are allowed to block these few actions (adding new drivers to driver codebase, setting time, etc.). additionally it will be possible to allow/block users run non installed software (not run from virtual sandboxes)

    When are profits ?

    you will be able to install for example many different versions of IE, applications can be easy uninstalled, there will be less questions from various antiviruses (for example: do you want application X to read Y key ?), no need of using WinSxS, etc.

    Additionally user should have ability of setting some network access to concrete processes and should have clear info, what servers can his system connect to (when is making updates for example)

    Current solution is going to nowhere and that's why can't give any real additional security than Windows XP. Non technical users will have problems with understanding it, technical users can configure old system, that it will have (almost) the same functionality + security for daily usage.

    Compatibility is very important, but making prosthesis will make only, that it will be more difficult to fix situation in the future. Making good roots will help much more....for customers. Imagine, that Microsoft will do secure system at last. It will difficult to sold next version. I don't want to believe, that this is reason, but...

Page 4 of 14 (198 items) «23456»