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

Re: Secure Chrome

From: Amir Herzberg <herzbea@macs.biu.ac.il>
Date: Mon, 12 Jun 2006 16:36:17 +0300
Message-ID: <448D6DD1.3010701@cs.biu.ac.il>
To: Chris Drake <christopher@pobox.com>
CC: public-usable-authentication@w3.org, Alex Dvorkin <kaledan@chaoslands.com>

Chris Drake wrote:
> 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.
But preventing this, i.e. properly framing every browser window, is 
definitely doable - although web designers may not like it.
> "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.
For this to work, server must identify browser securely. Currently, this 
is usually done by browser sending cookie over secure connection to the 
server. But cookies are not reliable: users erase them, change 
browsers/computers/disks, etc..

Would it help to make a more `permanent` kind of (limited) cookie?
Amir Herzberg
Received on Monday, 12 June 2006 13:37:14 UTC

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