Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons
Liam Brady
Contact emails
lbr...@google.com, shiva...@chromium.org, jka...@chromium.org
Explainer(s)
https://github.com/WICG/turtledove/pull/904
Spec(s)
https://github.com/WICG/fenced-frame/pull/133
Summary
As part of the Privacy Sandbox experiment, we introduced a way for beacons to be sent automatically if a top-level navigation is initiated from within an ad frame. At the time, we restricted this feature to frames and subframes that were same-origin to the root ad frame. However, there is a use case that this is not able to handle. With third-party ad serving (3PAS), the actual contents of the ad (including links/click handlers) are loaded in a cross-origin subframe. Because it is cross-origin, the frame does not get access to the automatic beacon API, and therefore is not able to report a top-level navigation when a user clicks on the ad.
A cross-origin subframe can now opt in to sending automatic beacons by setting a new response header: "Allow-Fenced-Frame-Automatic-Beacons". The cross-origin frame still cannot set automatic beacon data; instead, the main ad frame will set the automatic beacon data, but opt in to having the data be used for cross-origin automatic beacons using a new "crossOrigin=true" parameter. When these 2 criteria are met, the cross-origin subframe will send an automatic beacon when a top-level navigation happens.
This feature will also fix a separate issue brought up externally and allow for ad components to opt into sending automatic beacons without needing to invoke setReportEventDataForAutomaticBeacons(); they instead will just need to supply the "Allow-Fenced-Frame-Automatic-Beacons" response header. This will not remove the existing way for ad components to opt into sending beacons.
Blink component
TAG reviews and status
Fenced frames existing TAG review appended with these spec changes https://github.com/w3ctag/design-reviews/issues/838#
Link to Origin Trial feedback summary
No Origin Trial performed
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Supported on all the above platforms except Android WebView.
Debuggability
Additional debugging capabilities are not necessary for these feature changes.
Risks
Compatibility
This is an added functionality and is backward compatible.
Interoperability
There are no interoperability risks as no other browsers have decided to implement these features yet.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes. New automatic beacon tests have been added to test cross-origin beacons.
automatic-beacon-cross-origin-false.https.html (test) (results)
automatic-beacon-cross-origin-navigation.https.html (test) (results)
automatic-beacon-cross-origin-no-data.https.html (test) (results)
automatic-beacon-cross-origin-no-opt-in.https.html (test) (results)
automatic-beacon-use-ancestor-data.https.html (test) (results)
WPT directory for Fenced Frames: https://github.com/web-platform-tests/wpt/tree/master/fenced-frame
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5179499557945344
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ
Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/y6G3cvKXjlg/m/Lcpmpi_LAgAJ
Intent to ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/tpw8wW0VenQ/m/mePLTiHlDQAJ
Mike Taylor
Hi Liam,
Contact emails
lbr...@google.com, shiva...@chromium.org, jka...@chromium.org
Explainer(s)
https://github.com/WICG/turtledove/pull/904
Spec(s)
https://github.com/WICG/fenced-frame/pull/133
Summary
As part of the Privacy Sandbox experiment, we introduced a way for beacons to be sent automatically if a top-level navigation is initiated from within an ad frame. At the time, we restricted this feature to frames and subframes that were same-origin to the root ad frame. However, there is a use case that this is not able to handle. With third-party ad serving (3PAS), the actual contents of the ad (including links/click handlers) are loaded in a cross-origin subframe. Because it is cross-origin, the frame does not get access to the automatic beacon API, and therefore is not able to report a top-level navigation when a user clicks on the ad.
A cross-origin subframe can now opt in to sending automatic beacons by setting a new response header: "Allow-Fenced-Frame-Automatic-Beacons". The cross-origin frame still cannot set automatic beacon data; instead, the main ad frame will set the automatic beacon data, but opt in to having the data be used for cross-origin automatic beacons using a new "crossOrigin=true" parameter. When these 2 criteria are met, the cross-origin subframe will send an automatic beacon when a top-level navigation happens.
Is "crossOrigin=true" different than the "crossOriginExposed" boolean defined in the spec? Or just a typo?
Another question: is there any reason you chose to create a new
HTTP header, rather than use something like Permissions-Policy?
(Maybe that's not supported for fenced frames?)
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d33531b6-bc29-4951-ab8b-3b58880568den%40chromium.org.
Liam Brady
"crossOrigin=true" is just a typo. "crossOrigin" was the original naming convention for "crossOriginExposed". It was renamed during code review, but I forgot to update the I2S wording to match that.
We chose to not go with Permissions-Policy for a few reasons. First is that for fenced frames created through something like Protected Audience, they have a fixed list of permissions that must be enabled for the frame to load, so refactoring that to support one permissions policy that can be either enabled or enabled would be a lot of effort. Doing that would also allow 1 bit of information to leak from the embedder to the fenced frame, which is the whole reason we locked down permissions policies in the first place. We also didn't want the embedder to have any control over how this header is set (such as having an embedder opt in on the frame's behalf), and since permissions policies are based on inheritance, that was something we needed to avoid.
Mike Taylor
Thanks Liam. This seems fine to me given that both parties need
to opt in.
LGTM1
Yoav Weiss (@Shopify)
Daniel Bratell
LGTM3
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ca9eb71-fbf6-4e9d-a8b1-524306d0fbaen%40chromium.org.