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. On Monday, December 2, 2024 at 8:50:26 PM UTC-5 mike...@chromium.org wrote: > One other request: can you please request enterprise, debuggability, and > test bits in your chromestatus entry? > On 12/2/24 9:51 AM, Mike Taylor wrote: > > 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 > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-preregistered-destination-url>, > > automatic beacon events > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#registeradbeacon-1>, > > and reportEvent to custom destination URL with substitution of > preregistered macros > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-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 > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#example> > > or destinationURL > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#example-1> > > fields of events. > > We plan on introducing cross-origin support for reportEvent() beacons > <https://groups.google.com/a/chromium.org/g/blink-dev/c/CrUxPVSscW0> and > have previously introduced the same support for automatic beacons > <https://groups.google.com/a/chromium.org/g/blink-dev/c/byT9ygyWlo0/m/-WsSYjPcAQAJ>. > > 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 > <https://chromium-review.googlesource.com/c/chromium/src/+/5037514/21/content/browser/fenced_frame/fenced_frame_reporter.cc#451> > > for reportEvent() with destination enum > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-preregistered-destination-url> > > and Automatic beacon > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#registeradbeacon-1> > > 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 > <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/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? > > > Blink component > > Blink>InterestGroups > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups> > > TAG review > > None > > TAG review status > > Not applicable. This feature relates to Protected Audience whose review > TAG has already resolved with an "unsatisfied" position > <https://github.com/w3ctag/design-reviews/issues/723>. > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > 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 > > -- > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/24147311-a037-4fe1-8596-a1ea5ca1033fn%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3ce6786e-8dc8-4727-9905-b7e4cd83ee2en%40chromium.org.
