Re: Note Section - Design Principles

I'm not quite sure I agree with many of the "Characteristics of the 
Average User".  Being the IT person for friends and family, most of 
those users do care about the security dialogs and it isn't uncommon to 
get a phone call saying "What do I do with this, am I at risk?" 

I also worry that the "Characteristics of the Average User" as described 
below could lead us into the trap of modeling a user as "dumb".  Our 
experience at Tellme has been that users are not dumb, but systems are 
often notoriously bad at communicating, and they're often especially bad 
if they treat the user at a kindergarten level.  Instead, we tend to 
follow a design pattern that assumes the user is a capable, intelligent 
adult, but the burden is on the system to communicate effectively.

I have some suggested amendments below. 

Maritza Johnson wrote:
> A list of design principles extracted from the shared bookmarks in the 
> wiki.
>
> General Design Principles:
>
> - Dialogues should not contain information which is irrelevant or 
> rarely needed.
> - The user should be able to conveniently access more information as 
> required by their level of experience.
> - The cues should be displayed consistently in location and across 
> sites and browsers in an attempt to prevent spoofing and confusion of 
> the user.
> - False positive warnings rapidly dilute warning usability.
> - False positives and negatives should be kept to a minimum to avoid 
> degrading the user's level of confidence in the security cue.
> - The system should speak the user's language, with words, phrases and 
> concepts familiar to the user, rather than system-oriented terms. 
> Follow real-world conventions, making information appear in a natural 
> and logical order.
> - Provide explanations, justifying the advice or information given.
> - Integrated security aligns security with user actions and tasks so 
> that the most common tasks and repetitive actions are secure by 
> default. Provides information about security state and context in a 
> form that is useful and understandable to the user, in a non-obtrusive 
> fashion.
> - When possible, safe staging should be used. Safe staging is "a user 
> interface design that allows the user freedom to decide when to 
> progress to the next stage, and encourages progression by establishing 
> a context in which it is a conceptually attractive path of least 
> resistance."
> - Metaphor tailoring starts with a conceptual model specification of 
> the security related functionality, enumerates the risks of usability 
> failures in that model, and uses those risks to explicitly drive 
> visual metaphors.
> - If a feature or cue is included in the design with the intention of 
> improving some aspect of usability (learnability, better functionality 
> through more information ...) it must be clear to the user the feature 
> is available, and the action or process expected of the user must be 
> clear by the way the feature is presented.
> - The visual cues presented to the user must represent the 
> state/action of the system in a way that is consistent with the actual 
> state/action of the system to allow the user to create an accurate 
> conceptual model.
> - The user must be aware of the task they are to perform.
> - The user must be able to figure out how to perform the task.
> - The user should be given feedback when the state of the security of 
> a page is changed.
>
>
> Characteristics of the average user (is this what was meat by the 
> assumptions section?)
I would call this the "naive user" instead of the "average user".
>
> - Security is always a secondary goal, it is never the main focus of a 
> user.
"Users are typically task-driven and security is a secondary consideration."
> - Users lack the knowledge that would help them make security 
> decisions on the internet. This includes being unaware of security 
> protocols and concepts, the meaning of current security cues, and the 
> difference between the web content and the browser chrome.
In my experience, most naive users can differentiate web content from 
browser chrome and in many cases do understand the very high-level 
concepts but not the mechanisms.  My friends and family typically 
understand that a certificate is something provided by a site stating 
that it is who it says it is.  They typically understand that encrypted 
means the data is not easily read by someone else.  They don't typically 
understanding public-key, private-key, trust-networks, signing 
authorities, etc.  I might say:

"Users can make analogies to real-world concepts, but are typically 
unfamiliar with the detailed mechanisms involved in implementing web 
security."
> - A user has only a single locus of attention, a feature or an object 
> in the physical world or an idea about which you are intently and 
> actively thinking
> - Users can be visually deceived.
> - Users have bounded attention.
> - Users ignore warning signs, or reason them away.
This hasn't been my experience given the number of calls I've answered 
saying "Is this OK?  What do I do?".  I think the current security 
dialog approach has trained people to do this, but I don't think it is 
the default behavior. 
> - Users rely on the content of a web page to make security decisions. 
> - Users ignore warning signs, or reason them away.
(Duplicate)
>
> Can anyone think of any I've left out? Any suggestions for modifying 
> the ones listed?
I think the other thing I would try to add is that typically if a site 
is violating a security principle (cross-posting form data, including 
HTTP and HTTPS frames on the same page, transitioning from HTTPS to 
HTTP, presenting an expired certificate, presenting an unsigned 
certificate) the user is unempowered to do anything about it.  If a 
valid site is doing something insecure, the user has little recourse.  
How do I complain to E*TRADE, Fedex, AOL that their site is presenting 
me a security warning?  So the user has only two choices:  1)  Proceed 
anyways  2) Don't use their services until it is fixed (which might mean 
never use their services).

Maybe:

- Users are unempowered to request that a site fix its security problems 
and therefore are forced to decide whether to take the risk in order to 
complete the task

--Brad
>
> - Maritza
>
> http://www.cs.columbia.edu/~maritzaj/ 
> <http://www.cs.columbia.edu/%7Emaritzaj/>
>
>