Intent to Ship: Protected Audience - Do Not Disable Cookie Setting in ReportEvent until 3PCD (Chrome - 120)

[Garrett Tanzer]

Intent to Ship: Protected Audience - Do Not Disable Cookie Setting in ReportEvent until 3PCD (Chrome - 120)

Contact emails

shiva...@chromium.org, jka...@chromium.org, lbr...@google.com, gta...@google.com 

Explainer(s)

https://github.com/WICG/turtledove/pull/884 

Relevant issue: Don't disable cookie setting in ReportEvent API until 3PCD

Spec(s):

Since this change is only temporarily allowing cookies in the automatic beacons and the functionality change will be deprecated with 3PCD and it respects 3PC preferences as cookies do today, it is not added to the spec.

Summary

We launched Fenced Frames for Protected Audience as a part of Chrome 115. With this change, we are temporarily un-disabling credentials on the automatic beacons initiated from a fenced frame (or urn iframe) until 3rd party cookie deprecation (3PCD) to help with adoption.

Details

We received a request (https://github.com/WICG/turtledove/issues/866) to not disable credentials on automatic beacon reports until 3PCD for both fenced frames and urn-iframes, with higher priority for urn iframes. This will help adtech in running experiments on Protected Audience. For example, the Attribution Reporting API’s verbose debugging feature requires cookies to be set in headers, so it is currently broken for automatic beacons. 

With this change, we will switch the credentials mode for automatic beacons only from CredentialsMode::kOmit to CredentialsMode::kInclude. Please note: 

• This will be gated behind a check that 3rd party cookies are enabled. This has the effect of respecting current user preferences and automatically disabling the change at 3PCD.

• A parallel change splits up automatic beacons into beacons sent on navigation start and navigation commit. This change will apply to both.

Blink component

Blink>FencedFrames

TAG reviews and status

N/A since there are no spec changes.

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

There are no compatibility risks, since existing receiving servers can choose to not use the cookies.

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.

No. This is tested in browser tests. This will not become a part of web-standard, so we are not adding any additional tests in the web-platform. Links for the original tests are below. 

WPT 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/5170880732987392 

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ 

Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/y6G3cvKXjlg/m/Lcpmpi_LAgAJ 

Intent to ship:

https://groups.google.com/a/chromium.org/g/blink-dev/c/tpw8wW0VenQ/m/mePLTiHlDQAJ

[Mike Taylor]

Hi Garrett,

Would you mind requesting each of the review gates in the chromestatus entry?

thanks,
Mike

--
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/CAFk1C%2BNZrECQ9atA9vbZxjFrVtnW-H6z4yPdUt_4nD1q%3Dot61g%40mail.gmail.com.

[Garrett Tanzer]

They should all be requested now.

Thanks

[Yoav Weiss]

On Fri, Nov 10, 2023 at 10:23 PM 'Garrett Tanzer' via blink-dev <blin...@chromium.org> wrote:

They should all be requested now.

Thanks

On Fri, Nov 10, 2023 at 3:45 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Garrett,

Would you mind requesting each of the review gates in the chromestatus entry?

thanks,
Mike

On 11/7/23 12:24 PM, Garrett Tanzer wrote:

Intent to Ship: Protected Audience - Do Not Disable Cookie Setting in ReportEvent until 3PCD (Chrome - 120)

Contact emails

shiva...@chromium.org, jka...@chromium.org, lbr...@google.com, gta...@google.com 

Explainer(s)

https://github.com/WICG/turtledove/pull/884 

Relevant issue: Don't disable cookie setting in ReportEvent API until 3PCD

Spec(s):

Since this change is only temporarily allowing cookies in the automatic beacons and the functionality change will be deprecated with 3PCD and it respects 3PC preferences as cookies do today, it is not added to the spec.

Summary

We launched Fenced Frames for Protected Audience as a part of Chrome 115. With this change, we are temporarily un-disabling credentials on the automatic beacons initiated from a fenced frame (or urn iframe) until 3rd party cookie deprecation (3PCD) to help with adoption.

Can you explain more how this would help with adoption?

Wouldn't this create a false sense of "security" amongst early adopters and cause them to rely on those cookies up until their deprecation? 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACykZxqOWNtkLOwW71ZiG3Hu9G8xCyTi%2BcpJay1sZFtZ6UaTJQ%40mail.gmail.com.

[Garrett Tanzer]

> Can you explain more how this would help with adoption?

Allowing for cookies on the beacons lets testers utilize Attribution Reporting API’s debug reports, which are helpful for migrating to the new API. These reports are gated on third party cookie availability. It also enables testers to experiment with a single API at a time (e.g., verify that Protected Audiences with existing measurement methods works as intended and then add in ARA reporting) which allows for simpler experiments with greater understanding of the impact of each.

> Wouldn't this create a false sense of "security" amongst early adopters and cause them to rely on those cookies up until their deprecation?

We make it abundantly clear in our documentation that debug reports will go away at the point of third-party cookie deprecation. We have also documented that these cookies will only be sent with automatic beacons when third-party cookies are enabled. 

[Yoav Weiss]

LGTM1

Thanks for the explanation!!

[Mike Taylor]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9584d1eb-3145-4277-9677-003ff2c54b3e%40chromium.org.