Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Chris Harrelson]

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
>>> ).
>>> 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.
>>>
>>> On Thu, May 9, 2024 at 12:19 PM Mike Taylor 
>>> 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  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 
 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
> 
> 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 

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Yoav Weiss (@Shopify)]

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 
>> ).
>>  
>> 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.
>>
>> On Thu, May 9, 2024 at 12:19 PM Mike Taylor  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  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  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 
 
  
 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 

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Mike Taylor]

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

).
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.

On Thu, May 9, 2024 at 12:19 PM Mike Taylor 
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
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
 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

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 

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

['Liam Brady' via blink-dev]

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 
> ).
>  
> 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.
>
> On Thu, May 9, 2024 at 12:19 PM Mike Taylor  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  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  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 
>>> 
>>>  
>>> 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 

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

['Liam Brady' via blink-dev]

>
> 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.

On Thu, May 9, 2024 at 12:19 PM Mike Taylor  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  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  wrote:
>
>> On 5/8/24 11:30 AM, 'Liam Brady' via blink-dev wrote:
>>
>> Contact emails
>>
>> lbr...@google.com, shivani...@chromium.org, jkar...@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.)
>>
>>
>> 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
>> 

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[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?


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  wrote:

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


Contact emails

lbr...@google.com ,
shivani...@chromium.org ,
jkar...@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.)



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 

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

['Liam Brady' via blink-dev]

>
> 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.

On Wed, May 8, 2024 at 1:27 PM Mike Taylor  wrote:

> On 5/8/24 11:30 AM, 'Liam Brady' via blink-dev wrote:
>
> Contact emails
>
> lbr...@google.com, shivani...@chromium.org, jkar...@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.)
>
>
> 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 

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Mike Taylor]

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


Contact emails

lbr...@google.com , shivani...@chromium.org 
, jkar...@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.)



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 
)

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

['Liam Brady' via blink-dev]

Contact emails

lbr...@google.com, shivani...@chromium.org, jkar...@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