LGTM3, but please fill out the vendor signals part in your chromestatus
entry (at least pointing to the parent fenced frame requests - I don't
think you need to file new ones here).
On 12/11/24 11:16 AM, Chris Harrelson wrote:
LGTM2
On Wed, Dec 11, 2024 at 7:41 AM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
LGTM1
On Tuesday, December 3, 2024 at 1:32:58 PM UTC+1 lbr...@google.com
wrote:
There's no feature request for this, but this is something
that we anticipate developers are going to want access to,
especially after allowing cross-origin documents to send
reporting beacons. Since requests are generally sent with some
sort of referrer header today on the web platform, we
anticipate that developers will have the expectation that
reporting beacons are also sent with a referrer header
(assuming the referrer policy allows it), and this launch will
align the implementation with those expectations.
We considered putting this information in the "Origin" header,
but decided against that as we had concerns that it could be
used for cross-site request forgery (i.e. the cross-site
document sends a beacon that looks like it was sent from the
top-level ad frame). The other alternative would be to not
include anything and require the documents to "self-report"
where they came from in the payload, but since they'd be able
to put any arbitrary information in the payload, that method
would not be reliable enough to be useful.
I've also flipped the last 3 review bits.
On Monday, December 2, 2024 at 8:50:26 PM UTC-5
mike...@chromium.org wrote:
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, shiva...@chromium.org,
jka...@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+...@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/66f897bd-a60e-4ba4-9038-62dcf1459ef6n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66f897bd-a60e-4ba4-9038-62dcf1459ef6n%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/0bb44197-29de-4ed2-99ad-422db8899ebf%40chromium.org.
