Re: Secure Chrome (and secure browsing mode)

Let's remember that this is not break once run anywhere, we are not doing drm.

We are not protecting a single unique asset. This is a percentages game. Even if we only protect the vigilant that is a success.

We are not trying to prevent phishing here, I think the WARP bof at the ietf is also misnamed, we are not even necessarily aiming to reduce phishing with this single change by itself.

What we are trying to do is to provide one piece of an infrastructure which together helps to reduce successful attacks. 

 -----Original Message-----
From: 	Amir Herzberg [mailto:herzbea@macs.biu.ac.il]
Sent:	Mon Jun 12 04:53:21 2006
To:	George Staikos
Cc:	public-usable-authentication@w3.org; Alex Dvorkin; Ahmad Jbara
Subject:	Re: Secure Chrome (and secure browsing mode)


George Staikos wrote:
> On Friday 09 June 2006 17:12, Hallam-Baker, Phillip wrote:
>   
>> 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.
>   
I wish I could agree that this will make tricking `unlikely` - this was 
indeed our assumption with TrustBar. However in our experiments we found 
that displaying site identification - even personalized - helps, but 
there is still a significant fraction of failures to detect the 
spoofing. BTW, I've presented this `attack` also in the workshop - with 
the two menus.

The results do indicate a significant improvement in detection rates 
with improved (esp. personalized) security indicators - assuming these 
are protected in the chrome of course. However, these results motivate 
search for complementary measures, which will defend the user _without_ 
depending on the user to notice the security indicators. Which, I 
believe, is also what George is saying.

The current focus by MS & Google/FF on `blacklisting` (following 
NetCraft etc.), may be interpreted as a step towards automated defense; 
i.e.,  in some of these solutions, the browser actually blocks the 
suspect sites rather than expect users to notice. This is good, but 
unfortunately, I am skeptical about the long-term value of blacklisting 
against web spoofing/phishing. Spoofers can and will avoid blacklists; 
it is only matter of time and market share (of blacklists) till spoofers 
do this, resulting in another loss in credibility of secure e-commerce 
solutions. And we'll need real solutions at this point anyway.

Which motivates the following two solutions (any others?):

1. Avoid entry of sensitive data (passwords, credit card #, SSN, etc.) 
into forms. Main technique is probably by a `wallet/password manager` 
solution which (securely) stores the sensitive data and sends it only 
via SSL to appropriate sites. We are integrating such solution with 
TrustBar.

2.  `Secure browsing mode`, in which browser is limited to trusted 
content - certified by trusted authorities. Every figure, script and 
executable - signed. It may sound crazy to people familiar with the 
current contents of web sites, but is it really infeasible? We could 
begin with a solution for banks and brokers, which are probably the most 
critical targets. Initially, the solution may require user to use a 
special (secure) browser for these sites - this will be a simple 
recommendation that the banks & brokers can give to their customers. 
There are some technicalities to solve here such as the separation 
between script code and variables, which is one place where a W3C 
standard may help.
>   
>> 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).  
>   
Yes, and we have experiments which seem to validate the intuition that 
such customized information makes it easier for users to detect spoofing. 
> 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.
>   
I think it _is_ a bit absurd, to allow frameless popup and then ask 
users to to detect an identification of the `real` browser... The 
principle should be `defend don't ask` - in particular you should impose 
the control frame for all browser windows rather than ask users to 
detect the `real` frame by the picture of his car... Although I do agree 
it will have _some_ value.

But a customized picture is a good way to identify a trusted site e.g. 
your bank!!

Cheers, Amir