Re: belated remarks on PII Bar

Am I missing something here? Because my keyboard doesn't have F13....
or was that just a placeholder for "some key TBD"?

On 9/12/07, Thomas Roessler <tlr@w3.org> wrote:
>
> 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:49:37 UTC