LGTM3 On Wed, May 22, 2024 at 7:41 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> LGTM2 > > On Tuesday, May 21, 2024 at 2:11:37 PM UTC+2 Mike Taylor wrote: > >> 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? 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 <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 >>>>> >>>>> 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 >>>>> <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. >>>>> >>>>> 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 >>>>> >>>>> 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 >>>>> -- >>>>> 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 >>>>> <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/17ce2642-c4de-4d3a-b447-4d187f71f35fn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/17ce2642-c4de-4d3a-b447-4d187f71f35fn%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/CAOMQ%2Bw-VxcRJSHejeXJOCGgRS7oL4Dw7pc9_FgA7YL6QFbh6CA%40mail.gmail.com.
