Automatic update from web-platform-tests
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}
--
wpt-commits: 458d51295af838f04608bda0dc912aaf88bc1de3
wpt-pr: 43125
An explanation of the Firefox Source Code Directory Structure and links to
project pages with documentation can be found at:
https://firefox-source-docs.mozilla.org/contributing/directory_structure.html
For information on how to build Firefox from the source code and create the patch see:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
If you have a question about developing Firefox, and can't find the solution
on https://firefox-source-docs.mozilla.org/, you can try asking your question on Matrix at chat.mozilla.org in `Introduction` (https://chat.mozilla.org/#/room/#introduction:mozilla.org) channel.
Nightly development builds can be downloaded from:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
https://www.mozilla.org/firefox/channel/desktop/#nightly
Keep in mind that nightly builds, which are used by Firefox developers for
testing, may be buggy.
1f812d682c