Re: Secure Chrome

I'd like to pick up an earlier contribution by Phill: Right
now, we often don't even give useful tools to the *suspicious*
user.  That's the first thing to change.

I'd see work in this direction chartered, roughly, as resulting
in "here's a minimum set of context elements that you should
make accessible to the user", "here are some good ideas on how
to do it", and "by the way, please don't do x in scripting,
because else it's all fakeable too easily".

In other words, I'd suggest that we charter a group to be very
explicit about (a) what sites can expect to be displayed to
users, and (b) what *not* to do as a browser (this would
hopefully give browser makers a good excuse to "break" some of
the more dangerous features, such as frame-less pop-ups, hiding
status bars, etc).

That said, it's not clear to me that we should expect this
particular direction of work to solve problems like the <div/>
element that shows a screen-shot with the right stuff in it.

To make shared secret based approaches work, you'll need to
have the crypto in place on the protocol level so the secret
isn't displayed to any attacker; this strikes me as something
that would happen on a different time scale.

-- 
Thomas Roessler, W3C   <tlr@w3.org>








On 2006-06-12 09:46:43 -0400, Frederick Hirsch wrote:
> From: Frederick Hirsch <frederick.hirsch@nokia.com>
> To: "ext Hallam-Baker, Phillip" <pbaker@verisign.com>
> Cc: Frederick Hirsch <frederick.hirsch@nokia.com>,
> 	George Staikos <staikos@kde.org>,
> 	public-usable-authentication@w3.org
> Date: Mon, 12 Jun 2006 09:46:43 -0400
> Subject: Re: Secure Chrome
> List-Id: <public-usable-authentication.w3.org>
> X-Spam-Level: 
> X-Archived-At: http://www.w3.org/mid/C00EDA72-C79B-4ABB-BBF0-BBF243DBDACA@nokia.com
> 
> 
> I have a general question about secure chrome, which I think  
> reiterates what George said.
> 
> What is to prevent an attack on secure chrome by simply replacing the  
> entire browser implementation, so that the secure chrome isn't  
> effective since the underlying code is modified? Is the intent to  
> remove insecure functionality so that this attack would not work  
> undetected?
> 
> (in this case open source seems to enable a modification/replacement  
> attack on the entire browser implementation itself)
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> On Jun 9, 2006, at 5:12 PM, ext 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
> >
> >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.
> >
> >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.
> >
> >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
> >	* ???
> >
> >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.
> >
> >
> >>On Thursday 25 May 2006 16:37, you wrote:
> >>>Google published an "attack" on Secure Chrome that Jeffrey Altman
> >>>described earlier. I've put the relevant slide here:-
> >>>http://guardpuppy.com/BrowserChromeIsDead.gif
> >>>This came from http://www.w3.org/2005/Security/usability-ws/report
> >>>which links to Jeffrey Nelson & David Jeske's paper - their
> >>slides are
> >>>here:-
> >>>http://www.w3.org/2005/Security/usability-ws/presentations/37-google
> >>>Their paper here:-
> >>>http://www.w3.org/2005/Security/usability-ws/papers/37-google
> >>>
> >>>The picture quite dramatically explains everything!
> >>
> >>  Isn't that exactly what I said, repeated, and repeated
> >>again at the workshop? :-)  There are ways to improve on it,
> >>but we need, what I think, is a radically different approach.
> >> I'm just not sure what it is yet...
> >>
> >>--
> >>George Staikos
> >>KDE Developer				http://www.kde.org/
> >>Staikos Computing Services Inc.		http://www.staikos.net/
> >>
> >>
> >>
> >
> 
> 
>

Received on Monday, 12 June 2006 14:44:23 UTC