| commit | 458d51295af838f04608bda0dc912aaf88bc1de3 | [log] [tgz] |
|---|---|---|
| author | Liam Brady <lbrady@google.com> | Wed Dec 06 20:04:14 2023 |
| committer | Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> | Wed Dec 06 21:20:51 2023 |
| tree | e674dc2c6fed3609decf78a1cae6280b6243aaf6 | |
| parent | 8b2ff8f91555ee3cda84ad9bca665d960c4769e7 [diff] |
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}
The web-platform-tests Project is a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.
The most important sources of information and activity are:
wpt:matrix.org matrix channel; includes participants located around the world, but busiest during the European working day.If you'd like clarification about anything, don't hesitate to ask in the chat room or on the mailing list.
Clone or otherwise get https://github.com/web-platform-tests/wpt.
Note: because of the frequent creation and deletion of branches in this repo, it is recommended to “prune” stale branches when fetching updates, i.e. use git pull --prune (or git fetch -p && git merge).
See the documentation website and in particular the system setup for running tests locally.
The wpt command provides a frontend to a variety of tools for working with and running web-platform-tests. Some of the most useful commands are:
wpt serve - For starting the wpt http serverwpt run - For running tests in a browserwpt lint - For running the lint against all testswpt manifest - For updating or generating a MANIFEST.json test manifestwpt install - For installing the latest release of a browser or webdriver server on the local machine.wpt serve-wave - For starting the wpt http server and the WAVE test runner. For more details on how to use the WAVE test runner see the documentation.On Windows wpt commands must be prefixed with python or the path to the python binary (if python is not in your %PATH%).
python wpt [command]
Alternatively, you may also use Bash on Ubuntu on Windows in the Windows 10 Anniversary Update build, then access your windows partition from there to launch wpt commands.
Please make sure git and your text editor do not automatically convert line endings, as it will cause lint errors. For git, please set git config core.autocrlf false in your working tree.
The master branch is automatically synced to wpt.live and w3c-test.org.
Save the Web, Write Some Tests!
Absolutely everyone is welcome to contribute to test development. No test is too small or too simple, especially if it corresponds to something for which you've noted an interoperability bug in a browser.
The way to contribute is just as usual:
git checkout -b topic../wpt lint as described above.If you spot an issue with a test and are not comfortable providing a pull request per above to fix it, please file a new issue. Thank you!