Allow setting automatic beacon data from cross-origin subframes. #49960
+191
−12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cross-origin fenced frames/URN iframes can send automatic reporting beacons, but currently require data included in these beacons to be pre-registered via an API call accessible only to a document that is same-origin to the fenced frame config's mapped URL. This poses a problem for cross-origin subframes within the same entity (e.g., an ad frame and a payment subframe from the same company) that need to include dynamic data, like click information, in the beacon. The current workaround involves cumbersome postMessage communication and introduces potential timing issues, highlighting the need for a more practical solution for cross-origin subframes to set their own beacon data. This CL relaxes that restriction and lets cross-origin documents set automatic beacon data as well as use it. This is subject to the same kinds of opt ins as other cross-origin FFAR features. Namely, 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...(). See: WICG/fenced-frame#185 Change-Id: Iea922e737fa870f2edf0c24aa81927535f779d8b Bug: 382500834 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6074470 Reviewed-by: Andrew Verge <[email protected]> Reviewed-by: Dominic Farolino <[email protected]> Commit-Queue: Liam Brady <[email protected]> Reviewed-by: Arthur Sonzogni <[email protected]> Cr-Commit-Position: refs/heads/main@{#1403202}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-6074470
branch
from
412b352 to
b99f6ed
Compare
wpt-pr-bot
approved these changes
Jan 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cross-origin fenced frames/URN iframes can send automatic reporting
beacons, but currently require data included in these beacons to be
pre-registered via an API call accessible only to a document that is
same-origin to the fenced frame config's mapped URL. This poses a
problem for cross-origin subframes within the same entity (e.g., an ad
frame and a payment subframe from the same company) that need to include
dynamic data, like click information, in the beacon. The current
workaround involves cumbersome postMessage communication and introduces
potential timing issues, highlighting the need for a more practical
solution for cross-origin subframes to set their own beacon data.
This CL relaxes that restriction and lets cross-origin documents set
automatic beacon data as well as use it. This is subject to the same
kinds of opt ins as other cross-origin FFAR features. Namely, 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...().
See: WICG/fenced-frame#185
Change-Id: Iea922e737fa870f2edf0c24aa81927535f779d8b
Bug: 382500834
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6074470
Reviewed-by: Andrew Verge <[email protected]>
Reviewed-by: Dominic Farolino <[email protected]>
Commit-Queue: Liam Brady <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1403202}