RE: Secure Chrome (and secure browsing mode)

I agree with Mez except that in addition to being timely, I see the outbound issue as one where there is a pretty clear standards need and W3C is the only likely contender as a forum.
 
The problem of password management is currently recognized by at least four groups - OpenID, DIX, SAML, Cardbase/Higgins. And there is the WARP BOF planned for the IETF in Montreal, work in OASIS and so on. The primary political objective has to be to gain some unity of direction and viewpoint and hopefully make 4 = 1.
 
To make that secure we need to push the authentication down into the operating system as Cardbase (infocard) does with Vista. We need to recruit the Linux and Apple O/S developers, the phone O/S developers and so on. Perhaps it is a small enough world that there is no need for a standards group, perhaps we do need a group. At the moment though Identity 2.0 is where the bleeding edge is bleeding fastest. Lets work out where the wounds are before trying to apply bandages.
 



________________________________

	From: public-usable-authentication-request@w3.org [mailto:public-usable-authentication-request@w3.org] On Behalf Of Mary Ellen Zurko
	Sent: Thursday, June 15, 2006 7:57 AM
	To: Thomas Roessler
	Cc: public-usable-authentication@w3.org
	Subject: Re: Secure Chrome (and secure browsing mode)
	
	

	> The things that I'd think would be most useful to do (doing in
	> the sense of having a working group about them) in order to
	> meet the goal of helping vigilant ("suspicious", whatever we
	> call them) users:
	> 
	> - Define a baseline set of security context information that
	>   will be presented consistently, across browsers, e.g., "pick
	>   these elements from your X.509 certs", "add that information
	>   from whateversecurityprotocolcomesnext";
	> - define best practices for how to present them nicely,
	>   non-scarily and usably;
	> - define requirements that list precisely what browsers should
	>   not let content do to user interface elements, in particular
	>   those that are used to present security relevant context.
	> 
	> Comments welcome.
	
	As a set, this only makes sense if the security context information can be displayed non-spoofably. By that I mean a decent visual indicator when they're "different" from what you expect, not expecting the user to deal with character sets or logos that look the same but "are not". That could be done with browser history. There might be other ways. So I would insert "non-spoofably" in the middle bullet. 
	
	The security/crypto fixes to sharing the same password and/or PII with any site have the biggest impact potential, but are probably slightly longer term and more sweeping than what you're trying to target. 
	
	It's my personal belief that per-site personalization is likely to fall to the same reuse, homogeniety, and scaling issues that hit passwords and other information, if they were successful. I'd use my favorite picture of my kitty on all sites, even random evil sites trying to get that information from me in a follow up spoof. And oddly enough, the users I've talked to "in the wild" don't get the whole personalization as site authentication thing. But these opinions are not backed by any rigorous data. 
	        Mez