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/62dc98b8-09c6-4352-be86-18087d548a89n%40chromium.org.

Reply via email to