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

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 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.

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

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