> 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 <https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting-debugging/part-1/>, 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 <https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting-debugging/part-1/#debug-reports-are-cookie-based> that debug reports will go away at the point of third-party cookie deprecation. We have also documented <https://github.com/WICG/turtledove/pull/884> that these cookies will only be sent with automatic beacons when third-party cookies are enabled. On Wed, Nov 15, 2023 at 4:15 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > > > On Fri, Nov 10, 2023 at 10:23 PM 'Garrett Tanzer' via blink-dev < > blink-dev@chromium.org> wrote: > >> They should all be requested now. >> >> Thanks >> >> On Fri, Nov 10, 2023 at 3:45 PM Mike Taylor <miketa...@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 >>> >>> shivani...@chromium.org, jkar...@chromium.org, lbr...@google.com, >>> gtan...@google.com >>> >>> Explainer(s) >>> >>> https://github.com/WICG/turtledove/pull/884 >>> >>> Relevant issue: Don't disable cookie setting in ReportEvent API until >>> 3PCD <https://github.com/WICG/turtledove/issues/866> >>> >>> >>> 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 >>> <https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#support-for-attribution-reporting> >>> 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? > >> >>> 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 <https://github.com/WICG/turtledove/issues/822> >>> splits up automatic beacons into beacons sent on navigation start and >>> navigation commit. This change will apply to both. >>> >>> >>> >>> Blink component >>> >>> Blink>FencedFrames >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFencedFrames> >>> >>> 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 >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? >>> 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 >>> >>> -- >>> 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/CAFk1C%2BNZrECQ9atA9vbZxjFrVtnW-H6z4yPdUt_4nD1q%3Dot61g%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFk1C%2BNZrECQ9atA9vbZxjFrVtnW-H6z4yPdUt_4nD1q%3Dot61g%40mail.gmail.com?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/CACykZxqOWNtkLOwW71ZiG3Hu9G8xCyTi%2BcpJay1sZFtZ6UaTJQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACykZxqOWNtkLOwW71ZiG3Hu9G8xCyTi%2BcpJay1sZFtZ6UaTJQ%40mail.gmail.com?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/CACykZxpdWCx8d99RXR%3DKhy842e32eNdW5KGmPNTt4QgYdY4FxA%40mail.gmail.com.
