The purpose of User Account Control (UAC) according to one of its designers

MrBrian · Jun 1, 2010

From http://www.withinwindows.com/2009/06/10/uac-uac-go-away-come-again-some-other-day/#comment-3987:

I was part of the team that designed UAC. I’ll give you a little insight into the history of UAC and address some of the comments made on this blog post. Here we go…

As with any major initiative, especially one involving a multi-year effort involving 10s of engineers and affecting every application on the face of the earth, you don’t always end up with the exact technology you envisioned when you started. Hell, in the case of UAC we even changed the name of the feature several times – I bet no one remembers that it was called Flexible Account Control Technologies at one point.

If my memory serves me, when we started the UAC project, we firmly believed it would be a security feature. We wanted to protect users on the Windows system from malware. We also had the goal of incentivizing the use of Standard User accounts, which is something MSFT has been trying to do for several releases of Windows.

From my perspective, the design was brilliant and I take no credit for the creation of the split token. That concept was extremely powerful though because it modeled the default token to be that of a Standard User. In Vista, there was no compromise when it came to prompting and I remember answering the question “is there a white list for applications?” in every UAC talk I ever gave. Have no false pretense, that prompt isn’t security theatre – it is a giant stop sign that says: “This ISV wrote software that unnecessarily requires Administrator privileges!” This is exactly why you see the prompts today on Windows 7 targetted at 3rd parties.

As for the security messaging around UAC. The point where our messaging switched from security to reliability was when the product team engaged the support of our Secure Windows Initiative (SWI) team to PenTest UAC. They clearly demonstrated because of the shared state, HKCU, user profile, etc., between the “little Abby” and “big Abby” tokens (as we referred to them) that UAC elevations could never be a security feature – this was also right around when MarkRuss came to MSFT. He was also instrumental in demonstrating the flaws in our messaging!

I’ll admit that the product team was taken aback by this change in messaging and it took some of us longer than others to adjust to the new messaging. The good news is that I believe everyone at MSFT recognizes that UAC elevations (particularly for PA accounts, but also for Standard User accounts) is not a security boundary. If you want the highest level of security…never elevate a standard user account in an interactive session – this is achievable in an enterprise.
Click to expand...

Daveski17 · Jun 1, 2010

And there was me thinking it was designed primarily to scare the pants off of first time Vista users.

chronomatic · Jun 1, 2010

I have seen UAC developers say this before -- UAC is not a security boundary but rather more of a nag screen aimed at third-party developers to make it so they stop letting their programs unnecessarily require admin privs.

The lesson is that one should use a standard account and not rely on UAC to protect an admin account.

Log in or Sign up

The purpose of User Account Control (UAC) according to one of its designers

MrBrian Registered Member

Daveski17 Registered Member

chronomatic Registered Member

Log in or Sign up

The purpose of User Account Control (UAC) according to one of its designers

MrBrian Registered Member

Daveski17 Registered Member

chronomatic Registered Member

Useful Searches