RE: ACTION-69 Differential Use Case Analysis on User Expectations

I like the approach outlined below but it doesn't define what it means
by "this page is secure" nor "action is safe" versus "action is unsafe".
It implies that "secure" and "safe" equate to something allowing a user
to "correctly and reliably differentiate a legitimate site from a fake
site" (site authenticity).
 
As we've discussed before, there is reason to believe site authenticity
is only one of at least four aspects of web site security that users ask
about:

> A. Can eavesdroppers read my session?
> B. Is the web site really the one I requested?
> C. Have the web pages I'm seeing been tampered with?
> D. Is the web site reputable?

Today's padlock is a fairly good predictor of A and to a lesser extent
B.  But as we discussed on the Jan 16. call, many users mistakenly
believe the padlock is a predictor of D.

________________________________

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, January 22, 2007 3:38 PM
To: public-wsc-wg@w3.org
Subject: ACTION-69 Differential Use Case Analysis on User Expectations


One of the principal problems we face is that the traditional padlock
security interface establishes an expectation of security that is not
met. The padlock icon tells the user 'this page is secure', its real
semantics are 'this page was retrieved fvia an encrypted channel'.
 
Throughout we have been attempting to apply traditional use case type
techniques that are designed to allow assement of functionality. We and
others have arrived at a de facto modification of this approach that
allows it to be applied to security issues. In this note I am attempting
to formalize that which we do already.
 
 
Differential use case analysis of usage scenarios.
 
The objective of applying usability enginering to the security user
interface is to allow the user to correctly and reliably differentiate a
legitimate site from a fake site established by an attacker. We do this
by defining sets of use cases and abuse cases. 
 
The response to a use/abuse case may be one of three possible values:

1.	Afirmation that the action is safe 
2.	Warning that the action is unsafe 
3.	Netural: neither warning nor affirmation given

In each case we want to maximize the number of correctly assigned
Affirmations, Warnings while minimizing the number of Warnings presented
in safe cases and never providing an affirmation in an abuse case.
 
First we define the user situations in which the user response is to be
evaluated:

1.	Inexperienced user using the technology for the first time 
2.	Experienced user who uses the technology on a frequent (e.g.
daily) basis for an extended period of time 
3.	User who is being assisted by customer support

Next we define our task situations:

1.	User types in a naked domain name into the address bar
(www.example.com) 
2.	User types in a domain name prefixed by a secure protocol
(https://www.example.com) 
3.	User follows a link from a site via unsecured http 
4.	User follows a link from a site via http secured by SSL with a
domain validated certificate 
5.	User follows a link from a site via http secured by SSL with an
Extended Validation certificate 
6.	User follows a link from an unsigned email 
7.	User follows a link from an email that is signed by a party
considered to be trustworthy

In cases 2, 4, 5, 7 it might be considered that there is an expectation
of security on the part of the user. 
 
In each case we have a use case and a matching abuse case. The use case
being that the user is directed to a legitimate site, the abuse case
being that the user is directed to an illegitimate site.

Received on Tuesday, 23 January 2007 16:52:15 UTC