mirror of
https://github.com/mozilla/gecko-dev.git
synced 2025-02-25 11:58:55 +00:00

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.
Description
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
Languages
JavaScript
32.3%
C++
25.4%
HTML
21%
C
10.8%
Python
2.8%
Other
7.2%