OK - makes sense to me.
LGTM1
On 3/26/25 10:29 AM, Liam Brady wrote:
> 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
<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/b98de584-836d-44cb-bccb-b6cb2ae92586%40chromium.org.
