Re: belated remarks on PII Bar

On 2007-09-18 00:34:02 -0000, Close, Tyler J. wrote:

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

An example in point against this would be what key is being pressed
to invoke the form filler.  Strikes me as totally implementation
dependent; actually, it's probably more critical that this
experience be consistent with the platform around the user agent
than that it be consistent across browsers.

Also, note that things might simply be unspecified even if you need
to decide them in prototyping; a prototype can then either exercise
multiple of the choices possible, or just one. If exercising that
choice turns out to have security-critical effects, that means that
it should actually be made in the spec.

However, it's not at all self-evident that every little piece must
be specified.

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

The more I think about this, the more it strikes me that the origin
aspect might be problematic for personal information beyond
credentials.  Often, being able to quickly get information that I
had entered elsewhere is *precisely* what makes a form filler
interesting and valuable.

The distinction here is between information that is likely to be
presented to multiple sites (quite a bit, actually) and information
that should not be presented to multiple sites (credentials).  

It's not at all obvious that we even need to be pursuing the same
protection goals.  Also, the usability cost of a PII bar like
proposal is likely to be different for these two scenarios.

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

Interesting point, but probably not one we need to settle now.

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

Seeing that you are not adding anything further here, I take it that
my list covers the most critical aspects of your proposal.

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

For example, I might be asking for the weather in a location that
I've asked about before, but haven't bookmarked.  Very special
indeed.

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

Well, part of the merit of a form filler as it exists today is that
it comes to my help if it can, but doesn't get into my way.  I
typically don't remember what information I have given before, so
the perverse scenario with multiple changes of focus might indeed
occur.  Anyway, let's agree to disgaree on that one for the moment.

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

I'm not asking anything here; just observing that there's an
additional angle that we need to consider.

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

Well, if PII bar was used, that effect would only be noticed *after*
the user has started to enter material into that field. Strikes me
as an example where PII bar would actually be able to succeed, if
the user is indeed as habituated as you suggest.

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

The trouble with that argument is that we're in the middle of a
balancing act of (a) giving users more secure interactions, and (b)
making sure we don't screw up convenience.  "Avoid if possible"
isn't enough of a reason.

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

1. How does it fit in our scope?

2. WHOIS data accuracy is a headache for anybody who has tried to
   rely on it in a significant way.  Attempts to increase accuracy
   of whois data have typically caused significant policy concerns,
   and often led to unimplementable approaches.

3. The traditional WHOIS protocol is horribly underspecified (to the
   extent of being unspecified), and the attempts to deploy a
   replacement protocol have been less than successful, as far as I
   know.  (But my knowledge there might be outdated.)

4. E-Mail addresses given in WHOIS are typically not intended to
   deal with Web site related problems.

5. Automated processes are indeed against the terms of use that
   every registrar MUST impose, as Ian points out.

6. Assuming your suggestion was implemented and deployed, there
   would be a high likelihood that *many* messages are sent to the
   relevant address.  That's an undesirable effect by itself.

In summary, this is a positively bad idea overall, and it's an even
worse idea for this group to propose.

> At the very least, I think important distinctions and pitfalls
> must be documented.

I agree that important distinctions and pitfalls must be documented
and should be part of what's recommended.  I do not agree that every
ancillary feature (such as the history editing feature) should be
pursued further.

Cheers,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Sunday, 23 September 2007 08:22:53 UTC