[LINK] Study shows pop-up warnings are ineffective

Craig Sanders cas at taz.net.au
Wed Oct 1 13:49:17 EST 2008


On Wed, Oct 01, 2008 at 11:52:29AM +0930, Glen Turner wrote:
> Ah, good olde blame the user.

yes, of course, you're right. it is NEVER, under ANY CIRCUMSTANCES,
appropriate to ever blame the user.

and that goes for any user of any device in any situation.

drunk driving, for example, is obviously the car manufacturer's fault
for making the car, or the government's fault for making the roads.
or the pedestrian/other driver's fault for having the temerity to get
in the way and die, but it's never the user's fault. it's not their
responsibility to EVER operate their equipment safely and responsibly.
that's just expecting too much from the poor little dears.


> The malware authors go to extremes to avoid popup blocking and to make
> their software appear real. Your example of Antivirus Xp 2008 is a fine
> example -- it looks real and every user has been "educated" into the
> need to run a virus scanner (Windows will even complain if you are not).

and they rely on the fact that users won't expend even the slightest
amount of thought. not even the most basic and obvious thoughts like
"why is there a popup asking if i want to install a program just because
i visited a web site? i better say No until i understand what's going
on"

in other words, "is the popup appropriate for the kind of activity i am
attempting?". appropriateness is context-dependant.  Are you sure?" is
appropriate after clicking Delete, "Do you want to install?" is NOT
appropriate outside of specific user-initiated contexts. if users would
even try to understand that, most of the problems would just go away.


which was the point of the original article - popup warnings are
ineffective because users just click through them without even reading
them.


and sure, bad software has induced popup burnout by popping up warnings
all the time - but it's not the software that chooses to click OK rather
than Cancel, it's the user.


> I much prefer the SELinux approach. Deny the activity and audit it.
> Put an alert on the screen saying the activity was denied. Give a
> audit review tool which allows denied requests to be authorised in
> the future.  This approach moves the consideration of security out
> of the heat of the moment.  Also, SELinux is a security perimeter,
> which means that when it says "no" the only way of getting to "yes"
> is through SELinux. It's not just asking about commonly-used exploit
> paths, but policing requests through all paths.

yes, that's a better approach.

it's not idiot proof, however.

stupid users would just disable it because it's too much trouble.

but it's not their fault - NEVER their fault.





the fact there is a lot badly designed and implemented software around
in no way entirely absolves users from their own stupid decisions
(and even stupider abdication from decision-making). even though it's
unfashionable to say so, users ARE partly to blame.


craig

-- 
craig sanders <cas at taz.net.au>


More information about the Link mailing list