- From: Close, Tyler J. <tyler.close@hp.com>
- Date: Wed, 29 Aug 2007 16:55:01 -0000
- To: "Ian Fette" <ifette@google.com>
- Cc: <public-wsc-wg@w3.org>
- Message-ID: <08CA2245AFCF444DB3AC415E47CC40AFE4B291@G3W0072.americas.hpqcorp.net>
Hi Ian,
I assure you that I also think minimizing the burden on the user is
crucial, both to the usability of the web user agent as a whole and to
the effectiveness of the proposed security mechanism. After all, if the
secure interaction is too much of a burden, the user will find some
other way to get their work done, which will likely be less secure. To
this end, I have put a lot of effort into minimizing the user effort
required to use the PII bar. I would certainly like to make it even
better in this respect, if possible. If there are particular sequences
that you think can be further optimized, please point them out.
My reading-between-the-lines guess is that some of your concern is the
result of me being very detailed in my description of some of the use
cases. For example, see:
http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-usecases-p
lain
I documented this level of detail in the hopes of spurring a similarly
detailed review of the particulars of the proposal. I suspect this
detail has made it harder to see how lightweight actual interactions
will be. For example, I suspect a common login scenario will be:
1. User navigates to login page.
- The login page autofills the username field, using a persistent
cookie, and positions the keyboard focus in the password field.
2. User hits the down arrow key.
- The PII bar moves the keyboard focus to a list of PII strings,
with the focus possibly already on the password, based on seeing that
the to-be-filled text field is a password text field.
3. User hits the 'Enter' key.
- The PII bar copies the selected password to the password field.
The login page reacts to the pasted text by submitting the login form.
So, for the normal login, the user does 2 keypresses. I think this is
far from a burden and is in fact quite pleasant and usable. I'd
certainly be interested in discussing further optimizations though.
I'll pick up the other points you raise in your email in separate
responses. Thanks for taking an interest.
--Tyler
________________________________
From: Ian Fette [mailto:ifette@google.com]
Sent: Tuesday, August 28, 2007 5:09 PM
To: Close, Tyler J.
Cc: public-wsc-wg@w3.org
Subject: Re: PII Editor Bar & Trusted Browser Component
I know we're planning to do usability studies on all sorts of things,
but I am going to bring this up at tomorrow's meeting and ideally I'd
like to get over the "But studies show X" responses that I feel are
inevitable around these topics.
So, with that said:
Can anyone point me to the relevant papers that show
a) Just how much of a burden this is
b) That users will actually figure out that there is a problem when
they're being told to enter their username/password into some Flash
movie ( i.e. the formfiller is never triggered so PIIbar doesn't get to
show any warnings)
c) Resiliency against spoofing (i.e. if I just guess that "paypal" is
probably reasonable pii text for paypal.com and show that in a spoofed
display to the user, is the user actually going to notice that this is
not their pii text (assuming that they chose something different)
My biggest concern is that we seem to be on a warpath to say "X provides
protection because study Y shows a statistically significant difference
under some set of controls for some task", while not really trying to
quantify the burden on users and figuring out whether a) this is
acceptable under real usage b) How much dollars lost this burden
translates into and c) whether these dollars lost from b are actually
worth it. I.e. just because some users perform better in a lab study on
some task doesn't necessarily translate (for me) to "We should impose
this burden on people, which will probably result in a non-negligible
number of transactions being aborted due to user frustration, all in the
name of some marginal improvement that can still be spoofed and really
hasn't been tested to scale yet."
That's my fear, I will q+ already for tomorrow's meeting, but ideally I
wanted to get some of it out of the way ahead of time.
-Ian
On 8/28/07, Close, Tyler J. <tyler.close@hp.com> wrote:
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
<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
<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 Wednesday, 29 August 2007 16:55:37 UTC