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

On 1-Nov-06, at 1:50 PM, Timothy Hahn wrote:

> Please don't take my comments the wrong way here.

Oh, I didn't think that I did. I was agreeing with you, Tim :) Right  
now all the existing browser indications of security are pretty  
godawful. If we don't bore users to death with meaningless dialogs in  
cases that don't really need them (like going from a secure to  
insecure page) then we barrage them with all sorts of techno-centric  
overloaded terminology (like "encrypted" and "signed") and then ask  
them to click between a choice that basically looks like "Do the  
thing I just asked you to do" or "Get scared, and don't do that thing!"

> 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.

It's been a lazy way to do the UI design, as Philip points out in his  
other thread, and one that simply punts the decision to the user  
without giving them any actual help or information that's useful in  
making that decision.

> 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.

Exactly right. I also think that it's important that we use  
consistent terminology in this effort. We can do our best to bring it  
into a user-centric language, but that language must itself be  
consistent so that the web user audience can build up ideas of what  
"foo" or "baz" means in real-world terms.

> 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).

This moves into network-of-trust style approaches which have been  
examined and found to be useful to varying degrees. I think there's  
additional contextual information that a browser has, though, which  
it never operates on:

  - has the user been here before?
  - have they conducted some sort of secure transaction here before?
  - has the user been to someplace similar but not identical?
  - can the browser encrypt or otherwise strengthen the content being  
submitted by the user to limit the potential risk of having that  
information stolen?

cheers,
mike

Received on Wednesday, 1 November 2006 19:34:27 UTC