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
<https://github.com/WICG/turtledove/pull/1386>
Note: reading explainer diffs is not great UX.
Specification
https://github.com/WICG/fenced-frame/pull/203
<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
<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/5a7060b2-205e-4646-b5a0-4794ac9d55bb%40chromium.org.
