Features on Cookie Status

Blocking of known trackers

Mon, 01 Jan 0001 00:00:00 +0000

Once a domain is classified as a tracker, a browser can either block requests to it, or let the request through but restrict its storage.

When a request is blocked, nothing reaches the tracker: a script never downloads or runs, and a pixel is never sent.
When only storage is restricted, the script still runs and can send data, but it can’t keep a cookie or other identifier that would let it recognize the same browser on other sites.

Blocking protects more but breaks more, so most browsers block only the categories they see as clearly harmful, such as cryptominers and fingerprinting scripts, and restrict the storage of everything else. Brave is the exception: it blocks everything on its filter lists that is loaded from another site.

Classification of "known trackers"

Mon, 01 Jan 0001 00:00:00 +0000

Many protections only apply to domains that a browser has decided are trackers. How a browser makes that decision matters as much as what it does afterwards: the same vendor can be a “known tracker” in one browser and an ordinary third party in another.

Browsers use two broad approaches:

Lists. Firefox and Edge use the Disconnect.me lists, which sort tracking domains into categories such as Advertising, Analytics, Social, Fingerprinting and Cryptomining. Brave uses ad-blocking filter lists such as EasyList and EasyPrivacy. Lists are public and predictable, but they need maintaining and react slowly to new domains.
On-device classification. Safari’s Intelligent Tracking Prevention watches which domains show up as third parties on many different sites, or redirect the user through many sites, and classifies them on the device. Each Safari user can end up with a slightly different set of classified domains.

Chrome doesn’t classify trackers for its default protections.

CNAME cloaking

Mon, 01 Jan 0001 00:00:00 +0000

CNAME cloaking hides a third party behind a subdomain of the site itself. The site creates a subdomain such as metrics.example.com and points it, through a DNS CNAME record, at a vendor’s server. To the browser the requests look first-party, so the vendor gets first-party cookies and avoids lists of third-party trackers.

The same technique is used for legitimate reasons, such as running your own server-side tagging. Browsers that counter it either look up the CNAME record and treat the request as going to the real destination, or limit the cookies such subdomains can set.

Cookies in first-party context

Mon, 01 Jan 0001 00:00:00 +0000

First-party cookies belong to the site in the address bar. They keep users signed in, remember shopping carts, and hold the identifiers that analytics tools use to recognize returning visitors.

Trackers can use them too. A tracker that can’t use third-party cookies can add an identifier to the links it controls ( link decoration) and have its script store that identifier in a first-party cookie on the destination site. To limit this, some browsers shorten the lifetime of first-party cookies, especially those set with JavaScript (document.cookie) rather than an HTTP Set-Cookie header.

Cookies in third-party context

Mon, 01 Jan 0001 00:00:00 +0000

A cookie is used in third-party context when it belongs to a site other than the one in the address bar, for example in an embedded <iframe>, an image or a script loaded from another site. Third-party cookies let one company recognize the same browser on every site that embeds its content, which is the classic way of cross-site tracking. They also power legitimate features such as embedded sign-in, chat and payment widgets.

Fingerprinting

Mon, 01 Jan 0001 00:00:00 +0000

Fingerprinting identifies a browser by combining many small details it reveals: screen size, installed fonts, time zone, graphics hardware, how it draws text on a <canvas>, and so on. None of them is unique alone, but together they often are. Unlike a cookie, a fingerprint can’t be deleted by the user.

Browsers counter it in three ways:

Blocking known fingerprinting scripts (see Blocking of known trackers).
Reducing what they reveal, for example by freezing version numbers in the User-Agent string.
Randomizing values, so that each site sees a slightly different device.

Other

Mon, 01 Jan 0001 00:00:00 +0000

Protections that don’t fit the other rows, such as stripping tracking parameters from URLs, skipping bounce trackers, hiding the IP address from trackers, and privacy-preserving ad measurement.

Other browser storage in first-party context

Mon, 01 Jan 0001 00:00:00 +0000

A site’s own localStorage, IndexedDB and similar storage can hold the same kind of identifiers as first-party cookies, so the reasoning for capping first-party cookies applies here too.

In practice only Safari limits it in default browsing: it deletes all script-writable storage of a site the user hasn’t interacted with in 7 days of browser use. Firefox deletes the storage of known trackers after 45 days without interaction.

Other browser storage in third-party context

Mon, 01 Jan 0001 00:00:00 +0000

Cookies aren’t the only way to store an identifier. Embedded content can also use localStorage, sessionStorage, IndexedDB, the Cache API, service workers and more. If any of these were shared across sites, a third party could use them in place of cookies.

All five browsers now partition this storage by top-level site by default: an iframe from b.example on a.example gets different storage from the same iframe on c.example. Some browsers also block it entirely for known trackers, or clear it when the user leaves the site.

Referrer

Mon, 01 Jan 0001 00:00:00 +0000

When the browser follows a link or loads a resource, it tells the destination which page the request came from: the referrer, sent in the Referer header and exposed to scripts as document.referrer. A full referrer can leak search terms, user IDs or other details in the URL to another site.

All browsers now default to the strict-origin-when-cross-origin policy: other sites only see the origin of the referring page (https://www.example.com/), not its path or query string. Sites can set a different policy. Browsers differ in whether they allow sites to loosen it, for example with unsafe-url.