ISSUE-111 (Re: belated remarks on PII Bar)

The proposed alternative to the editor bar that I was
mentioning on the call today is in the message below, under
"Alternative proposal, for the sake of argument".

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







On 2007-09-12 16:42:14 +0200, Thomas Roessler wrote:
> From: Thomas Roessler <tlr@w3.org>
> To: tyler.close@hp.com
> Cc: public-wsc-wg@w3.org
> Date: Wed, 12 Sep 2007 16:42:14 +0200
> Subject: belated remarks on PII Bar
> X-Spam-Level: 
> 
> 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, 28 November 2007 16:36:05 UTC