I feel that UAC is incorrect 99% of the time when it issues false positives

"Personally, I feel that UAC is 80% correct 100% of the time. Where UAC ceases to make sense is when 1 user action spawns 2, 3, or more UAC prompts."

I actually feel that UAC is incorrect 99% of the time when it issues false positives. For the longest time I've asked Microsoft to allow legitimate software publishers to bypass the UAC prompt for software upgrades or installations. This not only avoids most of the annoyances, but it's also less secure. It's less secure because the user sees UAC prompts so often that they are likely to brush it off and say yes when they really need to say no. If legitimate software doesn't trigger UAC, it makes illegitimate software all that much more conspicuous.

The problem for Microsoft is that they fear that if they allow ISVs to bypass UAC for software installations using a digital certificate, then they can just as easily bypass UAC for normal software operation which defeats the purpose of UAC. My solution for that is to issue special code installation certificates that are backed by a bond of say $5000. The ISV will agree to ONLY use these code signing certificates to enable software installers to bypass UAC and NOT abuse it for normal software operation. If they do abuse it, their certificate gets revoked and they lose their bond. This would allow major ISVs like Apple, Mozilla, Adobe, Microsoft, etc to make pain free software installers.

Update - My criticism to Microsoft applies even more to Apple and *NIX. Both Apple and *NIX require you to not only click, but you need to enter your password as well.

UAC, this ad was used by Apple

http://movies.apple.com/movies/us/apple/getamac/apple-getamac-security_480x376.mov

UAC has received a most thorough 'battering about the head' by the press, perhaps undeservedly. *nix 'su' or 'sudo' are less intrusive and most effective at gatekeeping admin rights, which is not to suggest that UAC has not reached the same intended goal but the apparent 'pain' of UAC interaction is evident at this point.

It can be argued whether or not the ongoing Apple TV PC/Mac guy advertisement campaign has been successful at highlighting some of the more prominent underlying/perceived weaknesses of MS Windows products, particularly Vista, to differentiate Apple Mac as being of a higher overall quality. Their campaign has been very clever and funny, but I am not convinced theirs is any better than a well-oiled Windows or Linux machine.



UAC

My criticism to Microsoft applies even more to Apple and *NIX.

Dietrich, Apple is worse than UAC. They not only prompt you, they require you to type in the password.

My criticism to Microsoft applies even more to Apple and *NIX.

Re: Microsoft's Achille's Heel

OK, so, would it be correct to say you feel that prompting for a password is a 'deficiency'? If so, why?

Thanks

To the extent that prompting a yes/no at all is too much of a hassle for users, prompting for a password and yes/no is WORSE.

If you read my criticism of Microsoft, I feel that Microsoft shouldn't prompt for privilege escalation for software installations of software from legitimate software makers AT ALL. So to the extent that prompting a yes/no at all is too much of a hassle for users, prompting for a password and yes/no is WORSE. So Vista is actually not as bad as Mac OS X and any UNIX variant that demands passwords for privilege escalation.

Note that I am NOT saying there shouldn't be privilege escalations; I'm saying you don't need them when you're installing software from a trust worthy company. I define a trust worthy company as someone willing to put up a bond to show that they will not abuse a UAC-bypass code signing cert for anything other than legitimate software installers. If they produce malware, spyware, or even software that that bypasses a privilege escalation prompt, the code signing cert is revoked and they lose their bond. I think it would also be reasonable to wave the bond for respected non-profit open source shops assuming they behave within the guidelines.

Re: Microsoft's Achille's Heel

Well, as for Linux, personally, I never have felt inconvenienced for answering a prompt for a password. And just one GUI prompt is all you receive in 99% of cases for software installation/system configuration access, with all due respect to your viewpoint.

Giving away that authority might have its advantages with trusted sources, but it's very much a 'double-edged sword'. And you can find yourself very quickly hoisted on your own patard.

sudo is your friend. :)

Putting up a quid pro quo for the benefit of bond set that high seems to be a barrier to doing business rather than a benefit.

