Hi Daniel, On Wed, Nov 15, 2023 at 6:09 PM Daniel Bratell <bratel...@gmail.com> wrote:
> You say Q1 2024, but do you know a more exact date? I ask because we are > entering the holiday freeze period when companies do no changes whatsoever > and even if this makes a site want to fix something, they might not be able > to until some time into the quarter. > we're currently planning for early Jan, i.e. M120 would be the first release that contains the technical capabilities to ramp to 1% (breakage mitigations, quantitative testing). The holiday freeze is definitely a risk to call out here. However, as mentioned in the intent, we're already operating under the assumption that some sites, despite our outreach efforts, will only find out about this once the deprecation begins. To help with that, we have a number of temporary mitigations available that work quickly and effectively and can be initiated by various stakeholders in this process (site, user, browser). While not directly relevant to the web platform pieces, we plan to have user interface controls to give temporary exceptions per top-level site in Chrome. > > I also think it might be good to split it into the 1% part, and a 100% > part since it is hard to judge the web compatibility level already and that > is part of what the 1% run will do. > The 1% is a long-running testing period that we're doing as part of the commitments we entered with the CMA. However, from a readiness / web platform perspective, we'd really like to treat it with the same seriousness and care that we would treat a full rollout, as 1% of users (over a significant amount of time) should not have a greatly degraded user experience. We're trying to ship the full array of breakage mitigations we will have available for potential future rollouts in this phase as well. So, if possible, I'd prefer to discuss any concerns you might have about web compatibility, mitigations and ecosystem readiness in this thread, rather than pushing it further out. :) Thanks, Johann > /Daniel > On 2023-11-13 17:52, David Dabbs wrote: > > Thanks for the explanation. > > David > > > On Monday, November 13, 2023 at 9:30:55 AM UTC-6 Johann Hofmann wrote: > >> Hey David, yeah, that was me trying to fix the entry not showing up on >> API Owner dashboards. I don't think that was what fixed it though, so I can >> change it back to "In Developer Trial" (which feels like the most accurate >> right now?) >> >> Thanks! >> >> Johann >> >> >> On Mon, Nov 13, 2023, 16:10 David Dabbs <david...@epsilon.com> wrote: >> >>> This morning's Implementation status change to *Deprecated* results in >>> >>> Deprecate Third-Party Cookies >>> <https://chromestatus.com/feature/5133113939722240> (Deprecated) >>> >>> Did you intend to also rename the feature to "Third-Party Cookies?" >>> >>> >>> Thanks >>> >>> >>> >>> On Monday, November 13, 2023 at 4:20:47 AM UTC-6 yoav...@chromium.org >>> wrote: >>> >>>> LGTM1 >>>> >>>> I cannot imagine a more thorough and thoughtful approach than the one >>>> the Privacy Sandbox team has taken to tackle this significant change to the >>>> web's privacy model while minimizing breakage and providing replacement >>>> APIs. Thanks for pushing this important work through!! >>>> >>>> On Mon, Nov 13, 2023 at 10:31 AM Johann Hofmann <joha...@chromium.org> >>>> wrote: >>>> >>>>> Contact emails >>>>> >>>>> joha...@chromium.org, wande...@chromium.org, dylan...@chromium.org, >>>>> kaust...@chromium.org, jka...@chromium.org, john...@chromium.org >>>>> >>>>> Explainer >>>>> >>>>> For general information on Privacy Sandbox for the Web and Google’s >>>>> plans to phase out third-party cookies, see >>>>> https://privacysandbox.com/open-web/. >>>>> >>>>> For additional information on the planned semantics of third-party >>>>> cookie blocking and its interaction with the SameSite cookie attribute, >>>>> see >>>>> https://github.com/DCtheTall/standardizing-cross-site-cookie-semantics >>>>> >>>>> >>>>> Specification >>>>> >>>>> The Cookies RFC contains some language >>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-12#name-the-cookie-header-field> >>>>> that, in theory, allows user agents to block third-party cookies, leaving >>>>> a >>>>> lot of details unspecified. We are not happy with this status quo and are >>>>> collaborating with other browsers on a significant spec refactoring effort >>>>> called cookie layering >>>>> <https://github.com/httpwg/http-extensions/issues/2084> to give >>>>> Fetch/HTML more responsibility over specifying how and when cookies are >>>>> stored and attached, as well as a WebAppSec Note based on our existing >>>>> explainer >>>>> <https://github.com/DCtheTall/standardizing-cross-site-cookie-semantics> >>>>> that describes how cookie blocking interacts with SameSite cookies. >>>>> >>>>> Summary >>>>> >>>>> We intend to deprecate and remove default access to third-party (aka >>>>> cross-site) cookies as part of the Privacy Sandbox Timeline for the >>>>> Web >>>>> <https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline>, >>>>> starting with an initial 1% testing period in Q1 2024 >>>>> <https://developer.chrome.com/docs/privacy-sandbox/chrome-testing/>, >>>>> followed by a gradual phaseout planned to begin in Q3 2024 after >>>>> consultation >>>>> with the CMA >>>>> <https://www.gov.uk/cma-cases/investigation-into-googles-privacy-sandbox-browser-changes> >>>>> (The gradual phaseout is subject to addressing any remaining competition >>>>> concerns of the UK’s Competition and Markets Authority.) >>>>> >>>>> Phasing out third-party cookies (3PCs) is a central effort to the >>>>> Privacy Sandbox initiative, which aims to responsibly reduce cross-site >>>>> tracking on the web (and beyond) while supporting key use cases through >>>>> new >>>>> technologies. Our phaseout plan was developed with the UK's Competition >>>>> and >>>>> Markets Authority, in line with the commitments >>>>> <https://blog.google/around-the-globe/google-europe/path-forward-privacy-sandbox/> >>>>> we offered for Privacy Sandbox for the web. >>>>> >>>>> Blink component >>>>> >>>>> Internals>Network>Cookies >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies> >>>>> >>>>> Motivation >>>>> >>>>> Our goal on the Privacy Sandbox is to reduce cross-site tracking while >>>>> still enabling the functionality that keeps online content and services >>>>> freely accessible by everyone. Deprecating and removing third-party >>>>> cookies >>>>> encapsulates the challenge, as they enable critical functionality across >>>>> sign-in, fraud protection, advertising, and generally the ability to embed >>>>> rich, third-party content in websites—but at the same time they're also a >>>>> key enabler of cross-site tracking. >>>>> >>>>> Initial public proposal >>>>> >>>>> N/A >>>>> >>>>> TAG review >>>>> >>>>> The TAG has explicitly endorsed >>>>> <https://w3ctag.github.io/web-without-3p-cookies/#why-restrict-third-party-cookies> >>>>> (n.b. as a draft document) the deprecation of third-party cookies in the >>>>> past. Additionally, we requested feedback on our proposal to define >>>>> the 3PC security semantics >>>>> <https://github.com/w3ctag/design-reviews/issues/904> and received >>>>> generally positive feedback. >>>>> >>>>> TAG review status >>>>> >>>>> Tentatively Positive, see above >>>>> >>>>> Risks >>>>> Compatibility >>>>> >>>>> Impact on the Ads ecosystem: >>>>> >>>>> A suite of APIs for delivering relevant ads, measuring ad performance, >>>>> and preventing fraud and abuse are now generally available in Chrome to >>>>> continue to facilitate ad-supported content on the web. We continue to >>>>> work >>>>> closely with the UK Competition and Markets Authority (CMA) on evaluating >>>>> the impact of this change on the ads ecosystem. >>>>> >>>>> Web Compatibility: >>>>> >>>>> Despite 3PCs already being blocked in Firefox and Safari and developer >>>>> outreach efforts to raise awareness and encourage developers to prepare >>>>> for >>>>> the deprecation, we currently estimate that a non-trivial number of sites >>>>> are still relying on third-party cookies for some user-facing >>>>> functionality. To address this breakage, we have developed a two-pronged >>>>> strategy: >>>>> >>>>> >>>>> 1. >>>>> >>>>> Breakage Discovery & Outreach >>>>> >>>>> Through various efforts, such as UKM-based signal analysis, scaled >>>>> manual testing and dogfooding, we are collecting a list of impacted use >>>>> cases. These individual breakage cases inform our mitigation strategy (see >>>>> next step) and future API improvements, as well as our ongoing developer >>>>> outreach efforts. >>>>> >>>>> We also offer developers the ability to report 3PC breakage to the >>>>> Chrome team via goo.gle/report-3pc-broken or ask general questions at >>>>> https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues >>>>> . >>>>> >>>>> >>>>> 1. >>>>> >>>>> Temporary Breakage Mitigation >>>>> >>>>> It will take time for developers to replace their usage of 3PCs with >>>>> new APIs or different approaches, and some developers may not be aware of >>>>> this deprecation until they discover breakage. In order to reduce the >>>>> impact of such breakage on the web, we have implemented a series of >>>>> temporary mitigations: >>>>> >>>>> >>>>> - >>>>> >>>>> Exemption Heuristics >>>>> >>>>> <https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md>: >>>>> We are planning to ship heuristics mirroring those that already ship in >>>>> Firefox and Safari, and are also working with both browsers on a >>>>> coordinated removal process. Additional details can be found & should >>>>> be >>>>> discussed in the I2P >>>>> >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Eeh2pE0DRaE/m/1BJyBlCUAAAJ> >>>>> & upcoming I2S. >>>>> >>>>> >>>>> >>>>> - >>>>> >>>>> Deprecation Trial: >>>>> >>>>> <https://developer.chrome.com/blog/cookie-countdown-2023oct/#request-additional-time-with-the-third-party-deprecation-trial-for-non-advertising-use-cases> >>>>> This will be outlined in more detail in the upcoming Request for >>>>> Deprecation Trial, but it’s important to note that a review step >>>>> including >>>>> evidence of user-facing breakage will be required for participation. >>>>> Further, we do not intend to approve trials for ads-related use cases, >>>>> to >>>>> avoid interference with the quantitative testing. >>>>> >>>>> >>>>> >>>>> - >>>>> >>>>> As with other launches, we will also have a set of server-side >>>>> controls to manage the rollout as a whole and minimize issues specific >>>>> sites are causing for users. >>>>> >>>>> >>>>> Despite all these efforts, we want to be clear that we are >>>>> intentionally taking some risk here in the interest of user privacy. >>>>> >>>>> Enterprise Compatibility: >>>>> >>>>> To help with the transition, we intend to allow enterprise >>>>> organizations to opt their applications out of third-party cookie blocking >>>>> using the existing BlockThirdPartyCookies >>>>> <https://chromeenterprise.google/policies/#BlockThirdPartyCookies> or >>>>> CookiesAllowedForUrls >>>>> <https://chromeenterprise.google/policies/#CookiesAllowedForUrls> >>>>> policies. Given that enterprise systems are often gated and are therefore >>>>> hard to analyze from an external perspective, these policies will provide >>>>> additional time for the enterprise ecosystem to adapt. We intend to >>>>> publish >>>>> additional guidance for enterprises on https://goo.gle/3pcd-enterprise >>>>> for the period beyond the 1% testing period. >>>>> >>>>> Interoperability >>>>> >>>>> Both Firefox and Safari have removed default access to third-party >>>>> cookies already, though there are small differences >>>>> <https://github.com/DCtheTall/standardizing-cross-site-cookie-semantics> >>>>> in how browsers treat SameSite=None cookies in so called “ABA” scenarios >>>>> (site A embeds site B, which embeds site A again). Chrome ships the more >>>>> secure and more restrictive variant, and from initial conversations we are >>>>> optimistic that other browsers will adopt it as well. There are also >>>>> subtle >>>>> differences in how browsers restore access to third-party cookies through >>>>> mechanisms such as heuristics or custom quirks. Where Chrome implements >>>>> similar measures (such as the heuristics >>>>> <https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md>), >>>>> we try to follow the launch and standards processes to achieve as much >>>>> interop as we can, given other requirements such as privacy and security. >>>>> >>>>> Gecko: Shipping >>>>> >>>>> WebKit: Shipping >>>>> >>>>> Web developers: Mixed Signals >>>>> >>>>> As one of the most impactful changes to the web platform in a long >>>>> time, the deprecation of 3rd party cookies and the introduction of >>>>> alternative APIs have received a lot of helpful feedback from web >>>>> developers to an extent impossible to summarize in a few sentences. As >>>>> described in the summary, the Privacy Sandbox wants to ensure that a >>>>> vibrant, freely accessible web can exist even as we roll out strong user >>>>> protections and we will continue to work with web developers to understand >>>>> their use cases and ship the right (privacy-preserving) APIs. And we’ve >>>>> received feedback >>>>> <https://privacysandbox.com/news/privacy-sandbox-for-the-web-reaches-general-availability/#:~:text=The%20Benefits%20of%20Collaboration> >>>>> that gives us confidence that we’re on the right track. >>>>> >>>>> WebView application risks >>>>> >>>>> This deprecation will not affect WebView for now. >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> Developers may use the command-line testing switch >>>>> --test-third-party-cookie-phaseout >>>>> (available starting Chrome 115) or enable >>>>> chrome://flags#test-third-party-cookie-phaseout (available starting >>>>> Chrome 117), to simulate browser behavior with default access to >>>>> third-party cookies removed. We also started reporting DevTools issues for >>>>> cookies impacted by the deprecation starting in Chrome 117 to help >>>>> identify >>>>> potentially impacted workflows. We are continuing to improve our developer >>>>> documentation >>>>> <https://developer.chrome.com/blog/cookie-countdown-2023oct/> on >>>>> debugging third-party cookies usage, and guidance on migration to new >>>>> APIs. >>>>> >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? >>>>> >>>>> Yes. We have put together a set of WPTs >>>>> <https://wpt.fyi/results/cookies/third-party-cookies/third-party-cookies.tentative.https.html?label=experimental&label=master&aligned> >>>>> which cover third-party cookie blocking for subresource requests. It is >>>>> not >>>>> yet comprehensive, we are working on adding additional tests to support >>>>> our >>>>> standardization efforts. >>>>> >>>>> Flag name on chrome://flags >>>>> >>>>> TestThirdPartyCookiePhaseout >>>>> >>>>> Finch feature name >>>>> >>>>> Due to the nature of the Chrome-facilitated testing period >>>>> <https://developer.chrome.com/docs/privacy-sandbox/chrome-testing/>, >>>>> as well as the general complexity of managing breakage related to removing >>>>> third-party cookies, there won’t be a single Finch feature that takes us >>>>> from 0% to 100% deprecated. Instead, a collection of features, supporting >>>>> different phases and components, will be used. >>>>> >>>>> Non-finch justification >>>>> >>>>> N/A >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> No, the base third-party cookie blocking functionality does not >>>>> require Chrome code. Some custom Chrome functionality (such as the >>>>> aforementioned facilitated testing, mitigations and user experience >>>>> improvements) does require it. >>>>> >>>>> Estimated milestones >>>>> >>>>> Initial phase of Deprecation (1%) is planned as part of the “Chrome >>>>> facilitated testing period” beginning in Q1 2024, as described on >>>>> https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline, >>>>> further phaseout is planned to begin in Q3 2024. (The gradual phaseout of >>>>> third-party cookies is subject to addressing any remaining competition >>>>> concerns of the CMA.) >>>>> >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5133113939722240 >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>> -- >>>>> 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/CAD_OO4ikogMJZce42o-QcGUMDNiM2Lr_6BGAfP8Gzktakc5_fw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4ikogMJZce42o-QcGUMDNiM2Lr_6BGAfP8Gzktakc5_fw%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/1d705388-c7ff-46ad-9d4e-db6276b8035an%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1d705388-c7ff-46ad-9d4e-db6276b8035an%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4ispE4%2Bj-YsxyyxHU%2BGAJ8honiS0feV4zgf_4R_ZJq9MA%40mail.gmail.com.
