Re: Secure Chrome

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 13:48:09 UTC