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/CAOmohS%2BY7jfDL9R%3DgYoRUkGnqT5aD82AZmfg3Me8zEFk6Ho_qA%40mail.gmail.com.

Reply via email to