[whatwg] A mechanism to improve form autofill

[Smylers]

Ian Hickson writes:

> On Thu, 15 Dec 2011, Ilya Sherman wrote:
> 
> > Also, I do not understand why we have credit cards types. Is anyone
> > willing to have his credit cards information saved locally?
> 
> Sure, why not?

I am too, but I can understand why people who share their computer (and
user accounts) with others wouldn't want their card numbers saving.

> > Is any website not using autocomplete=off as soon as credit cards
> > are involved?
> 
> Those that do that are incredibly annoying.

A site using autocomplete=off enables a distinction to be made between
sensitive and non-sensitive fields, for users who want such a
distinction.

For users who wish everything to be saved, a browser (or an extension)
could be configured to ignore autocomplete=off when it's present.

Not using autocomplete=off makes it impossible for the first group of
users to make their desired distinction. Using it still enables the
second group to have their desired behaviour, given an appropriately
configured browser.

The relevant part of the spec currently says that for autocomplete=off:

  the user agent should not remember the control's value, and should not
  offer past values to the user.

Could we turn those "should not"s into "may choose not to" or similar,
to indicate that there's nothing wrong with browsers offering users such
a feature? Or possibly to "must not ... unless the user has specifically
configured the user agent to enable remembering sensitive data"?

If there is to be an autocomplete type for payment card numbers then I
think that the restrictions on saving autocomplete=off values should
also apply to them. I suspect sites currently using autocomplete=off for
card numbers would be unwilling to switch to autocomplete=cc-number if
it meant all users card numbers would suddenly start being saved.

There may be users who are happy to have their long card number (which
they can't remember) saved but not their CSC (which is easier to
remember) or 3D Secure password. Maybe a browser could ask the first
time a user submits a card payment what they want saving.

Thinking specifically about payment card input, but more generally than
just autocomplete, these features would be useful as a user:

* When entering a new number, if I type or paste in spaces or hyphens
  they are stripped from the number submitted to the site.

* If the number doesn't pass the Luhn check digit algorithm, treat the
  field as invalid and refuse to submit the form until I've fixed it.

* Save the card type (Amex, Visa credit, Visa debit, etc) along with the
  other details. Not all sites ask for this, but a significant number do
  have a select box for it, and it's tedious to have to select each
  time.
  
  Unfortunately this is a 2-dimensional quantity. Some sites group all
  Visa cards together; others list Visa credit and Visa debit on
  separate lines; and some others don't care about the brand but want to
  distinguish between credit and debit cards, sometimes because the
  price charged to the customer differs between those two.

* For my browser to have multiple sets of card details stored, which I
  can pick from.

* For the browser only to fill in stored card details of types that are
  accepted. For example:

  » I prefer to pay with my credit card, but some sites only accept
    debit cards. So I'd like to have my credit card details stored and
    used on most sites, but the debit card details also stored and used
    on those that don't accept credit cards.

  » Some people prefer, say, Amex, but have a Mastercard they use on
    sites that don't accept Amex.

  » The 2012 Olympics box office only accepts Visa. It's pointless the
    browser filling in the details of any other brand of card.

* If a card's CSC is stored for the browser to fill this in when making
  a repeat transaction on a site that stores my card number but prompts
  for the CSC each time. I think the East Coast trains site in the UK
  does that, and Amazon if shipping to a new address.

  For this to work for a user who has multiple card numbers stored in
  her browser, the site needs to indicate not just that the text box is
  for a CSC, but which card it is for. This is typically displayed to
  the user as a card number with most of the digits replaced by Xs, and
  sometimes with the card type as well; a way of specifying that in
  mark-up would enable a browser to pick the appropriate card.

* To fill in 3D Secure password characters, for the payment card being
  used.

  Unlike the other card payment fields, a stored 3D Secure password
  (Verified by Visa and similar) only needs to be sent back to one site,
  that of the card issuer, not to every site taking payment. However, if
  multiple cards are stored by the browser (say a debit and credit card
  from the same issuer) then the correct password needs to be picked --
  the one that goes with the card number submitted a page or two back --
  which requires the browser knowing this is a 3D Secure password field,
  (not just a normal site-specific password field it can remember with
  its usual password manager).

  At least some variants of 3D Secure only ask for certain characters of
  the password each time. For this to work with a password manager would
  require the fields to be labelled with which character is being
  requested.

* To work when a part of a card form is served form a different iframe.

  To be PCI compliant, many retailers don't want card numbers and CSCs
  to be submitted to their site, but to a third party whose systems are
  certified as meeting certain standards.
  
  Sometimes all payment details go to the third party, but there are
  third-party providers who serve an iframe for embedding in the
  retailers form. The iframe has <input> elements for the card number
  and CSC; all other fields, including the cardholder's name and the
  card's expiry date, are directly in the retailer's page and submitted
  to them. It's presented as a single form to users. Presumably
  JavaScript is required to submit both forms simultaneously.

  An example of such a service:
  http://www.hostedpci.com/solutions/checkout_express

  You can see this for yourself by going to the Modnique.com site, as
  seen in the screenshot on the above page, and pretending to buy
  something. When you get to the card details page, view the source or
  right-click on the card number part to see that it's an iframe.

  Since it isn't apparent to the customer that there are two separate
  forms here, instructing the browser to fill in my card details should
  also complete the fields in the iframe.

  However ... if I've instructed the browser to fill in card details on
  a site, I wouldn't want it also passing them to a random 'advert' that
  also happens to be on the page, served from an iframe. A malicious
  advert could include form fields (possibly obscured by something
  else), hoping the user will fill them in on the parent page.

>  - credit card details (and subfields such as "name", "exp" etc)

The pedant in my dislikes the term 'credit card' (and hence the
abbreviation 'cc') to refer to something that includes debit cards. It's
a particularly unfortunate term for a site that only accepts debit cards
and not credit cards.

The most commonly used other terms seem to be:

* 'credit or debit card' -- unwieldy

* 'card' -- great for situations where the context makes it clear, but
  can be ambiguous if any other types of card, such as a gift card,
  could be involved

* 'payment card' -- seems to be the payment industry jargon, but not
  widely used by consumers

Admittedly, none of them are ideal.

> The UA conformance criteria would be pretty minimal: for each input
> control with an autocomplete value that matches the above long forms,
> try to determine a value that matches the description of that value
> (the spec would have prose and a table describing what the values
> mean),

Or optionally determine there are several such values -- for example,
because sometimes I have goods sent to my home address and sometimes my
work; I don't have one constant value for 'delivery address', but would
like both of them remembering and to be available.

> and optionally offer to set the control to that value.

Or optionally just set the control to the value, without offering, like
password managers typically do? Or is that too risky, because a site
could have JavaScript which automatically submits a form after a short
delay, to see if the browser has filled in any details for the user?

But maybe an option for 'and automatically do this in future for this
site' would be OK? 

Cheers

Smylers
-- 
http://twitter.com/Smylers2