[w3ctag/design-reviews] Eligibility for autofill (Issue #831)

こんにちは 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: https://github.com/whatwg/html/pull/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:

  - [x] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/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](https://github.com/schwering/shared-autofill#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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/831
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/831@github.com>