Re: Measuring and optimizing user effort (Was: PII Editor Bar & Trusted Browser Component)

I still have some concerns. My biggest ones are as follows (with respect to
burden). The biggest one is quite simple - I don't see why the user has to
do a ritual for each field (click in the field, choose the text, click in
the next field, choose their stored pii text). Why can't the entire form be
filled out? Why does the user have to do something for each field?

Secondly, just as something I didn't understand, 2.4.4.3 Imposter Attack on
Plain Scenario, I didn't understand why the login was interrupted at "step
6", i.e. when they hit the password field. Why was it that the username was
able to be filled out properly? (The second paragraph, a more advanced
attack). Are you saying that an attacker gets Alice to enter her username on
a site for some other reason, and then changes that page that she's at to
somehow be a different attack? It wasn't quite clear to me what was
happening here.

Third, with respect to burden, a huge concern of mine was "The PII bar must
be the only form filling feature of the user agent." If someone dislikes PII
bar, finds it burdensome, whatever, and wants to turn it off, I don't see
why a UA should be prevented from doing so. (It sounds like offering a
PII-bar-less version would be against this though). You also say that PII
bar MUST NOT be enabled for exchanges not protected by SSL - does that mean
that the UA can have no form filler for non-ssl pages? Cause that would also
suck :(

-Ian

On 8/29/07, Close, Tyler J. <tyler.close@hp.com> wrote:
>
>  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 theeffectiveness
> 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 theresult
> 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-plain
>
> 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. Thelogin 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 toget 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 toquantify
> 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>
> >
> > [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>
> >
> >
> >
>