Fail to report click data from cross-origin subframe using ARA #185
Comments
|
Possible solutions. |
|
Thanks for the report and the summary! I'm going to look deeper into how feasible option 2 is. There will most likely be some sort of opt-in system in place, but if I can get the relevant privacy experts on board it might be possible. I'll keep you updated. |
|
option 2 is similar to #152 , in which case, the document created with the FencedFrameConfig opts in with a new response header(probably with the ability to set which cross origin domains are allowed). The cross-origin document opts in by calling reportEvent() with the crossOriginExposed=true parameter. |
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jan 7, 2025
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
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Jan 7, 2025
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
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jan 7, 2025
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
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Jan 7, 2025
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}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
This is a Protected Audience project. We want to collect click time signals in a click handler. This is in a cross-origin subframe.
When we use reportEvent API to send back the click data, it works fine.
However, it doesn't work when we use setReportEventDataForAutomaticBeacons. The data of setReportEventDataForAutomaticBeacons() called in the cross-origin subframe doesn't overwrite the data set in the top frame.
The code structure is below.
Main document that embeds an ad
CompanyA-owned ad top frame (calls setReportEventDataForAutomaticBeacons() with crossOriginExposed:true)
CompanyA-owned subframe (calls setReportEventDataForAutomaticBeacons() in the click handler and performs navigation)
The text was updated successfully, but these errors were encountered: