RE: ACTION-182 - SSL error anti patterns

I like all these. They each need more explanation, and some examples. 

1. Use of technical jargon containing terms with which the average 
layperson is not familiar.

That this level, this is a "no brainer". But of course, there must be 
reasons that this happens today. It's within our goals to lay out terms, 
indicators and metaphors that are usable. Can we start with some examples 
of technical jargon currently in use that is unfamiliar to the average 
layperson? Here are some examples from your email:
*                What is a certificate?
*                What does CA mean?
*                What is a thumbprint?  Does it have something to do with 
my thumb?  Should place my thumb on my laptop's finger sensor?
*                What does SHA1 stand for?
*                How should I interpret the mysterious code 8FBF6185 
1D390508 F04BA0CB 31F4C4C E5310DAE?

Since it's about SSL, it's all about the PKI. Does anyone have any good 
ideas or references on what to do in this space? What about the use of PKI 
might a user understand? Identification and shielding/enveloping seem like 
the minimal set. Certificates are like identity cards. CAs are identity 
authorities. The thumbprint idea is a travesty; everyone ignores that (see 
Xia and Brustoloni for an alternative approach). 

What better messages do other browsers already have for?
"You are about to install a certificate from a CA claiming to represent 
www.x9.org.  Windows cannot validate that the certificate is actually from 
www.x9.org.  You should confirm its origin by contacting www.x9.org.  The 
following number will assist you in this process: Thumbprint (sha1): 
8FBF6185 1D390508 F04BA0CB 31F4C4C E5310DAE.
                 "Installing a certificate with an unconfirmed thumbprint 
is a security risk.  If you click Yes you acknowledge this risk.  Do you 
want to install this certificate?"

What better ideas do we have?

2. Providing a web site's URL as the only contact info for it. (creates 
"catch-22" dilemma for user)

I agree (again, see Xia and Brustolonig). What alternatives are currently 
available? I'm afraid I can't think of what that would be. 

3. Actions suggested can't really be carried out.

Or, turning it around, every error has instructions that are clear and 
actionable to the user. They tell the user exactly what to do. If they 
don't, then the user can't do it. They do not rely on the user having 
contextual knowledge (such as contact information or administrative help) 
that they may or may not have. 

Can anyone say more? I think I know what we mean by this, but I fear it's 
still abstract. 

4. Consequences or risks of user actions not explained.

Or, turning it around, primary or secondary information should explain the 
consequences and risks of both the user action recommended, and any others 
(like inaction). Is that clear enough?  Flinn and Stoyles,  in ?Omnivore: 
Risk Management Through Bidirectional Transparency?, have a good set of 
structuring questions for what information the user needs/wants:

What could go wrong?
How likely is it, and what damage would it cause to me or to others if it 
did?
How would I know if something went wrong?
What reason do I have to believe that it won?t?
Who is responsible to ensure that it doesn?t, and what recourse do I have 
if it does? 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




<michael.mccormick@wellsfargo.com> 
04/23/2007 06:41 PM

To
<Mary_Ellen_Zurko@notesdev.ibm.com>
cc
<public-wsc-wg@w3.org>
Subject
RE: ACTION-182






After review of the 4-4-07 minutes, it's clear to me now that I cannot 
satisfy ACTION-182 with the FSTC recommendations.  Nonetheless, Dan 
Schutzer has kindly agreed to submit the subset of FSTC's suggested 
browser enhancements that are most applicable to WSC.
 
It appears ACTION-182 stems from my Lightning Discussion on 4 April about 
the cryptic IE6 browser errors that I received when I encountered a 
self-signed SSL certificate at the www.x9.org web site.  According to my 
notes, as well as the official meeting notes from Thomas, we had a lively 
discussion about the security anti patterns implied by such browser error 
messages.  In particular I captured the following possible anti patterns 
in my notes:
 
1. Use of technical jargon containing terms with which the average 
layperson is not familiar.
2. Providing a web site's URL as the only contact info for it. (creates 
"catch-22" dilemma for user)
3. Actions suggested can't really be carried out.
4. Consequences or risks of user actions not explained.
 
These are the [anti-]recommendations I propose we adopt.  Anticipating 
comment, I haven't yet updated the wiki.  Cheers Mike