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

Hi Ian,

comments inline below...

Ian Fette wrote:
> 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?

So the process of moving between fields can be automated, as I pointed
out in my last email. The page can put the focus in the first field, and
move the focus to the next field, or submit the form, in response to the
pasted text. I've documented the user driven process so that it is clear
that the PII bar can still be used with pages that do nothing to improve
the usability of their forms.

I think it is important to engage the user in the process of granting
their PII to a web site. I think automatically giving PII data to a web
site is dangerous and confusing for the user. It's dangerous because the
user may not want to give the requested PII to the web site. It's
confusing because the UI makes it look like the web site already knows
your PII, since the display is the same as the one for a form with
pre-populated fields. I think this display also contributes to the
problem we have with users making no distinction between their user
agent and the visited web site. The user studies this WG has examined
have shown that users make no distinction between web page area and
chrome area. I think we need to change this perception if we're to get
users to trust messages from their user agent more than messages from a
web site. Making it clear that the user agent knows their PII, but the
web site doesn't yet, is a step in this direction.

> 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. 

The second attack in the "Imposter Attack on Plain Scenario" section
covers the case where the user has an account at both the legitimate
site and the attack site. The attack site may have initially posed as a
useful service, say a blog that requires a login. Later, the attack site
changes its web site to impersonate the victim site. A username is often
reused across sites, so the user's login habits aren't interrupted as
they fill out that field. It's only when they try to fill out the
password that they're interrupted, since the expected password is not
available (on the assumption that they've actually used different
passwords, but if they haven't, then the jig is already up, since the
attacker already has the password). I'm hoping that this disruption, as
well as the moving of their locus of attention to the PII bar, will be
enough for the user to cast a glance at the petname tool which shows the
user they are not at the legitimate site.

> 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.

Hopefully you can see why it would be confusing to have both the PII bar
and another form filler operating simultaneously. I think we can make
the PII bar work well enough that there won't be a need for another form
filler.

> (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?

Yes. Transferring PII in the clear is a bad idea, especially as wireless
connections become more prevalent. A form filler is really only useful
for entering frequently used identifiers and AFAICT, these are all PII. 

> Cause that would also suck :( 

Do you have some specific scenarios in mind?

Thanks,
Tyler

Received on Friday, 31 August 2007 22:01:06 UTC