Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

2024-01-24 Thread Daniel Bratell 

LGTM3

/Daniel

On 2024-01-24 11:45, Yoav Weiss (@Shopify) wrote:

LGTM2

On Tuesday, January 23, 2024 at 11:17:35 AM UTC+1 Mike Taylor wrote:

Thanks Liam. This seems fine to me given that both parties need to
opt in.

LGTM1

On 1/22/24 6:10 PM, Liam Brady wrote:

Hi Mike,

"crossOrigin=true" is just a typo. "crossOrigin" was the original
naming convention for "crossOriginExposed". It was renamed during
code review, but I forgot to update the I2S wording to match that.

We chose to not go with Permissions-Policy for a few reasons.
First is that for fenced frames created through something like
Protected Audience, they have a fixed list of permissions that
must be enabled for the frame to load, so refactoring that to
support one permissions policy that can be either enabled or
enabled would be a lot of effort. Doing that would also allow 1
bit of information to leak from the embedder to the fenced frame,
which is the whole reason we locked down permissions policies in
the first place. We also didn't want the embedder to have any
control over how this header is set (such as having an embedder
opt in on the frame's behalf), and since permissions policies are
based on inheritance, that was something we needed to avoid.
On Friday, January 19, 2024 at 3:43:44 PM UTC-5
mike...@chromium.org wrote:

Hi Liam,

On 1/16/24 3:49 PM, '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/904



Spec(s)

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



Summary

As part of the Privacy Sandbox experiment, we introduced a
way for beacons to be sent automatically if a top-level
navigation is initiated from within an ad frame

.
At the time, we restricted this feature to frames and
subframes that were same-origin to the root ad frame.
However, there is a use case that this is not able to
handle. With third-party ad serving (3PAS), the actual
contents of the ad (including links/click handlers) are
loaded in a cross-origin subframe. Because it is
cross-origin, the frame does not get access to the automatic
beacon API, and therefore is not able to report a top-level
navigation when a user clicks on the ad.


A cross-origin subframe can now opt in to sending automatic
beacons by setting a new response header:
"Allow-Fenced-Frame-Automatic-Beacons". The cross-origin
frame still cannot set automatic beacon data; instead, the
main ad frame will set the automatic beacon data, but opt in
to having the data be used for cross-origin automatic
beacons using a new "crossOrigin=true" parameter. When these
2 criteria are met, the cross-origin subframe will send an
automatic beacon when a top-level navigation happens.


Is "crossOrigin=true" different than the "crossOriginExposed"
boolean defined in the spec? Or just a typo?

Another question: is there any reason you chose to create a
new HTTP header, rather than use something like
Permissions-Policy? (Maybe that's not supported for fenced
frames?)



This feature will also fix a separate issue

brought
up externally and allow for ad components to opt into
sending automatic beacons without needing to invoke
setReportEventDataForAutomaticBeacons(); they instead will
just need to supply the
"Allow-Fenced-Frame-Automatic-Beacons" response header. This
will not remove the existing way for ad components to opt
into sending beacons.


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

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

2024-01-24 Thread Yoav Weiss (@Shopify) 
LGTM2

On Tuesday, January 23, 2024 at 11:17:35 AM UTC+1 Mike Taylor wrote:

> Thanks Liam. This seems fine to me given that both parties need to opt in.
>
> LGTM1
> On 1/22/24 6:10 PM, Liam Brady wrote:
>
> Hi Mike,
>
> "crossOrigin=true" is just a typo. "crossOrigin" was the original naming 
> convention for "crossOriginExposed". It was renamed during code review, but 
> I forgot to update the I2S wording to match that.
>
> We chose to not go with Permissions-Policy for a few reasons. First is 
> that for fenced frames created through something like Protected Audience, 
> they have a fixed list of permissions that must be enabled for the frame to 
> load, so refactoring that to support one permissions policy that can be 
> either enabled or enabled would be a lot of effort. Doing that would also 
> allow 1 bit of information to leak from the embedder to the fenced frame, 
> which is the whole reason we locked down permissions policies in the first 
> place. We also didn't want the embedder to have any control over how this 
> header is set (such as having an embedder opt in on the frame's behalf), 
> and since permissions policies are based on inheritance, that was something 
> we needed to avoid. 
> On Friday, January 19, 2024 at 3:43:44 PM UTC-5 mike...@chromium.org 
> wrote:
>
>> Hi Liam,
>> On 1/16/24 3:49 PM, '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/904
>>
>> Spec(s)
>>
>> https://github.com/WICG/fenced-frame/pull/133
>>
>> Summary
>>
>> As part of the Privacy Sandbox experiment, we introduced a way for 
>> beacons to be sent automatically if a top-level navigation is initiated 
>> from within an ad frame 
>> .
>>  
>> At the time, we restricted this feature to frames and subframes that were 
>> same-origin to the root ad frame. However, there is a use case that this is 
>> not able to handle. With third-party ad serving (3PAS), the actual contents 
>> of the ad (including links/click handlers) are loaded in a cross-origin 
>> subframe. Because it is cross-origin, the frame does not get access to the 
>> automatic beacon API, and therefore is not able to report a top-level 
>> navigation when a user clicks on the ad.
>>
>> A cross-origin subframe can now opt in to sending automatic beacons by 
>> setting a new response header: "Allow-Fenced-Frame-Automatic-Beacons". The 
>> cross-origin frame still cannot set automatic beacon data; instead, the 
>> main ad frame will set the automatic beacon data, but opt in to having the 
>> data be used for cross-origin automatic beacons using a new 
>> "crossOrigin=true" parameter. When these 2 criteria are met, the 
>> cross-origin subframe will send an automatic beacon when a top-level 
>> navigation happens.
>>
>> Is "crossOrigin=true" different than the "crossOriginExposed" boolean 
>> defined in the spec? Or just a typo?
>>
>> Another question: is there any reason you chose to create a new HTTP 
>> header, rather than use something like Permissions-Policy? (Maybe that's 
>> not supported for fenced frames?)
>>
>>
>> This feature will also fix a separate issue 
>>  
>> brought up externally and allow for ad components to opt into sending 
>> automatic beacons without needing to invoke 
>> setReportEventDataForAutomaticBeacons(); they instead will just need to 
>> supply the "Allow-Fenced-Frame-Automatic-Beacons" response header. This 
>> will not remove the existing way for ad components to opt into sending 
>> beacons.
>>
>> 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.
>>
>> Is this feature fully tested by web-platform-tests 
>> ?
>>  
>> Link to test suite results from wpt.fyi. 
>>
>> Yes. New automatic beacon tests have been added to test

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

2024-01-23 Thread Mike Taylor 

Thanks Liam. This seems fine to me given that both parties need to opt in.

LGTM1

On 1/22/24 6:10 PM, Liam Brady wrote:

Hi Mike,

"crossOrigin=true" is just a typo. "crossOrigin" was the original 
naming convention for "crossOriginExposed". It was renamed during code 
review, but I forgot to update the I2S wording to match that.


We chose to not go with Permissions-Policy for a few reasons. First is 
that for fenced frames created through something like Protected 
Audience, they have a fixed list of permissions that must be enabled 
for the frame to load, so refactoring that to support one permissions 
policy that can be either enabled or enabled would be a lot of effort. 
Doing that would also allow 1 bit of information to leak from the 
embedder to the fenced frame, which is the whole reason we locked down 
permissions policies in the first place. We also didn't want the 
embedder to have any control over how this header is set (such as 
having an embedder opt in on the frame's behalf), and since 
permissions policies are based on inheritance, that was something we 
needed to avoid.
On Friday, January 19, 2024 at 3:43:44 PM UTC-5 mike...@chromium.org 
wrote:


Hi Liam,

On 1/16/24 3:49 PM, '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/904



Spec(s)

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



Summary

As part of the Privacy Sandbox experiment, we introduced a way
for beacons to be sent automatically if a top-level navigation is
initiated from within an ad frame

.
At the time, we restricted this feature to frames and subframes
that were same-origin to the root ad frame. However, there is a
use case that this is not able to handle. With third-party ad
serving (3PAS), the actual contents of the ad (including
links/click handlers) are loaded in a cross-origin subframe.
Because it is cross-origin, the frame does not get access to the
automatic beacon API, and therefore is not able to report a
top-level navigation when a user clicks on the ad.


A cross-origin subframe can now opt in to sending automatic
beacons by setting a new response header:
"Allow-Fenced-Frame-Automatic-Beacons". The cross-origin frame
still cannot set automatic beacon data; instead, the main ad
frame will set the automatic beacon data, but opt in to having
the data be used for cross-origin automatic beacons using a new
"crossOrigin=true" parameter. When these 2 criteria are met, the
cross-origin subframe will send an automatic beacon when a
top-level navigation happens.


Is "crossOrigin=true" different than the "crossOriginExposed"
boolean defined in the spec? Or just a typo?

Another question: is there any reason you chose to create a new
HTTP header, rather than use something like Permissions-Policy?
(Maybe that's not supported for fenced frames?)



This feature will also fix a separate issue
brought
up externally and allow for ad components to opt into sending
automatic beacons without needing to invoke
setReportEventDataForAutomaticBeacons(); they instead will just
need to supply the "Allow-Fenced-Frame-Automatic-Beacons"
response header. This will not remove the existing way for ad
components to opt into sending beacons.


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.


Is this feature fully tested by web-platform-tests

?
Link to test suite results from wpt.fyi .

Yes. New automatic beacon tests have been added to test

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

2024-01-22 Thread 'Liam Brady' via blink-dev 
Hi Mike,

"crossOrigin=true" is just a typo. "crossOrigin" was the original naming 
convention for "crossOriginExposed". It was renamed during code review, but 
I forgot to update the I2S wording to match that.

We chose to not go with Permissions-Policy for a few reasons. First is that 
for fenced frames created through something like Protected Audience, they 
have a fixed list of permissions that must be enabled for the frame to 
load, so refactoring that to support one permissions policy that can be 
either enabled or enabled would be a lot of effort. Doing that would also 
allow 1 bit of information to leak from the embedder to the fenced frame, 
which is the whole reason we locked down permissions policies in the first 
place. We also didn't want the embedder to have any control over how this 
header is set (such as having an embedder opt in on the frame's behalf), 
and since permissions policies are based on inheritance, that was something 
we needed to avoid.
On Friday, January 19, 2024 at 3:43:44 PM UTC-5 mike...@chromium.org wrote:

> Hi Liam,
> On 1/16/24 3:49 PM, '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/904
>
> Spec(s)
>
> https://github.com/WICG/fenced-frame/pull/133
>
> Summary
>
> As part of the Privacy Sandbox experiment, we introduced a way for beacons 
> to be sent automatically if a top-level navigation is initiated from 
> within an ad frame 
> .
>  
> At the time, we restricted this feature to frames and subframes that were 
> same-origin to the root ad frame. However, there is a use case that this is 
> not able to handle. With third-party ad serving (3PAS), the actual contents 
> of the ad (including links/click handlers) are loaded in a cross-origin 
> subframe. Because it is cross-origin, the frame does not get access to the 
> automatic beacon API, and therefore is not able to report a top-level 
> navigation when a user clicks on the ad.
>
> A cross-origin subframe can now opt in to sending automatic beacons by 
> setting a new response header: "Allow-Fenced-Frame-Automatic-Beacons". The 
> cross-origin frame still cannot set automatic beacon data; instead, the 
> main ad frame will set the automatic beacon data, but opt in to having the 
> data be used for cross-origin automatic beacons using a new 
> "crossOrigin=true" parameter. When these 2 criteria are met, the 
> cross-origin subframe will send an automatic beacon when a top-level 
> navigation happens.
>
> Is "crossOrigin=true" different than the "crossOriginExposed" boolean 
> defined in the spec? Or just a typo?
>
> Another question: is there any reason you chose to create a new HTTP 
> header, rather than use something like Permissions-Policy? (Maybe that's 
> not supported for fenced frames?)
>
>
> This feature will also fix a separate issue 
>  
> brought up externally and allow for ad components to opt into sending 
> automatic beacons without needing to invoke 
> setReportEventDataForAutomaticBeacons(); they instead will just need to 
> supply the "Allow-Fenced-Frame-Automatic-Beacons" response header. This 
> will not remove the existing way for ad components to opt into sending 
> beacons.
>
> 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.
>
> Is this feature fully tested by web-platform-tests 
> ?
>  
> Link to test suite results from wpt.fyi. 
>
> Yes. New automatic beacon tests have been added to test cross-origin 
> beacons.
>
> automatic-beacon-cross-origin-false.https.html (test 
> )
>  
> (results 
> 
> )
>
>

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

2024-01-19 Thread Mike Taylor 

Hi Liam,

On 1/16/24 3:49 PM, '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/904 




Spec(s)

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




Summary

As part of the Privacy Sandbox experiment, we introduced a way for 
beacons to be sent automatically if a top-level navigation is 
initiated from within an ad frame 
. 
At the time, we restricted this feature to frames and subframes that 
were same-origin to the root ad frame. However, there is a use case 
that this is not able to handle. With third-party ad serving (3PAS), 
the actual contents of the ad (including links/click handlers) are 
loaded in a cross-origin subframe. Because it is cross-origin, the 
frame does not get access to the automatic beacon API, and therefore 
is not able to report a top-level navigation when a user clicks on the ad.



A cross-origin subframe can now opt in to sending automatic beacons by 
setting a new response header: "Allow-Fenced-Frame-Automatic-Beacons". 
The cross-origin frame still cannot set automatic beacon data; 
instead, the main ad frame will set the automatic beacon data, but opt 
in to having the data be used for cross-origin automatic beacons using 
a new "crossOrigin=true" parameter. When these 2 criteria are met, the 
cross-origin subframe will send an automatic beacon when a top-level 
navigation happens.


Is "crossOrigin=true" different than the "crossOriginExposed" boolean 
defined in the spec? Or just a typo?


Another question: is there any reason you chose to create a new HTTP 
header, rather than use something like Permissions-Policy? (Maybe that's 
not supported for fenced frames?)




This feature will also fix a separate issue 
brought 
up externally and allow for ad components to opt into sending 
automatic beacons without needing to invoke 
setReportEventDataForAutomaticBeacons(); they instead will just need 
to supply the "Allow-Fenced-Frame-Automatic-Beacons" response header. 
This will not remove the existing way for ad components to opt into 
sending beacons.



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.



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


Yes. New automatic beacon tests have been added to test cross-origin 
beacons.


automatic-beacon-cross-origin-false.https.html (test 
) 
(results 
)


automatic-beacon-cross-origin-navigation.https.html (test 
) 
(results 
)


automatic-beacon-cross-origin-no-data.https.html (test 
) 
(results 
)


automatic-beacon-cross-origin-no-opt-in.https.html (test 
) 
(results 
)


automatic-beacon-use-ancestor-data.https.html (test 
) 
(results