belated remarks on PII Bar

Tyler,

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.

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.

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

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

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

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

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

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

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

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

Alternative proposal, for the sake of argument:

* We focus on login interactions only.

* If one occurs which is known, the login screen is replaced by an
  overlay as soon as the user interacts with one of the
  login-related form fields.  In this overlay, the user can select
  which set of previously used credentials he wants to use.  The
  overlay then auto-submits that set of credentials.

  Are more modest form might be a non-modal indicator that tells the
  user "we have been here before, please push F13 for help", F13
  being a key that is shielded from DOM, and launches the overlay.

  If the user pushes "F13" and there's no credentials, tell the
  user, and use the "here's stuff you've visited before" hook.

* The overlay also includes an option to go back to the web site to
  enter new credentials, and store these.

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

Received on Wednesday, 12 September 2007 14:42:19 UTC