RE: PII Editor Bar & Trusted Browser Component

I've collected together some links and more comments to help out with
tomorrow's Agenda item: "8. PII Editor Bar" [1].

Many of the questions in TLR's first pass [2] over the PII bar were
covered in last week's telecon, as well as in my response to Rachna's
first pass [3]. I suggest looking over this response, in addition to
reading the proposal itself again [5]. In particular, there's been some
confusion over secure attention keys, like the Windows CTRL-ALT-DEL
sequence. The PII bar *does not* require a secure attention key. If
someone could point to the text that is causing this confusion, that
would help.

In TLR's email [2], he wondered about providing a secure data entry
interaction for all sensitive data, as opposed to just special casing
username/password data. I think our charter and our use-cases require
providing protection for a broad range of PII data, such as credit card
numbers, social security numbers, phone numbers, etc. Moreover, I don't
seen anything to be gained at this stage from focusing only on login
forms. I believe the proposed form filler changes can be made just as
usable as any password-only manager that can be deployed on today's Web.

TLR's email also supposed that both proposals "get most of their
protection out of the
user's lossy memory". I think both proposals actually get most of their
protection from the data entry interaction, not on any reliance on the
user's not remembering sensitive data. I agree there is useful
protection to be had from freeing the user from the task of remembering
passwords, and that both proposals enable this.

I think the remaining parts of TLR's email need to be presented in more
detail to be effectively examined. Thomas, what do you think about
phrasing some of your questions in terms of our use-cases [6]? For
example, picking one that you think reveals a shortcoming and
pinpointing the exact moment where the user may be tempted to follow a
detrimental course.

--Tyler

--
[1] "Agenda: WSC WG weekly 2007-08-29"
 
<http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0157.html>

[2] "PII Editor Bar & Trusted Browser Component from Thomas Roessler on
2007-08-16 (public-wsc-wg@w3.org from August 2007)"
 
<http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0127.html>

[3] "Rachna's first cut at a usability analysis of PII bar"
 
<http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFirstC
ut#head-19caf4993d486f3f77f40171acc200d22fbf016e>

[4] "RE: first cut usability walk through from Close, Tyler J. on
2007-08-06 (public-wsc-wg@w3.org from August 2007)"
 
<http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0029.html>

[5] "Personally Identifiable Information (PII) Bar"
    <http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor>

[6] "Note - use cases"
    <http://www.w3.org/2006/WSC/drafts/note/#scenarios>

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Thomas Roessler
Sent: Thursday, August 16, 2007 10:19 AM
To: public-wsc-wg@w3.org
Subject: PII Editor Bar & Trusted Browser Component


I'm reading through the latest state of the PII Editor Bar proposal,
and also the Trusted Browser Component proposal again.

  http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor
  http://www.w3.org/2006/WSC/wiki/TrustedBrowserComponent

There are a number of differences on a detailed level -- e.g.,
petnames vs generic shared secrets, and some stuff like that.

I *think* the one significant difference between the two is that PII
Editor Bar proposes a different interaction ritual for generic
forms, and requires significant customization (i.e., the "data
entry" task is redesigned), while the Trusted Browser Component
seems to focus on a single high-level task ("login to XXX") and
introduces a new (possibly simpler?) user interaction for that more
narrow task.

Both proposals seem to get most of their protection out of the
user's lossy memory (if people don't remember passwords, they won't
easily hand them over), and the broken interaction flow when people
log in to an unkown site that they think is the one they were at
before.

Both proposals include some social engineering to steer users toward
a site they've dealt with before in certain failure cases, by making
it easy for them to find out about "existing relations" during the
interaction that would lead to data entry with the site they
currently deal with (and caching of that data / passwod).  I like
that part, and would love to see some empirics on the effect.

PII Editor Bar gets a second level of protection out of a
petname-like UI paradigm; the Trusted Browser Component assumes that
some kind of shared secret has been established to create a trusted
path to the user.  Mentally going through possible scenarios, I'm
suspecting that this particular element of the respective proposals
is the weakest one.

As we move forward, I would like to see both concepts -- the generic
form filler, and the task-specific approach -- tried out and
analyzed.  I have a gut feeling that the task-specific approach that
the Trusted Browser Component suggests might have larger chances for
deployment and user acceptance, based on ease of use when people log
in to sites.

It might in this context be worth looking at the difference between
approaches that (a) require a secure attention key, (b) require a
secure attention key and tell the user about it ("to login to XXX,
please push blah", maybe in one of the nice yellow
chrome-overlapping bars), and (c) don't require a secure attention
key, but simply replace the login interaction.

(Example: PII bar seems to require that a secure attention key be
pressed for every single form field.  TBC seems to only require some
specific interaction to either put a session into a specific mode,
or maybe to effect a login transaction.)

Additionally, it might be an interesting exercise to abstract one
step further, and beyond documenting the specific approach that
comes out useful as a secure data entry ceremony, also write up some
general requirements for secure, interactive credential selection
and/or login processes.

Thoughts?
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Tuesday, 28 August 2007 21:31:57 UTC