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

Now putting on my Chrome hat :)

We believe that the WPWG discussion shows significant need and interest, which aligns with what we have previously heard from other specific payment industry members. In the WPWG discussion (although not captured by the minutes, so of course treat with distrust ;)) we also covered that whilst the WPWG believes in finding 'better' (smoother, more private, more trustworthy) solutions for payments on the web, the group also acknowledges that payment forms are a huge part of payments that is going nowhere soon - and addressing pain points there has value for both web users and the businesses.

I think there are two points we need to speak to - firstly, one suggestion from the WPWG comment, and secondly the outstanding TAG comment re sharing 'upwards'.

**WPWG suggestion to constrain shared-autofill**

In the WPWG discussion, there was a suggestion to constrain shared-autofill if possible, e.g. to be able to say "I trust this iframe, but only for payments, don't give them addresses".

Although we support the idea of trying to constrain in this way, we don't think it is currently feasible:

1. There are no broad categories of autofill types specified today, and the path to specifying them seems unclear given autofill's historical status as a browser feature. It happens that Chrome generally defines our supported autofill types as 'addresses', 'payments', or 'passwords' today - but that's a purely internal splitting and is subject to change (and there are fuzzy boundaries too, e.g. your name could be both payments or address data!). 

2. The autocomplete attribute does give some very specific types (e.g., cc-number), but those are incomplete today - that is, browsers recognize more types of data than are expressable via the autocomplete attribute. In Chrome we're working to correct that (e.g., we have ongoing work for specifying more address-related attributes, and also are looking at specifying things like IBANs), **but** there will almost definitely always be a race where new types are heuristics first, then formally specified later.

3. More technical (rather than ideological), this isn't (I think?) currently possible with the permission prompt syntax - there isn't a way to specify sub-tokens of a permission prompt type. We might be able to introduce a very long list of permission prompts as a hack, e.g. shared-autofill-cc-number, shared-autofill-house-name, etc, but this would get very unwieldy for developers.

As such, Chrome's current position is that we are sympathetic to this idea, but do not believe it feasible/practical. We are open to hearing ideas if anyone has them!

**TAG's recent comment on the 'fill upwards' angle**

[This comment](https://github.com/w3ctag/design-reviews/issues/831#issuecomment-1639668379), where @torgo relayed the concern on sharing less-sensitive data upwards from a fill initiated on an iframe to the main frame.

We appreciate the input and do acknowledge the responsibility to leave the web better. We think that this proposal is still an improvement over the status quo, as the only tool for developers to achieve this today (without browser support) is to postMessage from the iframe to the main frame. When developers do that, the sharing is invisible to the user, whereas with this proposal the browser is able to show an autofill preview that helps the user understand what data is being filled. (We acknowledge that preview will not make it clear to the user that this sharing is across frames, because generally iframe boundaries are invisible to them already).

We also note that the proposed spec text already allows for a user agent to not fill a given field, and also that nothing prevents a user agent from choosing to display a warning to the user if it desires. If the TAG thinks it would help, we could add some note to the spec advising user agents to consider this angle, but we think it should be at most advisory and not a formal `should` requirement.


We look forward to a reply from the TAG, and thanks again for your patience and input!

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

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