RE: Artifacts and clutter (was: "Greetings")

Another way to deal with expired certificates is to simply not display
the lock icon at all and to only warn if the user typed in https rather
than being redirected.
 
If we are telling the user it is safe we should not be telling them that
it is not safe at the same time.
 


________________________________

	From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Timothy Hahn
	Sent: Wednesday, November 01, 2006 1:50 PM
	To: public-wsc-wg@w3c.org
	Subject: Re: Artifacts and clutter (was: "Greetings")
	
	

	Mike, 
	
	Please don't take my comments the wrong way here. 
	
	My impressions of where we are on this are that we have come
about this situation quite honestly and not by intent but rather no
better alternatives (at least so far). 
	
	I haven't written a line of user interface code (other than
parsing command-lines - and that doesn't count).  But I can see easily
how when faced with a "potentially dangerous" situation within a code
path of a browser's code, it is considered better to "ask for some human
to make a choice, or at least let someone know something looks
off-kilter" than the alternative of not doing so.  Thus the birth of a
Message box or two ... and then another, and another, and so on.   
	
	And for someone who understands SSL and certificate
verification, and what it means that a certificate is self-signed or has
expired, answering the questions isn't too bad. 
	
	I couldn't begin to describe to my kids, however, how to react
to such situations they might be subjected to. 
	
	I think you are onto something with respect to tying these
signals to the end goal of the user somehow.  Extending this to take out
the alternative: ... moving these signals further away from being
descriptions of what the underlying technology is saying. 
	
	While I've moved to the two topics of "signals" and
"technology", I think we should consider there are distinctions there
and this group likely will discuss areas of both. 
	
	There are the underlying communications paths, and what flows
over them.  Here, we MAY wind up recommending additional information or
formats of things to flow back and forth to make life easier either for
the human or the program(s) on either end (or even in between). 
	
	And there is the human <-> program interface.  Here, at least
for me, I only have 5 senses ... and I'm not planning on getting any
computer-neurological implants anytime soon, so I won't consider that as
an additional method of interaction for now.  So somehow, between sight,
smell, touch, hearing, and taste, we have to convey this information.
Sight and sound seem the primary mechanisms these days at least. 
	
	I wonder if there is a third area of discussion around
"independent analysis" of various elements used in the communication as
well (a rudimentary form of this is accomplished by using tools from
different sources of my independent choosing so as to not be susceptible
in some way - I having to "trust" of course that said different sources
weren't colluding in some way). 
	
	Regards, 
	Tim Hahn
	
	Internet: hahnt@us.ibm.com
	Internal: Timothy Hahn/Durham/IBM@IBMUS
	phone: 919.224.1565     tie-line: 8/687.1565
	fax: 919.224.2530
	
	
	
	
Mike Beltzner <beltzner@mozilla.com> 

11/01/06 12:19 PM 

To
"Hallam-Baker, Phillip" <pbaker@verisign.com> 
cc
Timothy Hahn/Durham/IBM@IBMUS, <public-wsc-wg@w3c.org> 
Subject
Artifacts and clutter (was: "Greetings")

	




	On 31-Oct-06, at 10:10 AM, Hahn, Timothy wrote:
	
	> I have been somewhat frustrated by the various "artifacts"
which  
	> different HTTP clients/browsers use to convey whatever
security- 
	> related information has been sent from HTTP servers to which
the  
	> browser is connected.  The current state-of-the-art seems to
be  
	> more annoying to users than informative, and even for security

	> professionals can be confusing to interpret.
	
	As a representative from one of the browser vendors, I'm very  
	interested in working towards creating a reliable and consistent
user- 
	centric language with which we can convey signals of safety or
non- 
	safety (my preference is for the latter, actually) to people
using  
	our web browsers. I'm pretty staunch in my belief that users are

	willing and able to understand these signals, as long as they're

	directly related to the end-goal that they are attempting to
achieve,  
	and not seen, as you say, as "annoying" or otherwise
interruptive.
	
	On 31-Oct-06, at 12:28 PM, Hallam-Baker, Phillip wrote:
	
	> We need to have a clear distinction between control and data.
Users  
	> should be able to trust the browser to display content in the

	> content window and restrict the chrome area to data that is  
	> trustworthy.
	
	As George Staikos is so keen to point out, though, it's pretty
easy  
	for websites to spoof that chrome area itself and make
themselves  
	look authentic. By and large I agree with you, but am not
exactly  
	sure how we can do this in a way that isn't itself spoofable.
	
	This is, fwiw, why I prefer signals of non-safety over signals
of  
	safety. Any indication of "this is good" invites spoofing.
Indicators  
	of "this is not good" can be spoofed just as easily, but there's
no  
	benefit to doing so.
	
	cheers,
	mike