[LINK] Study shows pop-up warnings are ineffective

andrew clarke mail at ozzmosis.com
Tue Sep 30 08:18:53 AEST 2008


On Mon 2008-09-29 22:27:13 UTC+1000, Malcolm Miles (mgm-ns at tardis.net) wrote:

> >So much for Vista's pop-up based "security":
> ><http://www.vnunet.com/vnunet/news/2226765/study-shows-pop-warnings>
> 
> >> Fewer than a quarter actually attempted to close the pop-ups manually, 
> >> and one in six just dragged the box off the screen and carried on as 
> >> normal.
> 
> Which you can't do with a Windows UAC prompt. 

The article's comments about Vista are misleading, and I think the
study is a bit pointless.

>From what I can tell (judging by the remainder of the article) the
study was focusing on popup windows in web browsers:

http://en.wikipedia.org/wiki/Pop-up_ad

With pop-up ads it was easy to confuse the user into thinking that the
window was generated by the browser or operating system and not by the
(malicious) web site itself.

However, my understanding is that modern web browsers largely block
pop-up ads.  So it's old news, but that's not the end of it.

Some people unfamiliar to the user interface of their computer
software (versus the user interface of web sites) only have to see an
image (or an embedded object, eg. Flash, Java, Silverlight) of a fake
warning dialog box on a web page and they will click on it,
practically volunteering themselves as beta testers for malware.  ;-)

A realistic example of how this might happen:

- A web forum or blog software (eg. vBulletin, WordPress, etc) running
on a server was subtly hacked and code injected into the HTML;

- Instead of the usual page the user was expecting to see, a fake
dialog box was displayed informing the user that a virus was detected
on their PC.  With CSS or JavaScript coding techniques it's possible
to keep this fake dialog box in the same position on the screen
despite the use of the vertical scroll bars;

- The fake dialog box asks if they would like to install a free
antivirus scanner with a convincing name, eg. "Antivirus XP 2008";

- The user is gullible or inexperienced, clicks "yes";

- A malware-infected .exe installer is downloaded by the user's
browser;

- Despite the web browser's warnings against running programs from
untrusted sources, they run it;

- Game over. The malware is free to do as it likes, or at least as far
as Windows will let it according to the account restrictions of the
logged-in user.

Probably the only real solution here is user education, although
browsers still need to improve their user interfaces.  For example if
a browser has a legitimate dialog box to display then it needs to do
so in a way that convinces the user that it really is legitimate,
perhaps by temporarily disabling (and greying-out) all other browser
windows while it waits for the user.


On the subject of Vista's UAC...

I have not used Vista but from what I understand its UAC prompts are
primarily designed to prompt the user for a password in the case where
a program requires Administrator access to perform a particular
function.  There should be no way for malware to bypass UAC, but if
the user is determined to install a program they think is a legitimate
virus scanner (but is actually malware) then a few pesky UAC prompts
isn't going to stop them.

Also, it should be pointed out that not all malware needs
Administrator access to do its dirty work.  There are a lot of nasty
things a program can do within the bounds of a "limited" user account.
Send spam email, for example.  Or continously fetch a web page from a
server as part of a large botnet doing the same - a distributed
denial-of-service (DDoS) attack.

The above is also true in Mac OS X and Linux.  Despite what some
people think they are not invulnerable to malware, and malware does
not require root access to do malicious things.


On the subject of user interfaces...

Many computer users are guilty of not reading every dialog box that
prompts us to answer a question.  Particularly if we're anticipating
the prompt and already know the answer.  Over the years I've deleted
files this way, by accident.  I'm sure people who work at banks moving
large amounts of money around all day have clicked on an OK/Cancel box
without actually reading it, perhaps with devastating results.  It
becomes a habit, but it doesn't have to be that way...

In the days before Windows, most programs relied entirely on the
keyboard for input.  Some programs would empty the "typeahead buffer",
so that if an important prompt was displayed then any keys pressed by
the user before the prompt appeared would be ignored.  A safety
feature.

Then Windows came along and we all started using mice.  Those of us
who experienced software prior to Windows probably discovered early on
that when an OK/Cancel dialog box appeared, instead of using the
mouse, pressing Enter on the keyboard would hit the OK button, and
pressing Esc would hit Cancel.

Then we noticed that if you hit Enter before the window appeared, the
window would appear on the screen briefly then disappear again.  If
you blinked you might've missed it.  Who knows what the window was
actually telling you.  Too late, it's gone.  And we can't bring it
back, either.

Have you ever installed a program under Windows, accidentally
double-clicked on the Next button (or pressed Enter twice) during
Setup, then suddenly realised this actually meant that you
inadvertantly clicked once on the Next button, then once on the Finish
button?  Worse yet, you then discovered that the Finish button was
actually prompting you to confirm that you wanted to reboot your
computer.  But you'd already clicked Finish.  It was going to reboot
whether you liked it or not.

Of course a simple solution to this is to add a timer to the dialog
box so that the Finish button was inactive (greyed out or completely
invisible) for several seconds - just enough time for the user to read
what is on the screen.  Oddly though, this type of user interface
design doesn't seem to be very popular.  The only time I've seen this
type of behaviour in a program is in Mozilla Firefox (and
Thunderbird), where the user must wait 5 seconds before the program
permits them to install add-on software.

Regards
Andrew



More information about the Link mailing list