R
Rock
Manatee Memories said:
You see it as slavery? I don't. Now the user has the control. Otherwise,
as in XP, any program running with admin privileges can do what it wants
when it wants. How is that control?
You see it as slavery? I don't. Now the user has the control. Otherwise,
as in XP, any program running with admin privileges can do what it wants
when it wants. How is that control?
S
Stephan Rose
Rock said:
Because the user can't choose when or if they want this level of control. It
is forced upon them.
--
Stephan
2003 Yamaha R6
å›ã®ã“ã¨æ€ã„出ã™æ—¥ãªã‚“ã¦ãªã„ã®ã¯
å›ã®ã“ã¨å¿˜ã‚ŒãŸã¨ããŒãªã„ã‹ã‚‰
A
Adam Albright
UAC does not always function as it was designed to. It does not learn
either which is my big gripe. If the two principle code writers of UAC
ADMITTED as they did in so many words in a extended interview and
pleaded with users to tell them when it acts up and this revealing
interview was conducted by another Microsoft employee and made
available as a web cast to anybody that wants to invest over a hour
watching it so they can see Microsoft itself ADMITTING that UAC has
issues and really doesn't offer the "security" some preach it does why
do so many fanboys go blindly on defending it?
After having UAC turned off for several weeks I again turned it on
yesterday. It promptly started doing the same dumb things.
All the video files I work on start off in the same folder on the same
hard drive. I delete these raw files once I've done whatever I'm going
to do to them and have replaced them and sent to other drives in a
finished version.
I KNOW without a doubt UAC is a pile of s*it when it will delete one
file from the original source file when I tell it to and never show a
prompt then nag it's ass off asking for my permission on the next file
I try to delete in the same folder. It is hit or miss. If this is
Microsoft's idea of "security" it is useless.
N
NotMe
The biggest problem is that when you turn it off, it breaks other things.
If you could turn it off, and everything else still worked properly, I
wouldn't have as big an issue with it.
You like it and want to use it. That's great for you.
I don't like it and want it gone, but when I turn it off, it breaks things
that I DO want to function.
Have it OUR WAY at MS Today.
If Burger King had taken that attitude, they would be gone, not a giant in
fast food.
If you could turn it off, and everything else still worked properly, I
wouldn't have as big an issue with it.
You like it and want to use it. That's great for you.
I don't like it and want it gone, but when I turn it off, it breaks things
that I DO want to function.
Have it OUR WAY at MS Today.
If Burger King had taken that attitude, they would be gone, not a giant in
fast food.
F
Frank
What does it break turned off?NotMe said:
Frank
8
=\(8\)
Carey Frisch said:
hat I understand is that in typical Microsoft fashion UAC is an all or
nothing setup. I am not going to deal with all of the freaking popups every
time I want to make a change to my start menu. UAC goes way to far and is a
nightmare feature that while it may make Windows safer for the stupid people
it does make it a nightmare of popup clicking for the rest of us. I strikes
me as funny that MS finally added popup blocking for the internet and then
turned around and made a popup hell in the rest of the OS. Nice job.
R
Rock
I don't use it with UAC off nor have I set up installations where it's on
for some installations, then later turned off. Though by virtue of file
virtualization, and other issues, I can see where doing the latter would
cause its own problems. Can these problems be avoided by turning off UAC
right from the start? I don't know. Some apps won't install without UAC, I
believe Adobe Reader is one.
Yes I agree that if the user wants to turn it off, it should not make things
more difficult or create more problems by that fact.
J
Jimmy Brush
Thing is, this will never be a valid assumption -- that a program that
performs an admin action will always be legitimate.
You did not state it, but you imply here that "If someone has an app
that they know is *legitimate* and will *always* be legitimate" ONLY if
they are the ones starting the program.
UAC is not just asking you if you trust a program - it is asking you if
you started it, as well.
Because without the prompt, non-legitimate applications could start the
legitimate ones, which negates the legitimacy.
J
Jimmy Brush
Stephan said:
It is your choice.
J
Jimmy Brush
Spirit said:I fully understand UAC, I just think its implementation is the pits! I am
usually logged in as
Admin and DO NOT NEED to be repeatedly told the same ALLOWED program wants
to do something..... there needs to be a way to STOP ITS NAGGING! I want a
DIVORCE
from UAC......Nagging when something not FLAGGED as always allowed
would be
a good thing.
Thing is, UAC is not just asking you if you trust the program, it is
asking you if you started it.
This may seem irrelevant at first glance, but it is important.
You may trust a program to format your hard drive or perform any other
admin action ... but do you also trust malware and any other untrusted
program to use that trusted program to format your hard drive or perform
any other admin action?
If UAC didn't prompt every time to make sure you are the one starting a
program, than any UNTRUSTED program could use those trusted admin tools
on your computer to perform those trusted actions, without you knowing
about it.
J
Jimmy Brush
If UAC had some sort of learning algorithm, where it could somehow tell
with X% accuracy whether you were starting a program or not as opposed
to a malicious program, would that be good enough?
I think we can both agree that it would never be able to get to 100%
accuracy, without actually asking the user whether they are the one
starting the program or not, which is what happens now.
So ... How accurate is good enough?
99.9%?
That means that 1 out of every 1000 times an admin program is run, UAC
fails to correctly identify that a user is the one starting it, and so a
malicious program that is trying to start the admin program would succeed.
Multiply that by the millions of users of Windows Vista.
To simplify things, let's say that there's 10 million Vista users and on
average they run one admin program a day.
That means 70,000 users *per week* are not being protected by UAC.
Is that good enough?
with X% accuracy whether you were starting a program or not as opposed
to a malicious program, would that be good enough?
I think we can both agree that it would never be able to get to 100%
accuracy, without actually asking the user whether they are the one
starting the program or not, which is what happens now.
So ... How accurate is good enough?
99.9%?
That means that 1 out of every 1000 times an admin program is run, UAC
fails to correctly identify that a user is the one starting it, and so a
malicious program that is trying to start the admin program would succeed.
Multiply that by the millions of users of Windows Vista.
To simplify things, let's say that there's 10 million Vista users and on
average they run one admin program a day.
That means 70,000 users *per week* are not being protected by UAC.
Is that good enough?
S
Stephan Rose
Jimmy said:
Sure it is, but only in terms of switching to a different operating system
which I am gladly am doing.
By plenty people, MVPs included, accounts turning of UAC in turn causes a
host of other problems and causes other things to not work.
So when turning *off* a "feature" that I don't want causes other things to
break, then it isn't really a choice.
--
Stephan
2003 Yamaha R6
å›ã®ã“ã¨æ€ã„出ã™æ—¥ãªã‚“ã¦ãªã„ã®ã¯
å›ã®ã“ã¨å¿˜ã‚ŒãŸã¨ããŒãªã„ã‹ã‚‰
S
Stephan Rose
Jimmy said:
And that's where UAC's failure is.
It is counting on the *reaction* of the user to be correct.
It'd be a far better approach if by definition no single application on the
system could ever perform *ANY* administrative operating under any
circumstances except one: The user ahead of time gives the program one-time
permission to do so. Once the application is done...the permissions go
away.
This makes any type of prompts unnecessary except when the user initiates
the prompt. The user has to *act* not *react*.
See that difference?
--
Stephan
2003 Yamaha R6
å›ã®ã“ã¨æ€ã„出ã™æ—¥ãªã‚“ã¦ãªã„ã®ã¯
å›ã®ã“ã¨å¿˜ã‚ŒãŸã¨ããŒãªã„ã‹ã‚‰
J
Jimmy Brush
You're right, that is unacceptable. Fortunately, this should be less and
less of an issue as software developers start writing Vista-compatible
apps, which would not be affected by turning uac on or off.
J
Jimmy Brush
Stephan said:
UAC works exactly how you describe.
The user gives their "one-time permission" for admin power when they
start an admin app, click a button that starts an admin operation, or
right-clicks a non-admin app and clicks run as administrator, which is
then confirmed by the OS via the prompt.
S
Stephan Rose
Jimmy said:
But you are only stating the few cases where the user actually is *acting*
by knowingly starting such an app.
What if a malware process gets spawned and such a prompt comes up?
What if another process spawns a malware process and such a prompt comes up?
What if the prompt is caused by a virus trying to infect the system?
Isn't the point of UAC to prompt the user in those cases to make sure they
started said process? Per your own words?
Those are the types of cases where UAC is of any importance. Those are the
types of cases where the system has to rely on the users reaction. Those
are the cases where it will fail as it has to count on the user not making
a mistake in their decision. People make mistakes.
Now if the process is named "BillyBobTheVirus.exe" then the user might have
an educated means of making a proper decision. I'm saying might because I
know there are enough people out there who would actually allow it to run!
If the process however is named after some MS related or 3rd party related
application that the user knows and trusts and possibly even closely
resembles valid prompts that the user is used to getting, then at this
point in time, UAC fails because the average user is going to make a
mistake eventually.
Anything that has to rely on the user intervention for it's success is
doomed for failure. This is not because a user is necessarily stupid. It's
because everyone eventually makes a mistake.
--
Stephan
2003 Yamaha R6
å›ã®ã“ã¨æ€ã„出ã™æ—¥ãªã‚“ã¦ãªã„ã®ã¯
å›ã®ã“ã¨å¿˜ã‚ŒãŸã¨ããŒãªã„ã‹ã‚‰
J
Jimmy Brush
But you are only stating the few cases where the user actually is *acting*
No, this is the MAJORITY of cases. *All* valid UAC prompts occur
immediately after a user action. *All* other prompts are invalid - this
is why UAC works.
I (finally) see what you are getting it... in the case where an admin
program starts that the user does not start, they may enter their admin
password or click continue and allow the program to run, even though
they may not have started it.
However, I would point out that they are still in control, which is
something that was not true before, even if they do make a mistake. But
I do concede that this makes UAC less than perfect at its job, even
though the user is still in control over the failure case, which is MUCH
better than the user not being in control over the failure.
And this is still more secure than giving admin power to any program
that wants it.
The solution to this problem would be to make the actionable input event
verifiable without needing an out-of-band prompt.
That would indeed be groundbreaking, since no other OS does that.
I certainly hope we get to that point
No, this is the MAJORITY of cases. *All* valid UAC prompts occur
immediately after a user action. *All* other prompts are invalid - this
is why UAC works.
I (finally) see what you are getting it... in the case where an admin
program starts that the user does not start, they may enter their admin
password or click continue and allow the program to run, even though
they may not have started it.
However, I would point out that they are still in control, which is
something that was not true before, even if they do make a mistake. But
I do concede that this makes UAC less than perfect at its job, even
though the user is still in control over the failure case, which is MUCH
better than the user not being in control over the failure.
And this is still more secure than giving admin power to any program
that wants it.
The solution to this problem would be to make the actionable input event
verifiable without needing an out-of-band prompt.
That would indeed be groundbreaking, since no other OS does that.
I certainly hope we get to that point
S
Stephan Rose
Jimmy said:
In theory. Reality on the other hand has to deal with the problem located
between the keyboard and chair.
Precisely. =)
The damage is already done at that point though. Not much point in being in
control over a burning wreckage!
Now on that I fully agree with you.
Will never happen unless computers get the ability to read the users mind.
There's just simply absolutely no way to detect if an action is wanted by
the user or not. Even if an action might be damaging to the system, there
still might be a valid reason for the user needing to do it.
That would indeed be groundbreaking, since no other OS does that.
I certainly hope we get to that point
That'd be nice but like I said, without mindreading capabilities, I just
don't see it. =)
And even *with* mindreading capabilities, I wish any computer luck reading
my mom's mind. She can't ever make a decision. =)
--
Stephan
2003 Yamaha R6
å›ã®ã“ã¨æ€ã„出ã™æ—¥ãªã‚“ã¦ãªã„ã®ã¯
å›ã®ã“ã¨å¿˜ã‚ŒãŸã¨ããŒãªã„ã‹ã‚‰
J
Jimmy Brush
Well, there are kind of two separate issues rolling around at this point:
1) What well-defined action is the user taking (in fact)
2) What is the user hoping to accomplish from the result of that action
While #2 might need some voodoo hocus pocus to work, I strongly believe
determining #1 is entirely possible.
You're saying that when a user grabs a hot piece of metal and burns
themself, it's impossible to determine whether the user is actually
wanting to burn themself or not (after all, they may have a good reason
for doing so).
I agree.
However, UAC is only about determining if the user did, in fact, grab
the metal - or not. Did somebody throw it in the user's hands, or did
they grab it?
The problem with UAC is not that the user can burn themself, but that
they can say that they grabbed the metal when they did not, or say that
they did not grab the metal when they did.
The problem isn't really that the user can make a mistake - it's that
the user can make perform an action (or inaction, in the case of not
starting a program but it runs anyway) which is correct by definition
(correctness being defined as whatever the user is or is not doing) and
then TURN it into a mistake.
I believe it is possible to get rid of this action/prompt mechanism and
replace it with a verifiable action mechanism, at least in the context
of a GUI - this would be much more difficult in a purely CLI, I think.
This wouldn't stop people from using tools to hurt themselves. Nothing will.
But it starts to ensure that the user is indeed the one hurting
themself, as opposed to a program doing the hurting.
This starts to draw a line between what actions the user is taking vs.
what actions a program is taking, and enforcing different security
policies depending on which one is going on and what action the user is
taking, and I really hope that we will see this sort of thing happen in
future operating systems.