Thanks Liam! LGTM1 to ship.
On 5/20/24 3:51 PM, Liam Brady wrote:
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.On Thursday, May 9, 2024 at 1:21:43 PM UTC-4 Liam Brady wrote: 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 <https://source.chromium.org/chromium/chromium/src/+/main:content/services/auction_worklet/public/cpp/auction_downloader.cc;l=413-429;drc=b8ddddd3dfef89a597a4e89d8cc76bcf8a15d655>). At the time of implementation, I wasn't aware of the preferred boolean convention of "?0" and "?1" defined in RFC8941 <https://www.rfc-editor.org/rfc/rfc8941#name-booleans>. 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. On Thu, May 9, 2024 at 12:19 PM Mike Taylor <mike...@chromium.org> wrote: 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? Itdoesn'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 <https://github.com/WICG/fenced-frame/pull/159>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?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. On Wed, May 8, 2024 at 1:27 PM Mike Taylor <mike...@chromium.org> wrote: 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 <https://github.com/WICG/turtledove/pull/1134> Spec(s) https://github.com/WICG/fenced-frame/pull/152 <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 <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-preregistered-destination-url>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.)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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFencedFrames> TAG reviews and status Fenced frames existing TAG review appended with these spec changes https://github.com/w3ctag/design-reviews/issues/838# <https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1792881253> 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 <https://github.com/mozilla/standards-positions/issues/781>or Webkit <https://github.com/WebKit/standards-positions/issues/173>. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? Link to test suite results from wpt.fyi <https://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 <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-content-initiated.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-content-initiated.https.html>) fence-report-event-cross-origin-nested-urn-iframe.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-nested-urn-iframe.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-nested-urn-iframe.https.html>) fence-report-event-cross-origin-nested.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-nested.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-nested.https.html>) fence-report-event-cross-origin-no-embedder-opt-in.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-no-embedder-opt-in.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-no-embedder-opt-in.https.html>) fence-report-event-cross-origin-no-subframe-opt-in.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-no-subframe-opt-in.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-no-subframe-opt-in.https.html>) fence-report-event-cross-origin-urn-iframe-content-initiated.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-urn-iframe-content-initiated.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-urn-iframe-content-initiated.https.html>) fence-report-event-cross-origin-urn-iframe-no-embedder-opt-in.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-urn-iframe-no-embedder-opt-in.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-urn-iframe-no-embedder-opt-in.https.html>) fence-report-event-cross-origin-urn-iframe-no-subframe-opt-in.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-urn-iframe-no-subframe-opt-in.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-urn-iframe-no-subframe-opt-in.https.html>) fence-report-event-cross-origin-urn-iframe.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin-urn-iframe.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin-urn-iframe.https.html>) fence-report-event-cross-origin.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-cross-origin.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-cross-origin.https.html>) fence-report-event-sub-fencedframe.https.html (test <https://github.com/web-platform-tests/wpt/blob/master/fenced-frame/fence-report-event-sub-fencedframe.https.html>) (results <https://wpt.fyi/results/fenced-frame/fence-report-event-sub-fencedframe.https.html>) WPT directory for Fenced Frames: https://github.com/web-platform-tests/wpt/tree/master/fenced-frame <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 <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 <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 <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 <https://groups.google.com/a/chromium.org/g/blink-dev/c/tpw8wW0VenQ/m/mePLTiHlDQAJ>-- You received this message because you are subscribed tothe 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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/adafffdd-cebf-4ad9-9df2-18b75571c6ban%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e7dcac8-5f6c-420e-993f-23274a2af95c%40chromium.org.
