LGTM1 On Tuesday, December 3, 2024 at 1:32:58 PM UTC+1 lbr...@google.com wrote:
> 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/66f897bd-a60e-4ba4-9038-62dcf1459ef6n%40chromium.org.
