Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Liam Brady]

Contact emails

lbr...@google.com, shiva...@chromium.org, jka...@chromium.org

Explainer(s)

https://github.com/WICG/turtledove/pull/1134

Spec(s)

https://github.com/WICG/fenced-frame/pull/152

Summary

Ad frames (both fenced frames and urn-iframes) created through a Protected Audience auction, as well as their same-origin nested iframes, are allowed to call reportEvent() API to send event-level reports. It's also important for third-parties on Protected Audience-created ads to have the same measurement and reporting capabilities for spam detection, brand safety, and measurement verification. However, the API as it exists currently has a same-origin child iframe restriction which poses a complication as described below.

If an ad buyer wins an ad auction and its ad frame is displayed on a page, it might choose to embed a subframe that points to a third-party server that hosts the actual ad instead. With this use case, and with the current state of the reportEvent() API, the actual ad's document cannot directly call reportEvent() the way that its embedder can since the document is in a cross-origin nested iframe. Instead, it has to get its embedder to actually send the beacon by letting the embedder know via a postMessage. This will not be an ergonomic solution for this use case.

With this change, a cross-origin subframe can opt in to sending reportEvent() beacons using its ancestor's reporting metadata by calling reportEvent() with the parameter crossOriginExposed=true. This is the same syntax as is currently used by the main render URL frame to opt in to sending cross-origin automatic beacons with data (this means the FenceEvent IDL will stay the same).

The main ad render URL frame will opt in with a new "Allow-Cross-Origin-Event-Reporting" response header. Its valid values will be true and false, and will default to false when omitted. This will not be required for documents that are same-origin to the FencedFrameConfig's mapped url.

This is a convenience change (not privacy impacting), as it's already possible (but cumbersome) for the third-party to postMessage the parent frame to send the report on their behalf. For security reasons, the proposal requires opt-ins from both the main ad frame and the cross-origin iframe.

Blink component

Blink>FencedFrames

TAG reviews and status

Fenced frames existing TAG review appended with these spec changes https://github.com/w3ctag/design-reviews/issues/838#

Link to Origin Trial feedback summary

No Origin Trial performed

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Supported on all the above platforms except Android WebView.

Debuggability

Additional debugging capabilities are not necessary for these feature changes.

Risks

Compatibility

This is an added functionality and is backward compatible.

Interoperability

There are no interoperability risks as no other browsers have decided to implement these features yet. We have not received any standards positions from Mozilla or Webkit.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi. 

Yes. New reportEvent() beacon tests have been added to test cross-origin beacons.

fence-report-event-cross-origin-content-initiated.https.html (test) (results)

fence-report-event-cross-origin-nested-urn-iframe.https.html (test) (results)

fence-report-event-cross-origin-nested.https.html (test) (results)

fence-report-event-cross-origin-no-embedder-opt-in.https.html (test) (results)

fence-report-event-cross-origin-no-subframe-opt-in.https.html (test) (results)

fence-report-event-cross-origin-urn-iframe-content-initiated.https.html (test) (results)

fence-report-event-cross-origin-urn-iframe-no-embedder-opt-in.https.html (test) (results)

fence-report-event-cross-origin-urn-iframe-no-subframe-opt-in.https.html (test) (results)

fence-report-event-cross-origin-urn-iframe.https.html (test) (results)

fence-report-event-cross-origin.https.html (test) (results)

fence-report-event-sub-fencedframe.https.html (test) (results)

WPT directory for Fenced Frames: https://github.com/web-platform-tests/wpt/tree/master/fenced-frame

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5113611084365824

Links to previous Intent discussions

Fenced Frame Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ 

Fenced Frame Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/y6G3cvKXjlg/m/Lcpmpi_LAgAJ 

Fenced Frame Intent to ship:

https://groups.google.com/a/chromium.org/g/blink-dev/c/tpw8wW0VenQ/m/mePLTiHlDQAJ

[Eli Grey]

This change would impact the ability of first parties to regulate and prevent reportEvent beacons. Although this requires mutual opt-in, I expect scenarios to eventually come up where a site owner wants to allow cross-origin reportEvent only for certain origins.

[Mike Taylor]

On 5/8/24 11:30 AM, 'Liam Brady' via blink-dev wrote:

Contact emails

