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 <agertenb...@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/CAD_OO4is_2Cqm8mMOnii9XWBb2gHqo9U-TrEAQoTaHu%3Drk7AUg%40mail.gmail.com.
