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

Re: Secure Chrome

From: Jeffrey Altman <jaltman@secure-endpoints.com>
Date: Sun, 16 Apr 2006 19:13:15 -0400
Message-ID: <4442CF8B.3090102@secure-endpoints.com>
To: George Staikos <staikos@kde.org>
CC: public-usable-authentication@w3.org
George Staikos wrote:
> On Friday 14 April 2006 09:48, Jeffrey Altman wrote:
>> I came away with the following from the discussions I held at the
>> workshop:
>> (1) Secure Chrome is only secure if the user is able to distinguish
>>     the "secure" from the "insecure".
>>     Suggestions have included that secure chrome be displayed by
>>     the browser whenever the browser encounters a form that contains
>>     a password field.
>   I think that a password field only covers a limited subset of the vulnerable 
> types of data input, but it's a good start.


>>     When supported by the operating system is available, whenever
>>     the user clicks within the secure chrome the user would be
>>     removed to a separate desktop on which the user would be displayed
>>     information about whom the data is being sent to as extracted from
>>     a certificate (logos, common name, url, etc), a distinguishing
>>     identifier selected by the user (perhaps a photo), and the form
>>     to be filled in.
>   This really sounds over-complicated and confusing.  Conceptually it's an 
> interesting approach, but I'm not so sure that the user experience will be 
> the greatest.

I'm not sure that the user experience will be as the web site designers
would prefer because it removes the seamlessness of the site design.  On
the other hand, if we can train users to only enter passwords into a
secure dialog where secure means "a dialog that cannot be spoofed" and
that dialog can only be displayed when the URL is validated without user
intervention, I believe we will have gained a lot.

>> (2) Attackers must not be able to determine what the secure chrome
>>     looks like on any particular system.
>   There are interesting ways to do this.  I'm definitely interested in 
> exploring these.  For instance, personalization of the chrome.

Me too.  Where I see a problem with personalization is when the machine
being used is not regularly frequented by the end user.  For example,
libraries, airport terminals, etc.  In this case the user will not be
aware of the personalization for the machine and would not gain any

>> (3) Another thing that was discussed was a hardware indicator of the
>>     use of secure chrome.  This would require that the indicator be
>>     protected by the operating system and that the secure chrome itself
>>     could be triggered by the operating system.
>   This doesn't sound like it would apply across platforms (think: PDA, phone, 
> etc) well.
> [...]

Nor could it be deployed on existing equipment.  It was simply something
that was discussed.

>> I believe the use of secure chrome is a good idea, but it certainly
>> would not be a cure all.  It would simply raise the bar for the attacks
>> in the case where users can be trained not to accept certificates that
>> are not validated.
>   Agreed.

Jeffrey Altman

Received on Sunday, 16 April 2006 23:11:11 UTC

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