Intent to Ship: Fenced Frame - Functionality Updates
Liam Brady
shiva...@chromium.org jka...@chromium.org lbr...@google.com
Explainer(s)Send Automatic Beacons To All Registered Destinations
https://github.com/WICG/turtledove/pull/808
Spec(s)
Send Automatic Beacons To All Registered Destinations
(Initial version) https://github.com/WICG/fenced-frame/pull/122
(Post-security review updates) https://github.com/WICG/fenced-frame/pull/129
Summary
One of the capabilities of fenced frames and URN iframes loaded through Protected Audience or Shared Storage is being able to send reporting beacons automatically after a top-level navigation. We would like to modify that functionality:
Automatic beacons will now send to URLs registered via registerAdBeacon() on reserved.top_navigation calls, but they will not have beacon data attached to the request. Previously, only URLs registered via setReportEventDataForAutomaticBeacons received beacons, and they do have beacon data attached.
Note: This chromestatus entry also includes changes to Protected Audience ad size macros. However, it is small enough that it will be taken care of in a separate PSA: https://groups.google.com/a/chromium.org/g/blink-dev/c/3JfA8EUBEgQ
Blink component
TAG reviews and status
Fenced frames existing TAG review appended with these spec changes https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1765061770
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
There are no compatibility risks, as described below:
The API shape as exposed to ad frames is not changing. While the assumptions of which sites receive the beacon after calling setReportEventDataForAutomaticBeacons() is changing, no code changes will be required to have existing code work with this new behavior.
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
automatic-beacon-no-destination.https.html (test) (results)
automatic-beacon-no-opt-in.https.html (test) (results)
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5140606359175168
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 extend origin trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ
https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ
https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ
Intent to ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/tpw8wW0VenQ/m/mePLTiHlDQAJ
Intent to ship for functionality updates:
https://groups.google.com/a/chromium.org/g/blink-dev/c/2FKlwNZ0J4Q/m/oQmHtp1rAQAJ
Yoav Weiss
Liam Brady
Mike Taylor
Hi Liam!
On 10/20/23 4:37 PM, 'Liam Brady' via blink-dev wrote:
Contact emailsshiva...@chromium.org jka...@chromium.org lbr...@google.com
Explainer(s)Send Automatic Beacons To All Registered Destinations
FWIW, it's a bit challenging to read an explainer as diffs on
GitHub and infer the motivation. For future intents, could you
write up the motivation and use cases for the "updates" elsewhere
(gist, comment, inline here), or just land the PR in the existing
explainer? Is there any reason the PR hasn't landed?
Attempting to mentally patch the diffs to https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#support-for-attribution-reporting, it seems like this intent is intended to support attribution reporting. And it seems like sending a reporting beacon for the "reserved.top_navigation" event to all registered URLs without event data is useful. But I don't really know. :) Can you elaborate, assuming my understanding is correct?
(One more note - sending a title like "Fenced Frames - Send
Automatic Beacons To All Registered Destinations" is a lot more
clear than "Functionality Updates")
Spec(s)
Send Automatic Beacons To All Registered Destinations
(Initial version) https://github.com/WICG/fenced-frame/pull/122
(Post-security review updates) https://github.com/WICG/fenced-frame/pull/129
--
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/f317f4d1-c4b7-4a19-8f13-cf6cbbde100dn%40chromium.org.
Liam Brady
Mike Taylor
Thanks for the design doc! The quote from kleber@ really helped me to understand the use case and developer need. It sounds like this is a small tweak to fenced frame event-level reporting, which is itself a temporary stepping stone on the path to a more private ads ecosystem. AIUI, this does not regress privacy by revealing the event data to more parties, just the event itself (by default).
Based on that, LGTM1 to ship.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d7ed7ec9-dcfb-4ec8-acba-5aad465aaeca%40chromium.org.
Rick Byers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_%2BqiXbfu%2BhspiS_CFwGGkgzAyZHbY_Z9R9J2JuCf4DRg%40mail.gmail.com.