> Why does that override the need to send the header? The intention is to have the cross-origin subframe's document explicitly opt in to the automatic beacon transaction. This is done in order to safeguard the click event itself, not just the data that would be attached to the beacon. If that cross-origin subframe document calls setReport...(), its intention is that it wants to send an automatic beacon and send it with the data provided. Since this function call implies an explicit intention to use the automatic beacon API, we decided to treat the frame invoking the function as it opting in, and if it already has opt in through setReport...(), we didn't think there was a need for it to opt in again through the header.
The header's main purpose is for the case when the cross-origin subframe doesn't want to provide data to be used, but still wants an automatic beacon to be sent out when it performs a top-level navigation. On Wed, Mar 26, 2025 at 9:41 AM Mike Taylor <miketa...@chromium.org> wrote: > On 3/25/25 11:04 AM, Liam Brady wrote: > > > Note: reading explainer diffs is not great UX. > > Ack. I'll avoid linking explainer diffs directly in the future. > > This section in the FFAR explainer doc > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#cross-origin-support> > should be a much more readable version of what I linked. > > Perfect, thank you. > > One thing I'm having a hard time following: in order for the cross-origin > automatic beacons to work, you need both a top-level frame to send `ACAER: > true`, and the cross-origin embedded frame to send `AFFAB: true`. > > But then there's mention of the situation where AFFAO:true isn't needed > <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#cross-origin-support:~:text=negating%20the%20need%20for%20the%20document%20to%20be%20served%20with%20the%20Allow%2DFenced%2DFrame%2DAutomatic%2DBeacons%3A%20true%20header.> > (because the cross-origin document set `crossOriginExposed: true` within > `setReportEventDataForAutomaticBeacons()`. > > Why does that override the need to send the header? > > > > Is it expected that Canary is failing all 4 tests? > > Yes. Most fenced frame tests are currently failing on wpt.fyi > <https://wpt.fyi/results/fenced-frame?label=experimental&label=master&aligned> > because > they rely on the FencedFrameConfig constructor (see: > chrome://flags#enable-fenced-frames-developer-mode) that is not enabled > by default. This feature will be enabled by default once we launch fenced > frames with local unpartitioned data access > <https://chromestatus.com/feature/5072963051454464>, and the tests should > start passing then. Note that these tests are all passing on the Chromium > build bots where the feature is turned on. > > Makes sense, thanks. > > > On Monday, March 24, 2025 at 9:54:40 AM UTC-4 mike...@chromium.org wrote: > >> On 3/19/25 1:16 PM, 'Liam Brady' via blink-dev wrote: >> >> Contact emails >> >> lbr...@google.com, shiva...@chromium.org, jka...@chromium.org >> >> Explainer >> >> https://github.com/WICG/turtledove/pull/1386 >> >> Note: reading explainer diffs is not great UX. >> >> Specification >> >> https://github.com/WICG/fenced-frame/pull/203 >> >> Summary >> >> This change allows descendant documents of fenced frames to set the root >> fenced frame’s automatic beacon reporting data, regardless of origin. Both >> the root fenced frame and the cross-origin data setting document must opt >> in for this to be allowed. >> >> More detail: >> >> Fenced frames or URN iframes, if loaded through an API like Protected >> Audience or Shared Storage, can send out reporting beacons automatically if >> some event occurs (currently only top-level navigation beacons are >> supported). We previously tweaked this feature to allow cross-origin >> documents loaded in the root fenced frame's tree to send automatic beacons >> if opted in, but still kept the restriction that only frames that are >> same-origin to the origin loaded by the API could set the data that would >> be sent as part of the beacon. >> >> The existing setup assumes that payload data will only ever come from the >> buyer directly. However, there are cases where a buyer embeds a >> cross-origin subpage that contains data that needs to be sent with an >> automatic beacon. This limitation forces the same-origin root document to >> be an intermediary between the page with the data and the automatic beacon >> API, causing unnecessary extra overhead and forcing extra data to be sent >> directly to the root fenced frame. >> >> To support this use case while still ensuring security guarantees (mainly >> that a given frame's data cannot be sent across origins without its >> consent), both the fenced frame root document and the cross-origin subframe >> document must explicitly opt in. This is the same opt-in shape as other >> cross-origin Fenced Frame Ads Reporting >> <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md> >> features. Specifically, the root frame must opt in via the >> "Allow-Fenced-Frame-Automatic-Beacons" header, and the cross-origin >> subframe setting the data must opt in via the 'crossOriginExposed' >> parameter in the call to setReportEvent...(). >> >> This does not change the privacy story nor does it introduce a privacy >> regression, as cross-origin subframes can currently postMessage() data to >> the root that the root frame can then use as automatic beacon data. Both >> the existing capability as well as the proposed changes involve the root >> fenced frame document and the cross-origin subframe document opting-in to >> this sharing. >> >> Blink component >> >> Blink>FencedFrames >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EFencedFrames%22> >> >> TAG review >> >> None >> >> TAG review status >> >> Not applicable. This feature relates to Protected Audience whose review >> TAG has already resolved with an "unsatisfied" position >> <https://github.com/w3ctag/design-reviews/issues/723>. >> >> Risks >> >> Interoperability and Compatibility >> >> This is an added functionality and is backward compatible. There are no >> interoperability risks as no other browsers have decided to implement these >> features yet. >> >> Gecko: Negative on fenced frames >> <https://github.com/mozilla/standards-positions/issues/781> >> >> WebKit: No signal >> <https://github.com/WebKit/standards-positions/issues/173> >> >> Web developers: No signals >> >> Other signals: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> Not applicable as this will not be supported on Android WebView. >> >> >> Debuggability >> >> Additional debugging capabilities are not necessary for these feature >> changes. >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)? >> >> Supported on all the above platforms except Android WebView. >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> Yes. See: wpt.fyi link >> <https://wpt.fyi/results/fenced-frame?label=master&label=experimental&aligned&q=automatic-beacon-data> >> . >> >> Is it expected that Canary is failing all 4 tests? >> >> >> Flag name on about://flags >> >> None >> >> Finch feature name >> >> FencedFramesCrossOriginAutomaticBeaconData >> >> Requires code in //chrome? >> >> False >> >> Estimated milestones >> >> Shipping on desktop >> >> 135 >> >> Shipping on Android >> >> 135 >> >> >> Anticipated spec changes >> >> None >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5121048142675968?gate=5185729511292928 >> >> -- >> 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 visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c1bf85f1-93ad-4b8f-b191-84c6dfeffaa9n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c1bf85f1-93ad-4b8f-b191-84c6dfeffaa9n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> >> -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BA0o602diowbLnu%3Djhug%3DD4dszw2VR9wZ14TMPH7GTVSzgR9A%40mail.gmail.com.
