One other request: can you please request enterprise, debuggability, and
test bits in your chromestatus entry?
On 12/2/24 9:51 AM, Mike Taylor wrote:
On 11/28/24 6:41 AM, 'Liam Brady' via blink-dev wrote:
Contact emails
lbr...@google.com <mailto:lbr...@google.com>, shivani...@chromium.org
<mailto:shivani...@chromium.org>, jkar...@chromium.org
<mailto:jkar...@chromium.org>
Specification
https://github.com/WICG/fenced-frame/pull/164
<https://github.com/WICG/fenced-frame/pull/164>
Summary
Reporting beacons (e.g. reportEvent to preregistered destination URLs
<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-preregistered-destination-url>,
automatic beacon events
<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#registeradbeacon-1>,
and reportEvent to custom destination URL with substitution of
preregistered macros
<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-custom-destination-url-with-substitution-of-preregistered-macros>)
will have their "Referer" header set to the initiating frame's
origin. This is a strictly additive change, as the "Referer" header
is currently unpopulated for all fenced frame event-level reports.
However, the referrer could be manually added today by callers of
reportEvent in the eventData
<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#example>or
destinationURL
<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#example-1>fields
of events.
We plan on introducing cross-origin support for reportEvent() beacons
<https://groups.google.com/a/chromium.org/g/blink-dev/c/CrUxPVSscW0>and
have previously introduced the same support for automatic beacons
<https://groups.google.com/a/chromium.org/g/blink-dev/c/byT9ygyWlo0/m/-WsSYjPcAQAJ>.
When this happens, event-level reports will be able to be sent from
origins other than the root ad frame's origin. However, a server
currently can't tell where an event-level report originates, since
the referrer is unset and the "Origin" header is set to the worklet
origin
<https://chromium-review.googlesource.com/c/chromium/src/+/5037514/21/content/browser/fenced_frame/fenced_frame_reporter.cc#451>for
reportEvent() with destination enum
<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-preregistered-destination-url>and
Automatic beacon
<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#registeradbeacon-1>events.
Giving a server this information will allow it to make a more
informed decision on how to handle reporting beacons originating from
documents that are cross-origin to the root ad frame. To align with
expectations for how the referrer header behaves, the referrer policy
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy>will
be set to the policy of the document that initiates the beacon.
This summary is useful - and I guess this last paragraph is the
closest thing to an explainer. But it's still missing some useful
info. Can you elaborate a bit more on the developer need you're trying
to address (i.e., do we have feature requests for this)? Are there any
issues you can point to? Alternatives considered, etc?
Blink component
Blink>InterestGroups
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups>
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>.
Link to Origin Trial feedback summary
No Origin Trial performed
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: No signal
WebKit: No signal
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. The existing event reporting WPTs have been modified to check
for the new header values.
Flag name on about://flags
None
Finch feature name
None
Requires code in //chrome?
False
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6246671997730816
<https://chromestatus.com/feature/6246671997730816>
--
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/24147311-a037-4fe1-8596-a1ea5ca1033fn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/24147311-a037-4fe1-8596-a1ea5ca1033fn%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/39d2ceee-781f-4367-be3a-ea920b9f1862%40chromium.org.