Thanks.

You need to understand the purpose of the bond

"Putting up a quid pro quo for the benefit of bond set that high seems to be a barrier to doing business rather than a benefit."

You need to understand the purpose of the bond. It's there to ensure that the ISV doesn't abuse their code signing privileges. This is an essential usability feature for mere mortals who don't grep sudo :).

Re: Microsoft's Achille's Heel

Ok, I guess I hit oil, so I'll stop drilling. Next topic. :)

Re: Microsoft's Achille's Heel

The idea of bonded development shops interesting idea, and we've discussed it before. One immediate problem with it that pops into my head (but never did before tonight, oddly) is what to do about open source projects. It's not just the money... as you said privately, exceptions could be made for non-profit organizations. The problem is the word "organization". A lot of OSS projects do not exist as legal entities. Who would you assign the rights to? The nature of open source itself poses another issue, the moment something goes GPL, the only people that can re-sign the code with the certificate is the original code author (or whoever holds the certificate). Unless you would ask the original certificate holder to sign the code for anyone and everyone who has forked the code, this would severely limited open source projects.

Another problem is interpreted code (as opposed to compiled code). As hardware advances, interpreted code is becoming more popular since the traditional performance problems are being eliminated through faster hardware (and smarter interpreters). In an interpreted code situation, you can sign the interpreter, but not the code; as far as the OS is concerned, the relationship is: interpreter is to code as Word is to Word document. To trust the entire interpreter is to trust any code put into it, unless the interpreter somehow guarantees that the authors of code will never abuse that trust. You know, like click a checkbox when downloading the interpreter, "I promise to never write code that modifies the system directories inappropriately, since the interpreter is trusted to modify them without UAC".

Of course, this may be the actual itent. If the goal is to raise the barrier of entry to getting software deployed on a mainstream basis (hard to compete when the system nags on your code a lot more than the competition's), this would be an effective start. Indeed, it could be argued that since most of the problematic software is caused by poorly trained developers. Just as print magazines tend to have more money put into the design and writing than online publications (and even more for TV) due to the cost of content creation, it is likely that projects that need to conjure up some money or can somehow prove that their code can be trusted or that their developers are certified in "safe techniques" will have a higher level of quality that the "I got it to compile, so I guess it's done" developers out there.

J.Ja

Re: Microsoft's Achille's Heel

Everything that <*> does seems to be about 80% finished

* Software vendor
* Hardware vendor
* Open-source project
* A human

Re: Microsoft's Achille's Heel

George: "If you read my criticism of Microsoft, I feel that Microsoft shouldn't prompt for privilege escalation for software installations of software from legitimate software makers AT ALL."

I feel the same way you do re Microsoft's half baked UAC implementation. Glad to see MS stepping out in this direction in the name of shoring up overall platform security, but they need to go even further to improve user friendliness and ease of acceptance with UAC measures. Short of that, lots of folks may feel the impulse to ditch the initiative wholesale just to get back to the basics of hassle free computing [oxymoron withstanding].

Justin: "Everything that Microsoft does seems to be about 80% finished."

It's all part of the time honored "Microsoft Way." Sad to say though, they're not the only ones in the industry guilty of rushing their goods out of the oven half baked. They just have more ground to cover than most.

Dietrich: "OK, so, would it be correct to say you feel that prompting for a password is a 'deficiency'? If so, why?"

Not a deficiency; try overkill instead (i.e. an extra and unnecessary annoyance when it comes to these types of prompts). Look up "crying wolf syndrome" - or shades thereof. Redundancy has its limits.

PS. Good to see Justin contributing here. Can recall a number of nice chips you've submitted over at TR in recent years.

Re: Microsoft's Achille's Heel

and lol at dre. You got that right (only re the last item: isn't that being a tad generous? Try maybe HALF of that at our apex, at the very moment before we jump in the hole and leave it all behind). :-)

Re: Microsoft's Achille's Heel

Klumper -

Thanks, and good to have you here as well!

J.Ja