W3C home > Mailing lists > Public > public-usable-authentication@w3.org > June 2006

Re[2]: Secure Chrome

From: Chris Drake <christopher@pobox.com>
Date: Mon, 12 Jun 2006 21:05:36 +1000
Message-ID: <1262257619.20060612210536@pobox.com>
To: George Staikos <staikos@kde.org>
CC: public-usable-authentication@w3.org

Hi Guys,

>> * There must be a clear visual distinction between 'control' and 'data'
>>  * Data elements must not be allowed to overlay or otherwise simulate the
>> control area

>  Agreed.

Sorry to broadside this debate again - everyone keeps forgetting
this:  http://guardpuppy.com/BrowserChromeIsDead.gif

You can put as much effort as you want into chrome, and 100% of it
will be wasted when the spamming phishers etc just visually simulate
the entire browser UI.

"Secure Chrome" is not a sensible or workable solution.

What *IS* a secure and sensible solution is using shared secrets to
authenticate resources to users - either before they "log in", or as
part of the login process.  This is easily implemented within a
browser with simple visual graphics, without using any chrome or
requiring browser makers to change anything, and can easily be done to
prevent both the visual attack that google demonstrated above, as well
as man-in-the-middle/proxy attacks.

>> from the security perspective. Quite what was going through people's minds
>> when they invented frameless popup windows I don't know.
> Agreed.  In fact I have long tried to remove such things in Konqueror, but
> that's considered a "broken browser".

Remove popups, and the spammers will use <DIV>s - there's a *ton* of
good reasons for frameless popups - the only reason a minority of
people don't like them is because every now and then someone does
something with them that annoys people.

> Imagine a browser that had, in the tool/menu bar, "This is Phillip's
> browser." and a mini-picture of Phill's car.

That doesn't protect Phill from https://www.paypa1.com - or if it
somehow *did* - then it makes it impossible for www.mywebsite.com to
take advantage of phills car, or if you somehow allowed that too -
then https://www.paypa1.com goes live again...

The browser executable is the wrong place for secure chrome - it
belongs with the resource who's trying to protect Phill (paypal's web
site).  Once PayPal etc finally work out that they've got to
authenticate themselves to Phill *before* asking Phill to authenticate
to them, the whole problem goes away - without slapping more stupid
restrictions on web designer creativity and browser usefulness.

Kind Regards,
Chris Drake
Received on Monday, 12 June 2006 11:05:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:15 UTC