Eligibility for autofill

[schwering]

こんにちは TAG-さん!

I'm requesting a TAG review of shared-autofill.

Payment service providers (PSPs) often distribute form controls (e.g., credit card number, CVC) over multiple distinct PSP iframes on a merchant checkout page. We propose a same-origin policy for autofilling such frame-transcending forms. Additionally, some less-sensitive fields from a PSP point of view (such as cardholder name) are often part of the main merchant frame instead of inside PSP iframes. For this case, we propose a policy-controlled feature which allows a parent frame to designate child frames as trusted for the purposes of Autofill, irrespective of their origin, allowing the browser to fully fill such cross-frame forms.

• Explainer (minimally containing user needs and example code): https://github.com/schwering/shared-autofill
• Specification URL: Define eligibility for autofill whatwg/html#8801
• Tests: 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).
• User research: n/a
• Security and Privacy self-review: the questionnair is below this list
• GitHub repo (if you prefer feedback filed there): https://github.com/schwering/shared-autofill
• Primary contacts (and their relationship to the specification):
  • Christoph Schwering (schwering), Google
  • Stephen McGruer (stephenmcgruer), Google
  • Ian Clelland (iclelland), Google
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification:
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5066686516953088?context=myfeatures

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: none
• The group where the work on this specification is currently being done: whatwg (note that we are still waiting on feedback on the PR from other whatwg members)
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
• Major unresolved issues with or opposition to this specification: none
• This work is being funded by: Google

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @schwering, @stephenmcgruer

Questionnaire

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

Our proposal restricts which origins a browser may share Autofill information with.

The HTML standard currently does not specify which kinds of information are shared, which user action (if any) is necessary to share the information, and which origins the information may be shared with. Most browsers display a list of suggestions when the user interacts with a form control, and they share the selected information with the form control’s document when the user confirms a suggestion.

We propose to restrict this information sharing to documents which either have the same origin as the form control the user interacted with or have the newly proposed shared-autofill enabled. As a policy-controlled feature, only the first party can enable shared-autofill in child frames.

2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes, our proposal minimizes the scope the information is shared. It will improve transparency in the following way.

Today’s browsers do not fill across origins. Many payment service providers work around by posting autofilled information from one frame to other frames using postMessage(). Naturally, such workarounds break the preview of to-be-autofilled information built into many browsers. Our spec makes such workarounds obsolete and lets the browser preview and autofill form controls in cross-origin form documents (if shared-enable is enabled in the respective document).

2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

Our specification fills a gap in formalizing the conditions under which the browser may fill such information.

Our proposal allows sharing such information according to a same-origin policy and a newly proposed policy-controlled feature shared-autofill, which can be passed by parent frames to their child frames to designate such frames as trustworthy for autofill purposes.

As argued in 2.2, our proposal intends to make JavaScript workarounds obsolete and increase transparency.

2.4 How do the features in your specification deal with sensitive information?

See 2.3.

2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No.

2.6 Do the features in your specification expose information about the underlying platform to origins?

No.

2.7 Does this specification allow an origin to send data to the underlying platform?

No.

2.8 Do features in this specification enable access to device sensors?

No.

2.9 Do features in this specification enable new script execution/loading mechanisms?

No.

2.10 Do features in this specification allow an origin to access other devices?

No.

2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No.

2.12 What temporary identifiers do the features in this specification create or expose to the web?

None.

2.13 How does this specification distinguish between behavior in first-party and third-party contexts?

The first party can enable shared-autofill in third-party child frames, and these child frames in turn can enable shared-autofill in their respective child frames. This behaviour is due to shared-autofill being a policy-controlled feature.

2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

The proposal is unrelated to private browsing or incognito mode. A browser may decide to disable Autofill in such a mode.

2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

It doesn’t have sections with these titles, but it does have a section on attack vectors.

2.16 Do features in your specification enable origins to downgrade default security protections?

There are currently no security protections for Autofill. This proposal introduces default protections, as well as a policy-controlled feature that is disabled by default for cross-origin iframes.

2.17 How does your feature handle non-"fully active" documents?

Our specification excludes non-”fully-active” documents.

2.18 What should this questionnaire have asked?

It seems sufficient.

[torgo]

Hi - can you clarify where this work is currently happening? Is this slated to be done in WICG? Has there been any engagement on this topic with other engines / browsers?

[cynthia]

Thanks for bringing this to our attention. We looked at this during our F2F, and overall we are happy with this. It solves an immediate user need, which is being able to autofill cross origin forms, which as far as the user is concerned should work like any other form.

We have a couple points we'd like to discuss here, both of which are likely out of your immediate control but would like to see some progress on.

1. Interest from other implementors. This seems like a useful, safe feature which would be more powerful if at least one other implementor is interested in implementing this (setting aside the depedency on permission policy, which is a dependency).
2. We do see the immediate reason why multi-frame forms is a thing, but we would like form domain experts to think about a future direction where we move away from this somewhat convoluted architecture. We understand the proposal is working around layers of limitations, but we feel like it shouldn't be this way.
3. In an ideal world, the solution to (2) might be web payments.

[hober]

As @annevk said elsewhere, autofill "is a user interface feature and as such the call as to whether or not to make it work in a particular case is with the user agent and not the HTML Standard." If some browsers' autofill doesn't work with fields in Shadow DOM, for instance, that seems like a bug in such browsers, and not with the spec.

[schwering]

Thank you all for the feedback and comments!

