RE: Secure Chrome

I'd like to suggest we adopt a very broad definition of "chrome" to
include not only security indicators like the padlock icon, but also the
address bar, menus, bookmarks/favorites, and all dialog boxes.  Pretty
much everything an end user would intuitively expect to be part of the
browser software and not the web page content.

With that in mind, I very much agree this need to be addressed.  As long
as http delivered content (including active scripts/objects) can modify
parts of the window users think are controlled by the browser, that
capability will remain an attack vendor for phishers and other
criminals.

These are some of the relevant requirements FSTC members (financial
institutions & technology vendors) identified in the Better Mutual
Authentication project:

 - Make it impossible for client scripts, controls, add-ons, or plugins
to alter address bar or padlock icon
 - Show a padlock or equivalent in all modes including full-screen
 - Make built-in browser dialog boxes visually distinguishable from
script generated dialog boxes

Mike McCormick
Co-chairman, FSTC Standing Security Committee

-----Original Message-----
From: public-usable-authentication-request@w3.org
[mailto:public-usable-authentication-request@w3.org] On Behalf Of Thomas
Roessler
Sent: Monday, April 10, 2006 12:30 PM
To: public-usable-authentication@w3.org
Subject: Secure Chrome


Hello,

one of the topics that we believe to be likely candidates for further
work as an outcome of the workshop in New York -- and that we solicit
your feed-back on -- is Secure Chrome.

This kind of work would cover best practices in terms of what sites
should or should not be able to control in a browser's user interface,
and, possibly, a switching mechanism between a rich and a safe browser
mode, as discussed at various occasions in New York.

To a certain extent, this is the flip side to the secure metadata
discussion: Secure display of metadata requires that there are parts of
the chrome that can't otherwise be written to, and that can't be hidden
easily.

Now, let the discussions begin...

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

Received on Wednesday, 12 April 2006 07:43:25 UTC