FYI - https://github.com/WICG/autofill-event/pull/30
Any other feedback would be appreciated! :) On Tue, Jan 27, 2026 at 2:06 PM Yoav Weiss (@Shopify) < [email protected]> wrote: > Hey Chris! > > On Mon, Jan 26, 2026 at 9:10 PM Chris Thompson <[email protected]> wrote: > >> Hi Yoav -- >> >> Chrome web platform security folks took a quick look at this -- we think >> there aren't any concerns but I think the spec could be clarified a bit to >> make it more obviously the case :-) >> >> Section 6 flags that UAs SHOULD only expose the data after explicit user >> confirmation. We think this is also important irrespective of timing >> attacks. >> > > Yeah, the "timing attack" title is not appropriate. I'll revamp. > > >> It also wasn't immediately clear to us that the data being passed is >> limited to the specific autofill fields/type >> <https://wicg.github.io/autofill-event/#dom-autofillevent-autofillevent-type-eventinitdict-type> >> initially requested (and thus confirmed by the user) and this *cannot* be >> changed by the page handling the autofill event -- i.e., that all that can >> happen is a refill for the same data the user already consented to share. >> Maybe this is just under-specified and UA-dependent? >> > > It's indeed not specified (as it's not specified today), but at the same > time, the spec does define the "full-address" autocomplete value > <https://wicg.github.io/autofill-event/#full-address> that enables the UA > to know ahead of time that it needs to get user consent for the entire > address information, not just the fields currently present in the form. > > We heard feedback from some UAs that this would be required for them, > while others felt that getting user consent of the specific parts of the > address implies consent for the more generic parts. > > The attribute will enable each UA to apply the policy it deems fit. > > I think it would still be good to at least discuss in the Security/Privacy >> considerations section, even if it's non-normative. >> > > Sure! > > >> Additionally, given that requirement, the new "full-address" field name >> may have UX challenges to ensure that the user understands the full scope >> of what is being shared. >> > > Potentially, but I imagined it being equivalent to pretending that all the > fields that are relevant to the user's address are already present in the > form. > > >> >> Cheers, >> Chris >> >> On Wednesday, January 14, 2026 at 6:22:57 AM UTC-8 Yoav Weiss (@Shopify) >> wrote: >> >>> *Contact emails* >>> [email protected], [email protected] >>> >>> *Explainer* >>> https://github.com/WICG/autofill-event?tab=readme-ov-file#autofill-event >>> >>> *Specification* >>> https://wicg.github.io/autofill-event >>> >>> *Summary* >>> Autofill is a key feature of the web that reduces friction for millions >>> of users everyday. But getting autofill to work reliably with dynamic forms >>> across multiple implementations requires jumping through many hoops. This >>> feature adds an "autofill" event that would allow developers to modify >>> their forms to fit the autofilled data and let the browser know when they >>> have done so. >>> >>> *Blink component* >>> Blink >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> >>> >>> *Web Feature ID* >>> Missing feature >>> >>> *Motivation* >>> Autofill today relies on static forms, but address forms are dynamic, >>> almost by definition. Addresses around the world have different fields and >>> requirements, and developers have to reconcile that dynamic nature with >>> autofill's static nature. Some browser heuristics are simplifying that task >>> in some implementations, but dealing with that implementation-specific >>> complexity requires jumping through a bunch of hoops. This feature will >>> enable developers to be notified of autofill-filled values, modify the form >>> to match the filled data and let the browser know when that modification >>> happened, enabling the browser to refill the data in the adapted form. >>> >>> *Initial public proposal* >>> https://github.com/WICG/proposals/issues/162 >>> >>> *Requires code in //chrome?* >>> True >>> >>> *Tracking bug* >>> https://issues.chromium.org/issues/466333215 >>> >>> *Estimated milestones* >>> >>> No milestones specified >>> >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5137581018841088?gate=5148847959572480 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKqgEjSSSHu2Wcbhvx8-8SwzFRui2ztMF8CJ%3DvC%2BfLcQw%40mail.gmail.com.
