usability claims and issues for potential testing of petnames

This email fulfills ACTION-476, which asks for a summary of petnames from the perspective of usability testing.

=General issues with any proposal=

1. The basic issue of whether the user can understand what the tool does and how to interact with it.

=Issues with passive indicators=

I expect the known issues with passive indicators in the chrome will also apply to the Petname Tool. I don't see any need to retest these. I think we should have a section in the spec that outlines the expected vulnerabilities of all the proposed passive indicators. This section should include:
   1. a note that these tools are vulnerable to a picture-in-picture attack
   2. a note that these tools will have difficulty getting the user's attention during an attack

In both cases, it's possible these tools can be paired with another that addresses these issues; such as a user specific tartan for the chrome that provides a picture-in-picture defense.

=Issues specific to the Petname Tool=

1. Will the user see enough value in the tool to assign a petname to a trusted site.
   Q1. Under what circumtances does the user see value in assigning a petname?
2. There are several issues to check around assignment of a petname:
    A. User visits a phishing site, which pretends to be a site the user *has* petnamed:
        i. User attempts to assign a new petname
            Q2. Is the new petname similar enough to the existing petname that the implementation can detect the collision and alert the user? How does the user react to this alert?
        ii. User looks at the list of existing petnames
            Q3. Can the user find the existing petname? What does the user do if they find it?
    B. User visits a phishing site, which pretends to be a site the user has a relationship with, but *has not* petnamed.
        i. User attempts to assign a petname
            Q4. Did the existence of the petname tool affect the chances of the user falling for the attack?
    C. User visits legitimate site, but has not assigned a petname yet.
        i. User attempts to assign a petname
            Q5. How much difficulty does the user have in selecting a petname?
    D. User visits a legitimate site, but has assigned a petname to a phishing site.
        i. User attempts to assign a petname
            Q6. Is the new petname similar enough to the existing petname that the implementation can detect the collision and alert the user? How does the user react to this alert?
        ii. User looks at the list of existing petnames
            Q7. Can the user find the existing petname? What does the user do if they find it?
3. There are several issues to check around viewing of an assigned petname:
    Q8. How easily can the user distinguish between the case where the site has an assigned petname versus the case where the site does not have an assigned petname?
    Q9. How easily can the user distinguish between their chosen petnames? If one petnamed site began masquerading as another petnamed site, would the user notice that the displayed petname is a mismatch?

That's what I've got for now.

I'll be away for next week's telecon, but expect to be present for the following one.

--Tyler

"ACTION-476"
<http://www.w3.org/2006/WSC/track/actions/476>

"Petnames"
<http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-petnames>

Received on Friday, 23 May 2008 23:55:12 UTC