Define eligibility for autofill

[schwering]

Introduces a necessary condition for a user-agent to autofill a collection of form controls:

A form control C is eligible for autofill if C's node document D is fully active and one of the following is true:

• Some element is focused and its node document's origin is the same origin as D's origin.
• The policy-controlled feature shared-autofill is enabled in document for D's origin.

---

• At least two implementers are interested (and none opposed):
  • Chrome
  • Mozilla: Eligibility for autofill mozilla/standards-positions#752
  • WebKit: Eligibility for autofill WebKit/standards-positions#141
• Tests are written and can be reviewed and commented upon at:
  • No Web Platform Tests were written because there is no JavaScript API for triggering Autofill. In particular, there is no API for storing or accessing data to be filled (e.g., a credit card).
  • Chromium's integration tests are available.
• Implementation bugs are filed:
  • As far as I know, all implementors do satisfy the aforementioned necessary condition, mostly trivially because they only fill controls that have the same node document. Chromium implements support for autofilling across frames in line with the necessary condition.
  • Chromium: crbug.com/1187842, crbug.com/1201849
  • Gecko: …
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• MDN issue is filed: …

(See WHATWG Working Mode: Changes for more details.)

---

/acknowledgements.html ( diff )
/form-control-infrastructure.html ( diff )
/forms.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/references.html ( diff )

[stephenmcgruer]

@domenic - is there a process in WhatWG for us to get this PR reviewed? We'd be interested to hear any feedback :).

Christoph will be sending request for positions to the other browsers for the part of this spec change that is new soon (e.g., the shared-autofill policy and the behavior it enables), so we may also hear feedback from them there ofc.

[domenic]

Some mechanisms you can use:

• Ping, either in this thread via @-mentions, or offline via emails, your contacts at other vendors asking for their review.
• Use other vendors' standards-position repositories to ask for their review.
• Attend the HTML triage meeting (Upcoming HTML standard issue triage meeting on 2/23/2023 #8873) to briefly explain your feature and ask for reviews.

[stephenmcgruer]

Ack, thanks Domenic.

@schwering - I suggest we start with the WebKit and Gecko standards-position repos (request for position), and see if we get any feedback there. Happy to assist you in drafting/sending those requests, just lmk if I can help :)

[annevk]

Thanks for writing this up!

Couple things:

• It reads like an introduction for Autofill, but then suddenly switches to making requirements. That's less than ideal. Especially with a later subsection titled "Processing model".
• The examples do not use the autocomplete attribute. I understand user agents typically support that, but none of that is standard and I'm not sure we want to encourage folks relying on it.
• The cross-document example could detail the specifics of the input element a bit more.
• You need to hook into the Permissions Policy processing model.

For the merchant, this design combines security and flexibility: the cross-origin iframes isolate the sensitive payment information from the merchant's infrastructure (which helps them with PCI DSS compliance), yet the merchant can arrange and style the fields in their website's look and feel.

This doesn't explain how the merchant accomplishes styling the fields. Also, PCI DSS is a pretty broad reference for someone unfamiliar with this field. It would help to have a more relevant quote about the requirements.

Also, is there more information as to why there is an expectation that merchants will adopt this as opposed to payment APIs?

[annevk]

cc @whatwg/forms

[galich]

There are a few items I'd like to understand better before we decide on our position to this proposal.

1. Some real life examples of the problem
   Are there specific web sites missing that feature? How widespread the problem is?

2. No explicit definition what information can be shared
   Merchant site can embed a weather widget iframe that needs a postal code. A few months later weather site adds more inputs, including credit card number or password. Now users of merchant site are leaking information to weather widget when they sign in to merchant site.

3. What to do with multiple iframes wanting the same fields
   When merchant site has 2 payment providers with their iframes, filling in one of them will fill another too? What about sites with multiple sign in and sign up forms? Filling a password in one, will send it to other?

[schwering]

Thank you both for the feedback!

A couple of questions regarding Anne's feedback:

It reads like an introduction for Autofill, but then suddenly switches to making requirements. That's less than ideal. Especially with a later subsection titled "Processing model".

The last sentence of the introduction transitions to the next subsection, doesn’t it? What do you have in mind to make the transition more smoothly?

As for the processing model subsection, I think ideally it’d be a subsection of the autocomplete attribute, but it’s already an h6 and also I see non-nested “Processing model” sections are a recurring theme in the standard. Should we put the autocomplete attribute and the processing model subsections under their own h5?

