Re: Non-form-filler users (Was: PII Editor Bar & Trusted Browser Component)

Hmm, this thread is getting massively forked. Oh well.

I think I just replied to this in a different fork of the thread, but I
really don't buy into the assertion that users are going to become
habituated enough that they refuse a different logon process out of
suspicion. That was the argument for SiteSecure - if you don't see your
image, or if you get prompted for your security question, you think
something is wrong and call your bank. Instead, I think my bank sucks and
screwed up somehow, and/or my cookie got lost, and/or my bank still sucks
and something else happened, but it happens with enough frequency that I do
not view it as a "problem" with the logon process, more just a problem with
my bank.

That, and the fact that if you really can get users to only use a trusted
method for filling authentication data, you can do all sorts of cool stuff
(crypto included) that would totally break current methods. I feel that if
it were really so simple (Users will get used to it and never use a
different input method) then we would see all sorts of new, more secure
login methods available and in use right now.

My $.02 (or 0,02€ as the case may be come Friday)

On 8/29/07, Close, Tyler J. <tyler.close@hp.com> wrote:
>
>  Hi Ian,
>
> I covered your point a) in:
>
> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0199.html
>
> I'm doing your point b) in this email.
>
> I think this is just something we are going to have to test. My hope is
> that once a user has become habituated to using the PII bar, they will be
> annoyed at being asked to manually type in their username and password, and
> so will be disinclined to submit to the Flash Movie's request. I am hoping
> that the user will instead click on the Contacts button in the PII bar and
> select the link for the site they intend to visit. The user can then login
> using the normal 2 keypress method.
>
> --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>
> >
> > [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>
> >
> >
> >
>