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

Hi Phillip,
 
Given that you recognize that "the traditional padlock security
interface establishes an expectation of security that is not met", I
wonder why you go on to propose a model in which you state in advance
that the expectations cannot be met: "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". The EV certificate study that Thomas
linked to also studies the IE7 Phishing Filter and finds that users are
made more vulnerable to attacks not flagged by the filter. Given that
phishers can test their attacks in advance against the filter, I expect
this to be a serious flaw.
 
Perhaps we would be better off starting with a goal that is achievable.
For example, we could aim to provide a distinction of "acquaintance"
versus "stranger"; does the user have a relationship with the web site,
or no relationship. This distinction need not be guessed at, but can
instead be directly determined, given the appropriate user interface.
Classifying the world into good and bad is hard. Keeping track of who
you know is easier. The latter distinction can also be implemented
without concern for how you arrived at the web page, making the case
analysis smaller.
 
Tyler

________________________________

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