The examples do not use the autocomplete attribute. I understand user agents typically support that, but none of that is standard and I'm not sure we want to encourage folks relying on it.

I think using the autocomplete attribute in the example forms leads to a dependency problem:

• The first example form is an introductory example and should come before the autocomplete subsection.
• The second example form could use autocomplete if we move the eligibility subsection after the autocomplete subsection. That ordering sounds wrong to me though.

I see how using the name attribute in the examples can be misinterpreted as being a binding hint to the browser. WDYT about using name-less form controls instead? That makes referencing them in the text a little more ambiguous though.

The cross-document example could detail the specifics of the input element a bit more.

I’ve added a minimal example document. Is that what you had in mind?

You need to hook into the Permissions Policy processing model.

How do you mean? I was intentionally following the pattern of the two other policy-controlled features in the standard: the autoplay feature is mentioned in a similar eligibility definition, and the cross-origin-isolated feature is mentioned without further reference. Neither go into the details of the processing model as far as I’m aware. Section 2.2, which lists the policy-controlled features, links to the permissions policy spec.

Replies to Sergey's questions:

1. We estimate about 18% of all credit card forms have fields across multiple origins. This includes large payment service providers like Stripe or Braintree. Here’s a somewhat random collection of sites whose credit card forms transcend multiple origins:
   • adoreme.com (PSP: stripe.com)
   • blinds.com (PSP: homedepot.com)
   • esteelauder.com (PSP: adyen.com)
   • flixbus.com (PSP: adyen.com)
   • hsn.com (PSP: paymentgateway.hsn.com)
   • maurices.com (PSP: aurusepay.com)
   • patagonia.com (PSP: adyen.com)
   • patreon.com (PSP: tokenex.com)
   • ruelala.com (PSP: braintree.com)
   • talbots.com (PSP: vantivcnp.com)
   • torrid.com (PSP: firstdata.com)
   • usps.com (PSP: vantivcnp.com)
   • vroom.com (PSP: stripe.com)
   • zoro.com (PSP: cybersource.com)
     Some of these sites are not available or use different payment service providers depending on the visitor’s country. For consistency, I tested these with a US IP address.
2. Yes, the merchant should allow shared-autofill only in iframes they trust. The default allowlist is 'src' so the merchant needs to actively express they trust the weather widget with respect to autofill. Since different user agents support different types of autofill information, it seems impractical to standardize what may be shared; I'd suspect we'd end up with a huge, constantly changing list of items.
3. We only propose a necessary condition for autofill. Which fields to actually fill is (still) up to the user agent.
   Chrome does not fill passwords across frames. For addresses and credit cards, Chrome fills controls at once only if they are associated with or frame-transcending descendants of the same in the main frame.

[annevk]

This looks okay, but it would be great to have a version that does not fail the build so I can look at how at it in context better.

[annevk]

root nodes (typically root is a document after all)

[schwering]

To clarify in case I'm using the wrong terminology here: I'm trying to say that even if

• form control A's root is a Document and
• form control B's root is a (non-null) shadow root,
• form control C's root is another (non-null) shadow root,

then A, B, C may be filled in together.

[annevk]

Right, it's just that shadow roots and documents are not elements. Looks okay now.

[annevk]

It's not entirely clear to me this is "should not" material. Whenever the user agent would not follow this they have a good reason (to serve the end user's interests) so it seems stronger than it actually is.

[schwering]

I've added a note further down that lists reasons why a user agent not-fill eligible fields or fill not-eligible fields. WDYT?

[schwering]

Thanks for the feedback, Anne! I've updated the PR but I'll upload another patch that extends the example and note.

The build fails at the deploy stage though because I created this PR from schwering:main rather than a new branch. It seems that GitHub does not allow renaming the source branch of an existing PR. I've uploaded a built version, if that helps.

[annevk]

Right, it's just that shadow roots and documents are not elements. Looks okay now.

[annevk]

I think this is largely fine now, modulo nits. Thanks! I saw that the W3C TAG had some feedback we should maybe wait for. Also not sure if @domenic or @zcorpan also wants to review.

[schwering]

Thanks! I've addressed the nits and rebased the PR.
Regarding the TAG's feedback, we're currently discussing this internally and will respond there.