> The 'Warn you when something bad is about to happen", Jesper, is merely a
> reference to one of the purposes of the feature, from the viewpoint of the
> end user. The article isn't intended to be a technical dissertation on UAC,
> but instead merely an accurate guide to a technique which will make life with
> UAC more comfortable for the end user.
Understand, but the problem is that UAC is not only not capable of warning
you when anything bad is about to happen, it was not designed to do that. The
primary design purpose of UAC was to enable more people to run as a
non-admin. The misconception that it was is what has lead to the vast
majority of the criticism about UAC. In fact, that misconception is what
Apple capitalized on in their ludicrous commercials poking fun at UAC (in
spite of the fact that (a) Mac OS X has exactly the same feature, (b) except
that in Mac OS X it is disabled by default, like all their security, and (c)
Vista has process separation to make driving the UI harder, which Mac OS X
does not).
As long as people are told that UAC is a protection layer from bad code the
user chose to execute people will not only fail to act with the proper amount
of care but they will also become extremely dismayed when the bad guys figure
out how to circumvent UAC and attack their computers. At that point it is
likely that a lot of bad things could happen, starting with disabling UAC,
which will disable the protections that it DOES afford. It will also mean
that we will never end up in a truly bifurcated world as software developers,
lazy as we are, will never start writing code designed to run as a non-admin.
> When the technique is followed UAC prompts will be kept to a minimum, and
> when one appears the end-user will, indeed, be 'warned' if it is not in
> response to something the end-user has initiated and is aware of.
I agree that you can keep the prompts to a minimum, and that doing so is
valuable. Your technique works well for installers that UAC does not
auto-detect.