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/1710ec26-bd1a-4167-b492-e58748248b5bn%40chromium.org.
