That is great news, thank you for the update! We appreciate the review and action, it will absolutely help us ensure a smoother and more seamless transition for our clients.
Thanks, Adam On Tuesday, December 26, 2023 at 11:18:43 AM UTC-5 Kaustubha Govind wrote: > Hi Adam, > > Just FYI, we are in the process of setting up a first-party deprecation > trial (applicable to non-advertising usecases only) as you requested. > Please see this thread > <https://groups.google.com/a/chromium.org/g/blink-dev/c/yGUdvW_t_y0/m/DafsVzHFAQAJ> > > for details. > > K > > On Thursday, December 7, 2023 at 6:43:27 AM UTC-5 Johann Hofmann wrote: > >> Hi Adam, >> >> Thank you for the detailed feedback. I'm discussing with the team and >> will follow up here. >> >> Thanks, >> >> Johann >> >> On Tue, Dec 5, 2023, 17:17 Adam Gertenbach <agert...@axisgroup.com> >> wrote: >> >>> Good morning all, >>> >>> Our organization is currently re-reviewing the impacts of the third >>> party cookie deprecation now that registration for deprecation trials have >>> been made available. Among our offerings, we provide consulting, hosting, >>> architecture, and development services for customers in the business >>> intelligence and enterprise analytics space, including Microsoft Power BI, >>> Qlik Sense, ThoughtSpot, and Tableau. The ability to provide embedding of >>> analytics capabilities, such as visualizations and dashboards, is common >>> across the industry and is supported by each of the major vendors; as such, >>> we've facilitated these capabilities in architecting and building solutions >>> for our customers, often using these embedding capabilities to create >>> custom solutions or enhance enterprise portals that have seen very large >>> adoption. >>> >>> >>> https://help.qlik.com/en-US/sense-developer/November2023/Content/Sense_Helpsites/embed-qlik-sense.htm >>> >>> https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-embed-secure >>> https://docs.thoughtspot.com/cloud/latest/intro-embed >>> https://help.tableau.com/current/pro/desktop/en-us/embed.htm >>> >>> As one might expect, these embedded solutions are often reliant on a >>> combination of iframes and cross domain third-party cookies to supply >>> authentication and authorization and cannot be made to operate under a >>> single domain. While we intend to actively engage with these vendors to >>> notify them of expected breakage due to the pending deprecation and would >>> hope that options for partitioning/CHIPS will make its way into these >>> products in a timely fashion, there is a significant risk that existing >>> solutions will be impacted in the interim period; furthermore, the customer >>> perception around this breakage is likely to impact our reputation based on >>> our role in delivery, despite the fact that we do not and cannot directly >>> resolve the underlying cause without third-party participation and product >>> updates. >>> >>> Historically, resolution of these types of issues have not always been >>> proactive. Qlik Sense had to update their interfaces as the SameSite None >>> rollout was occurring due to customer breakage ( >>> https://community.qlik.com/t5/Official-Support-Articles/Missing-SameSite-attribute-blocks-requests-in-Chrome-80-and/ta-p/1712551 >>> >>> ). More recently, Microsoft's Power BI login process for embedded reports >>> broke in September when the third-party storage partitioning policies were >>> enabled due to their use of cross-window localStorage usage for signaling >>> during authentication. Not knowing that this was in use by their product, >>> mitigation of this issue involved an all-nighter investigation on our part >>> to understand what was happening and the enrollment of a first-party >>> deprecation trial by us to re-enable services for our customers. >>> >>> While I recognize the motivations behind the strategies outlined, the >>> lack of a first-party deprecation trial to provide wide-spread temporary >>> mitigation is likely to significantly impair our service offerings and >>> existing customer solutions while these issues are ironed out and >>> implemented by these vendors. We're hoping to prepare our customers through >>> proactive messaging where possible (enterprise policy, anticipated per-user >>> UI overrides, etc.) but I'd like to call out this scenario and see if >>> there's anything I'm missing in terms of short-term solutions available to >>> us, and to ask if a first-party deprecation trial offering is expected for >>> cases like these where influence on the owners of third-party embeds is >>> limited. >>> >>> On Tuesday, November 21, 2023 at 7:56:58 PM UTC-5 Rick Byers wrote: >>> >>>> LGTM2 - It's time. >>>> >>>> Given that this is our biggest breaking change ever and I've gotten >>>> some feedback saying at least a couple people appreciate it when I expand >>>> on my thought process in compat analysis, I figured I should take the time >>>> to try to systematically evaluate this against our blink compat >>>> principles >>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.83o2xr8ayal6>. >>>> >>>> Hopefully we'll learn some things from how this deprecation goes in >>>> practice to help us further improve our framework for evaluating and >>>> mitigating future compat risk. >>>> >>>> - *Minimizing end-user impact* >>>> - *Page views impacted: High risk* >>>> - The UseCounter >>>> >>>> <https://chromestatus.com/metrics/feature/timeline/popularity/3408> >>>> has been steady at around 46% for years. Clearly a huge risk from >>>> our first >>>> line of reasoning. >>>> - *Unique sites impacted: High risk* >>>> - I don't have a pointer to data handy, but I assume it's >>>> also very large (eg. due to 3p embeds like ads). >>>> - *Severity of breakage: Moderate risk* >>>> - One argument is that most sites already need to work for >>>> all the Safari and Firefox users and the X% of Chrome users with >>>> 3P cookies >>>> disabled, and so have adapted. >>>> - But on the other hand we have plenty of examples of sites >>>> which just tell users they must enable 3PCs to make the site >>>> function at >>>> all. >>>> - So I think we have to say that there are a non-trivial >>>> number sites where the severity is total site breakage - >>>> necessitating all >>>> the mitigations, even if most impacted sites have non-visible >>>> breakage. >>>> - *Chrome's release process: Moderate mitigation* >>>> - This change is under very careful finch control with tons >>>> of monitoring. >>>> - We also have a variety of feedback channels including the >>>> manual breakage reporting Johann mentioned, as well as monitoring >>>> of user >>>> behavior to infer breakage, and a pretty big team motivated to >>>> react >>>> quickly to keep user impact to a minimum. >>>> - One thing to be mindful of here is that the CMA-mandated 1% >>>> experiment will place some limits on the team's options to >>>> respond to >>>> reports of breakage (eg. the deprecation trial says it can't be >>>> used by >>>> sites on the disconnect.me advertising list). >>>> - *User opt-out: Very strong mitigation* >>>> - I've been playing with the cookie control UI (eg. see >>>> screenshot below) on my personal account and I'm quite happy with >>>> it. I've >>>> seen the user education directing me to this UI including in >>>> scenarios like >>>> when I reload a page. Some of that may be experiments or things >>>> undergoing >>>> design change (I don't actually know the specific plans, just >>>> commenting on >>>> what I've experienced personally), but it gives me confidence >>>> that the team >>>> is seriously working to educate users on how to opt-out in the >>>> case of >>>> breakage. >>>> [image: image.png] >>>> - *Maximizing user experience* >>>> - *Security & Privacy: Strong mitigation* >>>> - Personally it seems clear to me (and eg. the W3C TAG >>>> <https://www.w3.org/2001/tag/doc/web-without-3p-cookies>) >>>> that 3PCs being off is the right long-term default for the web in >>>> the name >>>> of privacy. >>>> - In addition I believe there's some security benefit - eg. >>>> making side-channel attacks for sharing data between frames less >>>> useful to >>>> attackers >>>> - *Performance: Weak mitigation* >>>> - You could argue that sites will be faster without 3PCs, but >>>> I suspect that's temporary. >>>> - Perhaps more importantly, the deprecation of 3PCs creates >>>> pressure to raise the level of abstraction of the web and I think >>>> history >>>> has shown that we can make the web faster the more sites operate >>>> at a >>>> higher level of abstraction (eg. consider scrolling/animation >>>> being >>>> JS-driven vs. browser-driven and the rise of threaded compositing >>>> with >>>> mobile browsers and how web advertising might look 5-10 years >>>> from now). >>>> - *User annoyance: Weak mitigation* >>>> - Maybe a risk of some increase in annoyance - eg. need >>>> popups for some things that used to work in-page via iframes. >>>> - Certainly having to turn 3PCs back on for a site that >>>> doesn't work otherwise will be annoying >>>> - I'd also argue that, like for performance, raising the >>>> level of abstraction will give us more opportunity to reduce >>>> annoyance. Eg. >>>> users will have more centralized and consistent control over >>>> their >>>> advertising preferences. >>>> - *Minimizing web-developer impact* >>>> - *Ease of adaptation: Moderate mitigation* >>>> - Key functional scenarios like identity have well known and >>>> long-used alternatives like pop-ups and redirects. Chrome >>>> adopting the >>>> temporary heuristics already used successfully by other browsers >>>> seems like >>>> a significant mitigation for these flows to me. >>>> - The requestStorageAccess API is a drop-in option in many >>>> scenarios (again, already deployed for other browsers) >>>> - Advertising use cases require a lot more work to adapt to, >>>> but massive effort has gone into (and will presumably keep going >>>> into) >>>> building and validating these alternatives. >>>> - *Developer opt-in / opt-out: Strong mitigation* >>>> - The deprecation trial seems like a big mitigation to me - >>>> pretty easily giving non-ads origins an extra year. >>>> - The prior move to require SameSite=None also seems like a >>>> significant mitigation, developers have effectively been opting >>>> into 3PCs >>>> in chromium for three years! >>>> - There's also been an effort to variety of mechanisms and >>>> tools for developers to opt-in to 3PCD and validate their site >>>> works >>>> - *Enterprise policy opt-out: Moderate mitigation* >>>> - Policy control exists. Given the scope of potential impact >>>> in enterprises, this still seems like an area of some risk to me >>>> (eg. BYOD >>>> scenarios with Chromium-only custom apps). But again the user >>>> opt-out is a >>>> huge mitigation for this risk. >>>> - *Debuggability: Moderate mitigation* >>>> - Purpose-built tools A variety of tools have been built to >>>> help developers understand and adapt their cookie usage. Still >>>> cookies can >>>> be complicated, there's no silver bullet. >>>> - *Outreach: Moderate mitigation* >>>> - Almost certainly more outreach than we've ever done for a >>>> deprecation (even Flash!), yet still not so much as to avoid the >>>> likelihood of some developers being surprised. This is a place >>>> one could >>>> always argue for more work, but it's hard to know where the point >>>> of >>>> diminishing returns is, especially prior to the slow roll-out >>>> even >>>> starting. I expect this is something we'll learn more about >>>> during the 1% >>>> experiment period to guide the ramp-up process after that. >>>> - *Maximizing web ecosystem benefit* >>>> - *Interoperability: Strong mitigation* >>>> - The other two major engines have disabled 3PCs by default >>>> for some time. I'm personally uncomfortable with 3PC-related >>>> breakage being >>>> a reason why developers might encourage users to use >>>> chromium-based >>>> browsers. Restoring interoperability across browsers seems like >>>> strong >>>> motivation for accepting some risk here. >>>> - The team has gone the extra mile to advance specs, write >>>> WPTs and generally work to move the web away from UA-specific >>>> heuristics to >>>> a new likely interoperable and standardized state wrt. cookie >>>> behavior >>>> - *Standards conformance: Weak mitigation* >>>> - No standard requires 3PCD, but it seems likely that future >>>> web standards will be built under the assumption of 3PCs being >>>> unavailable >>>> (lots of such specs in development on a standards track) >>>> - *IP rights: Not relevant* >>>> - *Accepted interop risk: Not relevant* >>>> >>>> Overall it seems to me like the high risks are appropriately balanced >>>> by significant mitigations and justifications for accepting the cost of >>>> the >>>> risk. More importantly, every technical tool in our web compat toolbox has >>>> been brought to bear on mitigating the risks, and significant resources >>>> are >>>> devoted to monitoring and responding to any issues. I both trust the team >>>> to effectively manage the risk during roll-out and expect that there will >>>> be some bumps and mistakes that we will want to learn from. >>>> >>>> Best of luck! >>>> Rick >>>> >>>> On Wed, Nov 15, 2023 at 5:43 PM Johann Hofmann <joha...@chromium.org> >>>> wrote: >>>> >>>>> Hi Daniel, >>>>> >>>>> On Wed, Nov 15, 2023 at 6:09 PM Daniel Bratell <brat...@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+...@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+...@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 >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4ispE4%2Bj-YsxyyxHU%2BGAJ8honiS0feV4zgf_4R_ZJq9MA%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/60ada932-2675-43b0-8c40-a025d799ca16n%40chromium.org.
