Cookie Status

The cookiestatus.com website is a knowledge sharing resource for the various tracking protection mechanisms implemented by the major browsers and browser engines.

For more information about the service, please consult the FAQ.

Please submit suggestions and corrections as issues in the GitHub project. Click here to find your way.

Current status

Changes added in the latest release of each browser are indicated with yellow highlight. You can click the icon to be redirected to the respective section in each browser’s own “Current Status” page.

Last updated: 21 Nov 2024
Chrome storage partitioning added.

Suggest an edit

Toggle full screen

Brave Chrome Edge Firefox Safari
Mechanism Shields n/a Tracking prevention Enhanced Tracking Protection (ETP) Intelligent Tracking Prevention (ITP)
Deployed in 0.55.18 n/a 78.0.276.8 69.0 Safari 11
Latest release Link Link Link Link Link
Default protection mode Default Shield settings n/a Balanced Standard ITP enabled
Classification of “known trackers” Multiple filter lists n/a Trust Protection Lists (with engagement and organization mitigation) Disconnect.me Algorithmic
Cookies in 3rd party context

Restrict access in subresource requests.

Partitioned access in frame.

Partitioned storage is cleared when no more first-party documents that use the partition are open, or when the browser is closed.

Cookies restricted to a maximum lifetime of 400 days. Access restricted for known trackers.

Access restricted for known trackers.

Cookies are partitioned between the site and the third-party. Cookies are not shared across sites.

All access restricted, except with Storage Access API.

Cookies in 1st party context

For cookies set with document.cookie, expiration set to 7 days.

Otherwise maximum expiry set to 6 months.

Cookies restricted to a maximum lifetime of 400 days. No restrictions. All storage is purged from known trackers daily, unless the user has interacted with the site in first-party context within the last 45 days.

For cookies set with document.cookie, deletion happens after 7 days of browser use without user interaction on the site.

For cookies set with document.cookie, expiration set to 24 hours on pages with URL decoration (query parameters or fragments) when referring domain is a known tracker.

Other browser storage in 3rd party context

Partitioned access in frame.

Partitioned storage is cleared when no more first-party documents that use the partition are open, or when the browser is closed.

Chrome partitions third-party storage.

Access restricted for known trackers.

No restrictions for other domains.

localStorage and IndexedDB restricted for known trackers.

sessionStorage is not restricted.

Storage is partitioned between the site and the third-party. Storage is not shared across sites.

localStorage is partitioned and reset between application launches.

IndexedDB is restricted.

sessionStorage is partitioned.

Other browser storage in 1st party context No restrictions. No restrictions. No restrictions. All storage is purged from known trackers daily, unless the user has interacted with the site in first-party context within the last 45 days. All script-writable storage is deleted after 7 days of browser use without interaction (click, tap, text input) with the site.
CNAME cloaking Brave blocks any network requests where either the requested URL or that URL’s CNAME record matches any rules in Brave’s blocklists. No restrictions. No restrictions. No restrictions. Expiration of cookies set with Set-Cookie HTTP response headers is 7 days at most, if the response originates from a subdomain that has a CNAME alias to a cross-site origin, or if the subdomain is configured with A/AAAA records where the first half of the IP address does not match the first half of the IP address of the website the user is currently browsing.
Referrer

strict-origin-when-cross-origin or stricter referrer policy in subresource requests and cross-site navigational requests.

Same-site navigation preserves the referrer.

Default browser policy (strict-origin-when-cross-origin) Default browser policy (strict-origin-when-cross-origin)

Default browser policy (strict-origin-when-cross-origin or stricter)

If the referring URL has a tracking parameter (e.g. fbclid), document.referrer string is truncated to eTLD+1.

Downgrade cross-site document.referrer to origin.

Downgrade all cross-site request headers to origin.

For referrers that are known trackers, where the referring page also has URL decoration (query parameters or fragments), document.referrer is downgraded to eTLD+1.

Default browser policy (strict-origin-when-cross-origin)

Other

Remove known tracking parameters (fbclid, gclid, msclkid, mc_eid, and others) from URL query strings.

Randomize HTML canvas fingerprints by first-party domain.

Freeze Mac OS X version to 10_15_7 in the User Agent string.

Freeze Mac OS X version to 10_15_7 in the User Agent string.

Freeze Mac OS X version to 10_15_7 in the User Agent string.

Automatically block requests to tracking domains that are also listed in the Fingerprinting category of the Disconnect.me list.

Freeze Mac OS X version to 10_15 in the User Agent string.

Detect delays in bounce trackers and treat them as regular bounces.

Extend WebKit’s tracking protections to all browsers running on iOS 14 and newer. These protections can only be disabled by the user.

Purge all site data from classified domains if no user interaction (or Storage Access API grant) in first-party context has been recorded in the last 30 days.

Freeze Mac OS X version to 10_15_7 in the User Agent string.

Safari hides the user’s IP address in requests sent to known trackers.

FAQ

1. Why does this resource exist?

Web browsers are going through fairly momentous shifts in order to better respond to the increasing number of data breaches and cases of data misuse by third parties.

Unfortunately, each browser (and the underlying browser engine) seems to have their own interpretation of how to best tackle the problem, which leads to a diverse set of features across the browser landscape.

What’s worse, the information about how these tracking protection mechanisms are deployed is all over the place: in release notes, in developer documentation, in Twitter threads, in working groups, in feature drafts, in bug patches, etc.

The purpose of the Cookie Status resource is to (attempt to) collect this information in one place for easy access and perusal.

There is no commercial agenda behind this project. In fact, there is no agenda other than knowledge transfer.

2. Why only these browsers?

Just to kick things off. Hopefully the open-source nature of this project will invite others to contribute details about browsers that are doing significant work with regard to user privacy.

Cookie Status doesn’t use browser cookies, localStorage, or IndexedDB.

sessionStorage is used to add some functionality to navigation (marking visited pages, highlighting search terms).

Nothing in browser storage is sent to any third parties at any time.

If you see anything contrary to the above, please raise an issue about this.