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