Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define eligibility for autofill #8801

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Conversation

schwering
Copy link
Contributor

@schwering schwering commented Jan 29, 2023

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:


  • At least two implementers are interested (and none opposed):
  • 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
Copy link
Contributor

@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
Copy link
Member

domenic commented Feb 17, 2023

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
Copy link
Contributor

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 :)

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 annevk added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms labels Mar 17, 2023
@annevk
Copy link
Member

annevk commented Mar 17, 2023

cc @whatwg/forms

@galich
Copy link

galich commented Mar 22, 2023

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
Copy link
Contributor Author

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.

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated
</div>

<p>The user agent may fill multiple controls at once even if they have different
<span data-x="form owner">form owners</span>, <span>root</span> elements, or even
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

root nodes (typically root is a document after all)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

source Outdated Show resolved Hide resolved
source Outdated
<p>The user agent may fill multiple controls at once even if they have different
<span data-x="form owner">form owners</span>, <span>root</span> elements, or even
<span data-x="node document">node documents</span>. However, the user agent should not fill in a
field if that field is not <span>eligible for autofill</span>.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@schwering schwering force-pushed the main branch 3 times, most recently from b6b2696 to dcf22fa Compare May 25, 2023 03:47
@schwering
Copy link
Contributor Author

schwering commented May 25, 2023

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.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated
</div>

<p>The user agent may fill multiple controls at once even if they have different
<span data-x="form owner">form owners</span>, <span>root</span> elements, or even
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

source Outdated Show resolved Hide resolved
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 shared-autofill feature is enabled in document for D's origin.

Above, "shared-autofill" refers to a new policy-controlled feature.
Explainer: https://github.com/schwering/shared-autofill

We have no Web Platform Tests 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 integration tests for autofilling forms that span multiple
frames are here:
https://crsrc.org/chrome/browser/autofill/autofill_across_iframes_browsertest.cc
This commit extends the example to explain how and why payment forms
today use cross-origin iframes.

It also extends the note to explain why a user agent might ignore
share-autofill or fill in controls even when shared-autofil is disabled.
@schwering
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms
Development

Successfully merging this pull request may close these issues.

5 participants