Intent to ship: Automatic beacon cross-origin data support (M135)

[Liam Brady]

Contact emails

lbr...@google.com, shiva...@chromium.org, jka...@chromium.org

Explainer

https://github.com/WICG/turtledove/pull/1386

Specification

https://github.com/WICG/fenced-frame/pull/203

Summary

This change allows descendant documents of fenced frames to set the root fenced frame’s automatic beacon reporting data, regardless of origin. Both the root fenced frame and the cross-origin data setting document must opt in for this to be allowed.

More detail:

Fenced frames or URN iframes, if loaded through an API like Protected Audience or Shared Storage, can send out reporting beacons automatically if some event occurs (currently only top-level navigation beacons are supported). We previously tweaked this feature to allow cross-origin documents loaded in the root fenced frame's tree to send automatic beacons if opted in, but still kept the restriction that only frames that are same-origin to the origin loaded by the API could set the data that would be sent as part of the beacon.

The existing setup assumes that payload data will only ever come from the buyer directly. However, there are cases where a buyer embeds a cross-origin subpage that contains data that needs to be sent with an automatic beacon. This limitation forces the same-origin root document to be an intermediary between the page with the data and the automatic beacon API, causing unnecessary extra overhead and forcing extra data to be sent directly to the root fenced frame.

To support this use case while still ensuring security guarantees (mainly that a given frame's data cannot be sent across origins without its consent), both the fenced frame root document and the cross-origin subframe document must explicitly opt in. This is the same opt-in shape as other cross-origin Fenced Frame Ads Reporting features. Specifically, the root frame must opt in via the "Allow-Fenced-Frame-Automatic-Beacons" header, and the cross-origin subframe setting the data must opt in via the 'crossOriginExposed' parameter in the call to setReportEvent...().

This does not change the privacy story nor does it introduce a privacy regression, as cross-origin subframes can currently postMessage() data to the root that the root frame can then use as automatic beacon data. Both the existing capability as well as the proposed changes involve the root fenced frame document and the cross-origin subframe document opting-in to this sharing.

Blink component

Blink>FencedFrames

TAG review

None

TAG review status

Not applicable. This feature relates to Protected Audience whose review TAG has already resolved with an "unsatisfied" position.

Risks

Interoperability and Compatibility

This is an added functionality and is backward compatible. There are no interoperability risks as no other browsers have decided to implement these features yet.

Gecko: Negative on fenced frames

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Not applicable as this will not be supported on Android WebView.

Debuggability

Additional debugging capabilities are not necessary for these feature changes.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Supported on all the above platforms except Android WebView.

Is this feature fully tested by web-platform-tests?

Yes. See: wpt.fyi link.

Flag name on about://flags

None

Finch feature name

FencedFramesCrossOriginAutomaticBeaconData

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

135

Shipping on Android

135

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5121048142675968?gate=5185729511292928

[Mike Taylor]

On 3/19/25 1:16 PM, 'Liam Brady' via blink-dev wrote:

Contact emails

lbr...@google.com, shiva...@chromium.org, jka...@chromium.org

Explainer

https://github.com/WICG/turtledove/pull/1386

Note: reading explainer diffs is not great UX.

Is it expected that Canary is failing all 4 tests?

Flag name on about://flags

None

Finch feature name

FencedFramesCrossOriginAutomaticBeaconData

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

135

Shipping on Android

135

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5121048142675968?gate=5185729511292928

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c1bf85f1-93ad-4b8f-b191-84c6dfeffaa9n%40chromium.org.

[Liam Brady]

> Note: reading explainer diffs is not great UX.

Ack. I'll avoid linking explainer diffs directly in the future.

This section in the FFAR explainer doc should be a much more readable version of what I linked.

> Is it expected that Canary is failing all 4 tests?

Yes. Most fenced frame tests are currently failing on wpt.fyi because they rely on the FencedFrameConfig constructor (see: chrome://flags#enable-fenced-frames-developer-mode) that is not enabled by default. This feature will be enabled by default once we launch fenced frames with local unpartitioned data access, and the tests should start passing then. Note that these tests are all passing on the Chromium build bots where the feature is turned on.

[Mike Taylor]

On 3/25/25 11:04 AM, Liam Brady wrote:

> Note: reading explainer diffs is not great UX.

Ack. I'll avoid linking explainer diffs directly in the future.

This section in the FFAR explainer doc should be a much more readable version of what I linked.

Perfect, thank you.

One thing I'm having a hard time following: in order for the cross-origin automatic beacons to work, you need both a top-level frame to send `ACAER: true`, and the cross-origin embedded frame to send `AFFAB: true`.

But then there's mention of the situation where AFFAO:true isn't needed (because the cross-origin document set `crossOriginExposed: true` within `setReportEventDataForAutomaticBeacons()`.

Why does that override the need to send the header?

> Is it expected that Canary is failing all 4 tests?

Yes. Most fenced frame tests are currently failing on wpt.fyi because they rely on the FencedFrameConfig constructor (see: chrome://flags#enable-fenced-frames-developer-mode) that is not enabled by default. This feature will be enabled by default once we launch fenced frames with local unpartitioned data access, and the tests should start passing then. Note that these tests are all passing on the Chromium build bots where the feature is turned on.

Makes sense, thanks.

[Liam Brady]

> Why does that override the need to send the header?

The intention is to have the cross-origin subframe's document explicitly opt in to the automatic beacon transaction. This is done in order to safeguard the click event itself, not just the data that would be attached to the beacon. If that cross-origin subframe document calls setReport...(), its intention is that it wants to send an automatic beacon and send it with the data provided. Since this function call implies an explicit intention to use the automatic beacon API, we decided to treat the frame invoking the function as it opting in, and if it already has opt in through setReport...(), we didn't think there was a need for it to opt in again through the header.

The header's main purpose is for the case when the cross-origin subframe doesn't want to provide data to be used, but still wants an automatic beacon to be sent out when it performs a top-level navigation.

[Mike Taylor]

OK - makes sense to me.

LGTM1

[Vladimir Levin]

This does not change the privacy story nor does it introduce a privacy regression, as cross-origin subframes can currently postMessage() data to the root that the root frame can then use as automatic beacon data. Both the existing capability as well as the proposed changes involve the root fenced frame document and the cross-origin subframe document opting-in to this sharing.

There's a bit of an overloaded terminology that confuses me: when you refer to a cross-origin subframe, are we talking about a cross-origin fenced frame or an iframe? My recollection is that in a fenced frame case, one cannot use postMessage to communicate with its embedder. Having this data sent, if that's the case, would seem to introduce a new information sharing channel. If the subframe here refers to an iframe, then I agree that there's no novel channel.

 

[Liam Brady]

> There's a bit of an overloaded terminology that confuses me: when you refer to a cross-origin subframe, are we talking about a cross-origin fenced frame or an iframe? My recollection is that in a fenced frame case, one cannot use postMessage to communicate with its embedder. Having this data sent, if that's the case, would seem to introduce a new information sharing channel. If the subframe here refers to an iframe, then I agree that there's no novel channel.

I should've been more explicit when stating what that was referring to. Cross-origin subframes are referring to iframes and not fenced frames in this case. And yes, postMessage isn't allowed between fenced frames and their embedder and continues to be disallowed after this change.

[Vladimir Levin]

LGTM2.

Thanks for clarifying.

[Chris Harrelson]

LGTM3

--

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 blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b91ef12f-56ca-46c8-83e1-8f5f42cf3251n%40chromium.org.