lbr...@google.com, shiva...@chromium.org, jka...@chromium.org

Explainer(s)

https://github.com/WICG/turtledove/pull/1134

Spec(s)

https://github.com/WICG/fenced-frame/pull/152

Summary

Ad frames (both fenced frames and urn-iframes) created through a Protected Audience auction, as well as their same-origin nested iframes, are allowed to call reportEvent() API to send event-level reports. It's also important for third-parties on Protected Audience-created ads to have the same measurement and reporting capabilities for spam detection, brand safety, and measurement verification. However, the API as it exists currently has a same-origin child iframe restriction which poses a complication as described below.

If an ad buyer wins an ad auction and its ad frame is displayed on a page, it might choose to embed a subframe that points to a third-party server that hosts the actual ad instead. With this use case, and with the current state of the reportEvent() API, the actual ad's document cannot directly call reportEvent() the way that its embedder can since the document is in a cross-origin nested iframe. Instead, it has to get its embedder to actually send the beacon by letting the embedder know via a postMessage. This will not be an ergonomic solution for this use case.

With this change, a cross-origin subframe can opt in to sending reportEvent() beacons using its ancestor's reporting metadata by calling reportEvent() with the parameter crossOriginExposed=true. This is the same syntax as is currently used by the main render URL frame to opt in to sending cross-origin automatic beacons with data (this means the FenceEvent IDL will stay the same).

The main ad render URL frame will opt in with a new "Allow-Cross-Origin-Event-Reporting" response header. Its valid values will be true and false, and will default to false when omitted. This will not be required for documents that are same-origin to the FencedFrameConfig's mapped url.

Can you clarify what the type is for this new header? It reads as if you're adding a String Item that looks like a boolean, rather than a Boolean Item. Is that correct? It doesn't seem to be actually defined in the spec. 

(I filed https://github.com/WICG/fenced-frame/issues/158 for that.)

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/adafffdd-cebf-4ad9-9df2-18b75571c6ban%40chromium.org.

[Liam Brady]

Can you clarify what the type is for this new header? It reads as if you're adding a String Item that looks like a boolean, rather than a Boolean Item. Is that correct? It doesn't seem to be actually defined in the spec. 

This is meant to be a string literal that is either "true" or "false". I have a spec PR up to formally define that and remove any confusion over what values it's expecting. Thanks for calling this out!

This change would impact the ability of first parties to regulate and prevent reportEvent beacons. Although this requires mutual opt-in, I expect scenarios to eventually come up where a site owner wants to allow cross-origin reportEvent only for certain origins.

To clarify the first party piece, control over sending reportEvent() beacons rests within the worklet owner that invokes registerAdBeacon()/registerAdMacro() i.e. seller/ buyer and the document loaded with the main ad renderURL (i.e. the buyer/advertisers). The first-party (i.e. the publishers) don't have control over reportEvent() beacons since that is considered part of the overall Protected Audience API, and this feature doesn't change that.

[Mike Taylor]

On 5/9/24 12:13 PM, Liam Brady wrote:

Can you clarify what the type is for this new header? It reads as if you're adding a String Item that looks like a boolean, rather than a Boolean Item. Is that correct? It doesn't seem to be actually defined in the spec. 

This is meant to be a string literal that is either "true" or "false". I have a spec PR up to formally define that and remove any confusion over what values it's expecting. Thanks for calling this out!

Can I ask why string literal vs boolean?

[Liam Brady]

Can I ask why string literal vs boolean?

I had done this to match the convention already being used for other Protected Audience-related response headers (such as Ad-Auction-Allowed/X-Allow-FLEDGE). At the time of implementation, I wasn't aware of the preferred boolean convention of "?0" and "?1" defined in RFC8941. Even though this isn't what's preferred, I think it should still be fine to keep in place for now, and being consistent with the rest of the Protected Audience API is always a plus.

[Liam Brady]

Thanks for your feedback on this intent! We plan on modifying the "Allow-Cross-Origin-Event-Reporting" response header to accept a boolean instead of a string literal to match the preferred convention for response headers.

[Mike Taylor]

Thanks Liam!

LGTM1 to ship.

[Yoav Weiss (@Shopify)]

LGTM2

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17ce2642-c4de-4d3a-b447-4d187f71f35fn%40chromium.org.