LGTM2 On Fri, May 24, 2024 at 5:53 PM Anton Maliev <[email protected]> wrote:
> I see the concern. The 3P can use document.hasStorageAccess() > <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasStorageAccess> > to > check for cookie support, which accounts for the grace period and opt-out. > (It would return true if there is an active grace period on the 1P or 3P > that affects the current frame, or false if the current client is opted > out.) Per the linked I2S, we recommend document.hasStorageAccess() instead > of navigator.cookieEnabled moving forward for validation relating to > Chrome's 3PCD rollout - the latter doesn't return the correct value for > this case. Thanks! That makes sense. > > This also depends if the 3P in question is also on the grace period. If it > is not, we would expect them to notice any breakage on other 1Ps as well. > > On Thursday, May 23, 2024 at 4:17:14 PM UTC-4 Yoav Weiss wrote: > >> On Thu, May 16, 2024 at 4:15 PM Anton Maliev <[email protected]> >> wrote: >> >>> > Will developers have a way of knowing if the current site (where they >>> may see breakage metrics) is opted-out of the grace period? >>> >>> Google is planning to build a site dashboard where developers can check >>> on the status of their grace period and opt-out values. In the interim, >>> Chrome DevTools shows an Issue for third-party cookies which are allowed >>> due to the grace period - this can be used to validate whether the grace >>> period is active for that particular client. >>> >>> >> While that's potentially useful, that's not what I had in mind. >> If a site opt-outs of the grace period, that may impact 3Ps that the site >> embeds. >> Those 3Ps (if they are not ready for it) are likely to notice some drop >> in their functionality or conversion, but they'd need a way of attributing >> that to the lack of 3P cookies. >> >> At the same time, while writing this, I was reminded of >> navigator.cookieEnabled >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/xU3gTW4aTfg/m/LaUu7IN2BAAJ?utm_medium=email&utm_source=footer>. >> Do I understand correctly that it would indicate the lack of 3P cookie >> support in these cases? >> >> >> >>> > Do you have a rough estimate on the length of the grace period? (I'm >>> guessing this will not be relevant after it) >>> >>> That's correct, a site will no longer need an opt-out file after it is >>> removed from the grace period. Each grace period entry has its own >>> expiration date, depending on when the site applied for the deprecation >>> trial. We will need to assess the demand for new sites onboarding to the >>> trial before we can give an estimate on how long we will continue to >>> support grace periods overall. >>> >>> On Thursday, May 16, 2024 at 3:56:15 AM UTC-4 Yoav Weiss wrote: >>> >>>> This is an odd one, but I agree that it's a web exposed feature and >>>> hence should go through the blink process. Thanks for sending this! >>>> >>>> >>>> On Tue, May 14, 2024 at 11:15 PM Anton Maliev <[email protected]> >>>> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected] >>>>> >>>>> [email protected] >>>>> >>>>> [email protected] >>>>> >>>>> Explainer >>>>> >>>>> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out >>>>> >>>>> Specification >>>>> >>>>> Well-known resource specification: >>>>> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out/blob/main/well-known-specification.md >>>>> >>>>> Summary >>>>> >>>>> This proposal details a new mechanism for site developers to conduct a >>>>> self-service staged opt-out of their third-party cookie phaseout grace >>>>> period. This is intended primarily for Chrome’s active trials for >>>>> third-party cookie deprecation - one for top-level sites >>>>> <https://developers.google.com/privacy-sandbox/3pcd/temporary-exceptions/first-party-deprecation-trial> >>>>> and one for embedded sites >>>>> <https://developers.google.com/privacy-sandbox/3pcd/temporary-exceptions/third-party-deprecation-trial>. >>>>> When a site is approved for one of these trials, they are added to a >>>>> short-term grace period which mitigates breakage until the token is >>>>> launched. Sites may also use this opt-out to test long term solutions. >>>>> >>>>> Each site on the trial will specify their desired opt-out percentage >>>>> in a new resource in their .well-known directory >>>>> <https://datatracker.ietf.org/doc/html/rfc8615>, specified here >>>>> <https://github.com/explainers-by-googlers/3pcd-deprecation-trial-staged-rollout/blob/main/well-known-specification.md>. >>>>> Google will implement server infrastructure to fetch and update these >>>>> values on a schedule, and assign clients randomly to cohorts matching this >>>>> percentage. These cohorts persist for a client up until clearing site >>>>> storage or reinstalling the browser. >>>>> >>>> >>>> >>>> Will developers have a way of knowing if the current site (where they >>>> may see breakage metrics) is opted-out of the grace period? >>>> >>>> >>>> >>>>> >>>>> Blink component >>>>> >>>>> Privacy <https://b.corp.google.com/components/1457231> >>>>> >>>>> TAG review >>>>> >>>>> N/A >>>>> >>>>> TAG review status >>>>> >>>>> N/A >>>>> >>>>> Risks >>>>> >>>>> There aren’t inherent security implications for fetching external >>>>> resources using server-side infrastructure, but there is a risk of >>>>> fetching >>>>> bad data, which our implementation addresses. >>>>> >>>>> There are also privacy implications for randomly assigning clients to >>>>> cohorts, which we mitigate by clearing cohorts on site data deletion. >>>>> There >>>>> is also a risk that the fetching system fails or that a site loses access >>>>> to its .well-known resource, both cases which we have planned mitigations >>>>> for. >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> The third-party cookie deprecation trials are a Chrome feature, so >>>>> these new well-known resources will only be fetched by the Chrome browser. >>>>> The new resource will be distinct and will not interfere with any existing >>>>> resources used by other browsers or features. >>>>> >>>> >>>> Beyond that, I think that the fact that this is a short-lived >>>> capability also significantly reduces risk. >>>> Do you have a rough estimate on the length of the grace period? (I'm >>>> guessing this will not be relevant after it) >>>> >>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> >>>>> No >>>>> >>>>> Debuggability >>>>> >>>>> N/A >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>> >>>>> All except WebView. (Third-party cookie deprecation launches don’t >>>>> include WebView.) >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> No >>>>> >>>>> Flag name on chrome://flags >>>>> >>>>> N/A >>>>> >>>>> Finch feature name >>>>> >>>>> base::features::TpcdMetadataStageControl >>>>> >>>>> Non-finch justification >>>>> >>>>> N/A >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> No. All code for the grace period and new staged opt-out handling is >>>>> in //components/tpcd/metadata >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/tpcd/metadata/> >>>>> . >>>>> >>>>> Estimated milestones >>>>> >>>>> Client support is shipping to M125 on May 14. Server-side file >>>>> processing will begin some time after that date. A separate notice will >>>>> be >>>>> sent when that process begins. >>>>> >>>>> Anticipated spec changes >>>>> >>>>> None >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5205350707101696 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> Intent to prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/O9mh5XvbqqE/m/IyK22zHkAAAJ >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODhGg7m2ARTr5%3DxE0Jex1bcmQ2ySUZRa%3DJSWpW6UuX56sD5Yg%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODhGg7m2ARTr5%3DxE0Jex1bcmQ2ySUZRa%3DJSWpW6UuX56sD5Yg%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 [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25be1203-c642-426a-bfeb-27592e50e113n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25be1203-c642-426a-bfeb-27592e50e113n%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJif6nxD4S5hcwoO%3DB1vSzHBphr0E%3DxuzLxRHBfVsbk9g%40mail.gmail.com.
