RE: belated remarks on PII Bar

 

Thomas Roessler wrote:
> you asked toward the end of the last call what my issue was with the
> current text on the PII Bar proposal.  It took me a while to figure
> that out, but actually, I think it's the amount of detail with which
> the implementation of a form filler is described.  That blurs the
> additions to form-filling very heavily.

Perhaps a more layered description would be better. I think all the
details do eventually need to be presented, since I think all the detail
I included has security implications. These details will also be needed
for lo-fi prototyping.

> I *think* the key points where the proposal deviates most from
> current practice are these:
> 
> * form filling is partially tied to a particular "origin", so there
>   is no autocompletion if site A happens to ask for your SSN the
>   same way site B does that.  There is, however, the possibility to
>   select a string interactively that hasn't been shown to site A,
>   but might previously only have been shown to site B.  This
>   selection would have a user interaction different from the
>   autocompletion one.
> 
> * The "origin" includes whether a site is secure or not; more
>   precisely, it is currently suggested to have no form filling at
>   all if a page is served through plain HTTP.  For HTTPS, the
>   "origin" is expressed in terms of the X.509 certificate used.

This distinction also provides a different interaction for submitting
information securely versus not securely. With the proposed division we
have the simple rule that information submitted via the PII bar was
submitted securely, but information entered into the web page may not
have been. We have a number of use cases around making this distinction
clearer for users.

> 
> * if a user is at a site that they haven't been to before, and if
>   the user behaves as if they want to use the form-filler, then
>   that's used as a hook to ask the user to (a) give that site a
>   nick-name, and (b) give the user a way to navigate using their
>   browsing history.

I think the way the browser walks the user through this workflow is also
important, providing reasonable options and explaining how to choose
between them. Full screen messaging, like Serge has had success with,
should also be used here. 

> * for visual user agents, the data entry widget is next to a
>   passive, identity signal like indicator, to move the user's locus
>   of attention to this signal.

Unlike all other identity signals, the petname tool is robust against
homograph and similar attacks.

> * there must be explicit user approval of kinds before information
>   is filled into form fields and transmitted.

I think this explicit user approval, and other aspects of the
presentation, also help create a distinction of user agent versus web
site that browsers have thus far failed to create. Current form fillers
make it look like the web site already knows the filled field values.
For example, even during our telecon, I noticed cases where people were
talking about current form filler use cases that in fact, aren't the
form filler at all, but functionality provided by the web site.
Currently, even experts can't tell when they're using their browser's
form filler versus functionality built into the web page.

> * there are "display names" for passwords.  Passwords and user names
>   seem to be handled independently of each other.
> 
> * there is an idea in here on handling TLS errors, and generating
>   e-mail to abuse addresses from WHOIS records. I believe that would
>   belong elsewhere in the document.
> 
> * there is a remark about the minimum features to expose to users in
>   terms of editing form strings.
> 
> Some comments / observations:
> 
> * There seems to be a critical assumption in here that people will
>   be *so* habituated that they will press the "attention key" to
>   trigger the rest of the interaction, even though they need to deal
>   with each form field separately.  Is that really warranted?

Testing will settle this question. I'll only note that I'm not just
banking on habituation, but also laziness. It's easier to click on your
password than remember it and type it in correctly.
 
>   Also, does the separation of form fields get into the way of
>   "habituation"?  I'd suspect that a very simple interaction in
>   which I succeed with, ideally, one or two key presses will be
>   easier to learn (and lead to a stronger irritant) than an
>   interaction in which I'm navigating all over the side, and
>   constantly have my locus of attention changed.

If a web site is asking the user to reenter information that the user
has already given it, something special might be happening. For example,
the site might be asking for permission to use the information in a new
way. I think we need to think hard about subverting this interaction by
automating the user's response.

I think the perverse scenario you imagine in the above paragraph could
turn out to be rather rare.

Also, repetition is what creates habituation.

> * "Explicit user approval before filling" -- filling the forms
>   includes generating DOM events.

Not sure what you're asking here.

> * Since HTML forms have a mechanism (type="password") to indicate
>   that some content shouldn't be displayed on the screen, we'd
>   probably want to mention that as well.

I'm really nervous about doing any introspection on the document. I'm
worried the phisher will be able to construct a document that makes it
look like the PII bar is malfunctioning, and so convince the user to act
against the advice of the PII bar. For example, for the case you
suggest, the phisher could make a text field that displays "*"
characters, using Javascript, and so seems to be a password field, but
is not treated as one by the PII bar.

Another principle carefully adhered to by the PII bar is to be very
careful about knowing the source of information you're acting on, or
displaying to the user. Changing how the tool behaves based on
information provided by the phisher is dangerous. Places where such a
dependency exists must be carefully examined, and avoided if possible.

> * On the WHOIS-related part, don't do it.  WHOIS is a complete and
>   utter mess.  (And you don't want me to even start telling you the
>   long story about that.)

Why does that matter? All we're doing is sending up a flare to say
something is wrong. No harm done if no one sees the flare, we're no
worse off.

> * On the minimum features to edit the local history, I wonder how
>   much of this can be safely left to implementers.  I suspect most.

I'm skeptical. To date, browser implementers haven't shown good
judgment, or we wouldn't be here now. At the very least, I think
important distinctions and pitfalls must be documented.

> Alternative proposal, for the sake of argument:
> 
> * We focus on login interactions only.

I'm not interested in pursuing such a proposal. I'll be putting my
effort into prototyping a solution that also protects credit card
numbers and other security-sensitive identifiers. Perhaps we'll revisit
this issue if early testing shows this goal to be less achievable than I
hope it is.

Thanks the feedback.

--Tyler

Received on Tuesday, 18 September 2007 00:35:56 UTC