What is the receive-cookie-deprecation cookie?
This cookie is an opt-in flag, defined by Google Chrome's Privacy Sandbox and set by participating (mostly advertising) third parties, that enables a site to receive Chrome's Sec-Cookie-Deprecation label used during testing of the third-party cookie phase-out.
Table of Contents
About receive-cookie-deprecation
| Vendor | |
|---|---|
| Category Category The functional category of the technology, such as Web Analytics or Social Media. Learn more | Heatmap & Recording |
| Consent Category Consent Category The consent category this cookie most commonly falls under across sites we scan, normalized into four standard categories. Learn more | Targeting & Advertising |
| Prevalence | Very Common |
| Popularity Popularity Popularity is calculated from our dataset of 4.5B+ cookies analyzed across hundreds of millions of web pages. Learn more | Found on 20.1% of scanned pages |
| Expiration Type | Mixed |
| Party Type Party Type Whether the cookie is first-party or third-party. Learn more | 3rd-Party |
| Risk Level Risk Level Rates how sensitive the data stored by this cookie is (High, Medium, or Low) based on data classification and distribution. Learn more | Medium |
| Vendor Privacy Policy | https://policies.google.com/privacy |
| Vendor Website | https://www.google.com |
What is the purpose of receive-cookie-deprecation?
The receive-cookie-deprecation cookie is part of Google Chrome's "Chrome-facilitated testing" of third-party cookie deprecation within the Privacy Sandbox initiative. According to Google's Chrome documentation, a site must set this cookie before Chrome will return the Sec-Cookie-Deprecation request header (also exposed via a JavaScript API), which carries the browser's experiment-group label (e.g., Mode A/Mode B control or treatment groups). The cookie must use the Partitioned attribute, so opting in to receive the label is scoped per top-level site. The cookie itself simply carries a flag value (e.g., "1") and is not a unique user identifier.
Although the cookie name and mechanism are defined by Google Chrome, in practice the cookie is set across the domains of many independent third-party ad-tech vendors observed deploying it (for example DoubleClick/Google, Rubicon Project/Magnite, Conversant/Epsilon, AdRoll, Criteo, Index Exchange, Taboola, and others). These vendors set it so they can detect, via the deprecation label, whether a browser is in a cohort that has third-party cookies restricted, allowing them to preview and evaluate how their ad targeting, measurement, and site features behave once third-party cookies are limited. Note that this is a temporary testing mechanism that Chrome has announced it will wind down (the Sec-Cookie-Deprecation header and associated JavaScript API are being deprecated).
What are the Privacy Risks of receive-cookie-deprecation?
Risk Level: Medium
The cookie itself carries only a flag value rather than directly identifiable personal information or a unique user ID, which on its own would suggest low risk. However, it is set within the cross-site third-party advertising ecosystem (ad exchanges, ad servers, and programmatic platforms) and is used to expose a browser's inclusion in Chrome's cookie-deprecation experiment cohorts to those ad-tech parties. Because it is part of behavioral advertising infrastructure operating across many domains, it carries a medium privacy risk typical of ad-tech signaling, even though the cookie value is not a persistent personal identifier.
How to Remove receive-cookie-deprecation from a Website
To stop this cookie from being set, site administrators must audit their site for the third-party advertising, measurement, and monetization tags (for example Google/DoubleClick, Rubicon/Magnite, Index Exchange, Criteo, AdRoll, Conversant, or Taboola) that participate in Chrome-facilitated cookie-deprecation testing. Because the cookie is set dynamically by these third-party scripts as part of the testing opt-in, it cannot be disabled through a single first-party website setting. The administrator must remove the responsible third-party tags/scripts from the site's source code or tag manager, or ask the relevant vendor whether they offer an account-level configuration to opt out of "Chrome-facilitated testing" / Privacy Sandbox deprecation testing so their tag stops setting the cookie. If a given vendor sets this cookie as an intrinsic part of its service and offers no such toggle, it cannot be removed without removing that vendor's service entirely.