Intent to ship: Send "Referer" header in reportEvent/automatic beacons

[Liam Brady]

Contact emails

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

Specification

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

Summary

Reporting beacons (e.g. reportEvent to preregistered destination URLs, automatic beacon events, and reportEvent to custom destination URL with substitution of preregistered macros) will have their "Referer" header set to the initiating frame's origin. This is a strictly additive change, as the "Referer" header is currently unpopulated for all fenced frame event-level reports. However, the referrer could be manually added today by callers of reportEvent in the eventData or destinationURL fields of events.

We plan on introducing cross-origin support for reportEvent() beacons and have previously introduced the same support for automatic beacons. When this happens, event-level reports will be able to be sent from origins other than the root ad frame's origin. However, a server currently can't tell where an event-level report originates, since the referrer is unset and the "Origin" header is set to the worklet origin for reportEvent() with destination enum and Automatic beacon events.

Giving a server this information will allow it to make a more informed decision on how to handle reporting beacons originating from documents that are cross-origin to the root ad frame. To align with expectations for how the referrer header behaves, the referrer policy will be set to the policy of the document that initiates the beacon.

Blink component

Blink>InterestGroups

TAG review

None

TAG review status

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

Link to Origin Trial feedback summary

No Origin Trial performed

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: No signal

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. The existing event reporting WPTs have been modified to check for the new header values.

Flag name on about://flags

None

Finch feature name

None

Requires code in //chrome?

False

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6246671997730816

[Mike Taylor]

On 11/28/24 6:41 AM, 'Liam Brady' via blink-dev wrote:

Contact emails

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

Specification

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

Summary

Reporting beacons (e.g. reportEvent to preregistered destination URLs, automatic beacon events, and reportEvent to custom destination URL with substitution of preregistered macros) will have their "Referer" header set to the initiating frame's origin. This is a strictly additive change, as the "Referer" header is currently unpopulated for all fenced frame event-level reports. However, the referrer could be manually added today by callers of reportEvent in the eventData or destinationURL fields of events.

We plan on introducing cross-origin support for reportEvent() beacons and have previously introduced the same support for automatic beacons. When this happens, event-level reports will be able to be sent from origins other than the root ad frame's origin. However, a server currently can't tell where an event-level report originates, since the referrer is unset and the "Origin" header is set to the worklet origin for reportEvent() with destination enum and Automatic beacon events.

Giving a server this information will allow it to make a more informed decision on how to handle reporting beacons originating from documents that are cross-origin to the root ad frame. To align with expectations for how the referrer header behaves, the referrer policy will be set to the policy of the document that initiates the beacon.

This summary is useful - and I guess this last paragraph is the closest thing to an explainer. But it's still missing some useful info. Can you elaborate a bit more on the developer need you're trying to address (i.e., do we have feature requests for this)? Are there any issues you can point to? Alternatives considered, etc?

--
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/24147311-a037-4fe1-8596-a1ea5ca1033fn%40chromium.org.

[Mike Taylor]

One other request: can you please request enterprise, debuggability, and test bits in your chromestatus entry?

[Liam Brady]

There's no feature request for this, but this is something that we anticipate developers are going to want access to, especially after allowing cross-origin documents to send reporting beacons. Since requests are generally sent with some sort of referrer header today on the web platform, we anticipate that developers will have the expectation that reporting beacons are also sent with a referrer header (assuming the referrer policy allows it), and this launch will align the implementation with those expectations.

We considered putting this information in the "Origin" header, but decided against that as we had concerns that it could be used for cross-site request forgery (i.e. the cross-site document sends a beacon that looks like it was sent from the top-level ad frame). The other alternative would be to not include anything and require the documents to "self-report" where they came from in the payload, but since they'd be able to put any arbitrary information in the payload, that method would not be reliable enough to be useful.

I've also flipped the last 3 review bits.

[Yoav Weiss (@Shopify)]

LGTM1

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66f897bd-a60e-4ba4-9038-62dcf1459ef6n%40chromium.org.

[Mike Taylor]

LGTM3, but please fill out the vendor signals part in your chromestatus entry (at least pointing to the parent fenced frame requests - I don't think you need to file new ones here).