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/12c691ac-4460-4420-92bc-05a7256cefbbn%40chromium.org.
