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. 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? I think it would still be good to at least discuss in the Security/Privacy considerations section, even if it's non-normative. 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. 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/340b8c4e-6ee4-4b59-861b-35467144d03bn%40chromium.org.
