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

Re: Secure Chrome

From: George Staikos <staikos@kde.org>
Date: Sun, 11 Jun 2006 23:00:59 -0400
Cc: public-usable-authentication@w3.org
To: "Undisclosed.Recipients": ;
Message-Id: <200606112300.59355.staikos@kde.org>

On Friday 09 June 2006 17:12, Hallam-Baker, Phillip wrote:
> I do not understand the point being made here.
>
> The statement being made re secure chrome is that Web Browsers should
> provide some form of trustworthy UI path, that is:
>
> 	* 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.

> We know that existing browsers do not support secure chrome. Most deployed
> browsers support features that can only be described as complete lunacy
> 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".

> Without the ability to do a frameless popup the example shown simply
> becomes a web browser with two sets of menu and status bars. The user will
> probably find this confusing but it is unlikely that they will be tricked.

  This I'm not so sure about in terms of "unlikely that they will be tricked", 
but I do agree that once we axe the frameless popup, we will be in much 
better shape.

> There are two parts to this group as I see it:
>
> 1) Work out how to make chrome secure
> 	* Limitations on Javascript to prevent stomping
> 	* Limitations on controls
> 	* Ways of varying or customizing the interface
> 	* etc.
>
> 2) Work out what information the user needs to see in the secure chrome
> 	* Site info
> 	* SSL conection status info / gogreen(TM) / letterhead
> 	* ???

  I think it's still spoofable, but perhaps addressable.  I've seen some 
tactics in a few places where some sort of information well-known only to the 
user was placed in the chrome.  While it did require the user to actively 
look at the chrome to make sure the information was valid, the information 
was not spoofable since it was impossible for a site to know what that 
information was (barring any security hole in the browser implementation).  
Imagine a browser that had, in the tool/menu bar, "This is Phillip's 
browser." and a mini-picture of Phill's car.  It uses real-estate, and maybe 
that's not the best implementation, but it's an example of placement of 
information in a secured area that indicates the probable authenticity of the 
window.  I think that makes it much harder to spoof.

> Secure chrome is not necessarily just about the main fame. There are
> secondary dialogs as well. It may not be appropriate to display Secure
> Letterhead (logotype) info in the main browser frame as some argued at the
> meeting but it really should be the first information people see when they
> open the secondary dialog to see the cert info rather than a cert chain or
> an X.500 DN or similar.

  The secondary dialogs are worse problems than the main frame IMHO.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
Received on Monday, 12 June 2006 02:59:40 UTC

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