Re @torgo

We intend to pursue this in the WHATWG as part of the HTML spec, and are looking to drive consensus on the autofill definitions within that group.

Re @cynthia

1. The final positions on the proposal from Mozilla and Apple are pending and discussions are ongoing.
2. We agree. We suppose this would need cooperation of the implementors, payment industry, and payment service providers.
3. Acknowledged.

Re @hober

Thanks Tess (and Anne!); we do appreciate and agree that autofill is a user interface feature. However, we think there is value in giving web developers some structure around what they can roughly expect, and in particular we think specing shared-autofill as a clear (though non-binding) signal to the browser is valuable. Much like how autocomplete="cc-number" is a valuable signal for web developers to know about.

We're happy to work with Anne to find the right middle-ground of what to spec – see our latest reply in the WebKit request for positions where we changed the text, and we can keep iterating on that!

[torgo]

Hi folks – We discussed this in today's TAG breakout.

We remain concerned with the level of information available to the user about what they have agreed to share with whom via auto-fill. Is it possible to advise UA providers to surface this information to the user in some way "are you OK with sharing your cc number with ecommerce site who uses payment provider as a payment provider?"

We also remain concerned about the multi-stakeholder buy in. If this is going to be adopted by the industry then we'd like to make sure it's widely adopted across browsers.

Apart from that can you let us know any other status or updates?

[ianbjacobs]

Just a note: we can make time on Monday or Tuesday at TPAC at the WPWG meeting to discuss this if people would find that useful. (Tuesday afternoon is particularly good.)

[RByers]

Thanks Ian. I'll be there and happy to present for such a discussion if there's interest.

[RByers]

A few of us met at TPAC to discuss this: @torgo, @stephenmcgruer, Gerhard Oosthuizen, @cynthia and myself. Here's my summary of the conversation, please let me know if I missed or mis-recalled anything.

First Dan said the TAG wanted to understand how we could help web payments shift towards something better than forms long-term. We all agree that entering strings into text fields is a sub-optimal user experience for completing a payment. @stephenmcgruer described the many years of efforts from WPWG and others, and how the industry is continuing to shift towards payment apps - whether via PaymentRequest or some other mechanism on top of web platform primitives. We talked a bit about things we may (or may not) be able to do to further accelerate a reduction on reliance of input fields, but I think there was agreement that input fields weren't going to just go away anytime soon. Certainly @stephenmcgruer and I intend to continue investing in approaches in Chrome to help meet the needs of the payments industry outside of input fields, but feel we need to address this tactical and pragmatic issue with payment forms in parallel with that.

Secondly we discussed my proposal above to shift the policy away from a nuanced implementation detail of autofill (shared-autofill) to more of a trust model for the embedder/embedee relationship around collecting user data. We heard that pii-input was a bad name because "PII" has a very specific legal meaning we wouldn't want to confuse things with. Otherwise Dan said he'd like to discuss this more with the TAG and get back to us ASAP.

On Chrome, we'd like to proceed with some urgency in this direction. Our current thinking is that we'll update our proposal to use the permission name input but defined in a way that gives the user agent latitude in deciding which forms of "input" are risky enough to disallow in frames lacking this permission. Frames with the input permission would be expected to accept all forms of input exactly as if they were operating in the top frame. In Chrome we'd start by only gating new automated input scenarios like shared-autofill on the input permission, but over time we'd explore whether there are existing classes of input we could begin to warn about or restrict when this permission is lacking. We welcome feedback on this approach, and I'll post pointers here as we proceed down the path of trying to ship this.

[torgo]

Hi @RByers - Discussed briefly today and there is rough consensus that this is the right approach. We'd like to see it written up in a revised proposal – is that in the works?

[RByers]

Great, glad to hear it @torgo! I'm personally excited about taking steps towards making the web's model for user data acquisition more explicit...

Yes @schwering is working on an updated proposal but it may be delayed a bit now as something more urgent came up for him. We'll ping this review whenever the explainer and spec PR have been updated. But also this is really just a change of positioning / long-term goal (and policy name) with the immediate next step otherwise unchanged.

[hadleybeeman]

Hi @RByers! Just to clarify, after a quick conversation at our plenary meeting today — we would appreciate it if you could explore some abuse scenarios in your updated proposal. We had some concerns, and would really value your thoughts on how to mitigate any potential problems. Huge thanks!

[RByers]

Hi @hadleybeeman, do you mean improving on the existing attack vectors section of the explainer which focuses on how the narrow case of autofill split across frames could potentially be abused? Or do you mean broaden the abuse discussion to autofill in 3p iframes generally (i.e. status quo in multiple browsers) and how the new proposal gives a path to potentially reduce that risk over time? Or maybe both?

[torgo]

Hi @RByers - we just discussed in TAG plenary today and I think what we're asking for is more the first thing - expansion on the existing attack vectors discussion - although in my view "attack vectors" may be too narrow a framing. What we're concerned about is general abuse scenarios of this new proposal: given that this new proposal is in place, what are the abuse scenarios, including by actors who may be "legitimate actors", and what are the mitigations against those? In other words, how may this be mis-used by players in the web ecosystem?

[torgo]

Hi @RByers - we were just briefly reviewing status on this. First of all, has there been any update that we should be aware of? Should we be re-reviewing at this point?

[schwering]

Hi Daniel! I'm currently revising the proposal, broadening its scope from autofill to (keyboard) input in iframes. I'll update the thread here when I have something to share.