tree e674dc2c6fed3609decf78a1cae6280b6243aaf6
parent 8b2ff8f91555ee3cda84ad9bca665d960c4769e7
author Liam Brady <lbrady@google.com> 1701893054 -0800
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> 1701897651 -0800

Allow cross-origin subframes to send automatic beacons.

Fenced frames can send out reporting beacons if an event occurs.
However, only same-origin documents are allowed to send automatic
beacons. This restriction is problematic when a subframe from a
third-party ad server is embedded in an ad loaded with a script from
that server. One such use case is when an ad frame embeds a subframe
that loads the actual contents of an ad. This is known as Third-party ad
serving, or 3PAS.

The solution to allow cross-origin subframes to send automatic beacons
involves four parts: subframes will opt in through a header, the main ad
frame will opt in to allow cross-origin subframes to use its automatic
beacon data when sending automatic beacons, the subframe will then be
able to use the automatic beacon data that is stored in its frame tree's
FencedFrameConfig, and the automatic beacon data will be stored
per-document rather than per-fenced frame config.

The opt-in mechanism for the main ad frame's data is a new
"crossOriginExposed" parameter in
`setReportEventDataForAutomaticBeacons()`, which defaults to false.

The opt-in mechanism for the cross-origin subframe is done through a new
"Allow-Fenced-Frame-Automatic-Beacons" response header.

The reason for storing the beacon data per-document is a security one.
With the current setup, a same-origin subframe of an ad frame could set
automatic beacon data, and a different cross-origin subframe could then
use that data. Since those two frames are not direct descendants of each
other, we want to prevent that behavior, and instead only allow
documents to use opted in data set by direct ancestors.

This CL also modifies the automatic beacon web platform tests to
properly handle multiple beacons being sent with the same data. The
automatic beacon store endpoint now accepts a "beacon type" parameter
that is added to the hash when storing/retrieving a beacon. This will
prevent collisions if two beacons with different types are sent with
the same data.

Change-Id: I4af9d7ef34732dcd56c4f6bcf677f48956f7968c
Bug: 1504306
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5018876
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Commit-Queue: Liam Brady <lbrady@google.com>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1234109}