Tracking protection, and similar measures, seek to protect the user from covert data collection and exploitation by scripts and applications created for such purposes.
In short, tracking protection, tracking prevention, anti-tracking, cookie blocking, content blocking, etc. are designed to:
In this introductory chapter, we’ll gloss over some of the key terminology regarding tracking protection. You are then advised to visit the other pages of Cookie Status for more details.
Browser cookies are key-value pairs (e.g.
id=abcd1234) of information stored on the user’s computer. Websites set them in order to persist information from one page to the next. This is because the web is effectively stateless - only a very limited set of information is shared from one page to the next. By writing information into browser storage, that information persists even if the pages the user navigates from are unloaded and their storage purged.
Typical use cases for cookies include persisting a shopping cart from one page to the next on an ecommerce site, storing details about user’s login status, and for setting an identifier for the user, so that their visits can be recognized in an analytics tool as originating from the same browser.
Websites can write cookies on the user’s computer, and they can read cookies from the user’s computer. How effective this is depends on whether the user’s browser allows cookie access in third-party context, and whether cookies in first-party context have restrictions as well.
The first method relates to the browser requesting resources from a web address. This is done via an HTTP request.
When the browser requests a resource from a web address, that request will include a
cookie header, which includes all the cookies written on the target domain and all the domains in its domain hierarchy up to the eTLD+1.
eTLD+1 means effective top-level domain plus one part. The eTLD is the same thing as the Public Suffix. For a domain like blog.ecommerce.cookiestatus.co.uk, the eTLD would be .co.uk, and the eTLD+1 would be cookiestatus.co.uk. For a domain such as cookiestatus.github.io, the eTLD would be github.io and the eTLD+1 would be cookiestatus.github.io.
This is what a sample HTTP request would look like with the
cookie header in place:
cookie header must respect the cookie settings in the browser. If the browser blocks third-party cookies, the
cookie header is only included for requests in first-party context. Similarly, if the browser blocks all cookies, the
cookie header will not be included in any requests.
cookie header is part of the HTTP request, it means that the web server hosting the resource will be able to read this header and use this information at will.
const cookies = document.cookie; console.log(cookies); // userId=abcd1234; logged-in=true
document.cookie is invoked in a third-party context, such as an
<iframe> element embedding content from a third-party source, the string will be populated only if the web browser allows third-party cookies.
Similar to reading cookies, the HTTP protocol can be used to write cookies as well. The web server can return with an HTTP response including the
This header is an instruction to the browser to write the included cookie(s) on the domain specified in the header.
document.cookie API can be used to write cookies, too.
While on the www.cookiestatus.com domain, the following command would write a
userId cookie on cookiestatus.com.
document.cookie = 'userId=abcd1234;domain=cookiestatus.com;path=/';
It’s common in the parlance of the web to talk about first-party cookies and third-party cookies. This is a bit of a misnomer. Cookies are pieces of information that are stored on the user’s computer. There is no distinction between first-party and third-party in how these cookies are classified and stored on the computer.
What matters is the context of the access.
Nevertheless, to align with other discussions around the same topic, Cookie Status will use first-party cookie and third-party cookie for clarity’s sake.
First-party context means that the operation happens between domains within the same site, í.e. domains that share the eTLD+1. Third-party context means that the operation happens cross-site, i.e. between domains that do not share the eTLD+1.
Here are some examples. Consider the user to be on the domain www.cookiestatus.com.
|Scenario||Type of context||eTLD+1||Details|
|The browser requests an image from images.cookiestatus.com.||First-party context||cookiestatus.com||The
|The browser runs
||First-party context||cookiestatus.com||The command can be used to read and write cookies on www.cookiestatus.com and cookiestatus.com.|
|The browser loads a page from booking.vendor.com in an
||Third-party context||vendor.com||The command can be used to read and write cookies on booking.vendor.com and vendor.com.|
In the first-party context scenarios above, the cookie read/write operations will work unless the browser blocks all cookies or has cookiestatus.com in a blacklist.
In the third-party context scenarios, the cookie operations will work unless the browser blocks all third-party cookies, has vendor.com in the blacklist, or the possible tracking protection mechanisms have deemed vendor.com to be a tracking domain.
Cookie access in a first-party context is rarely blocked, because many features of modern websites rely on state management in the browser (using cookies or other browser storage). However, some vendors are repurposing first-party cookies for cross-site tracking, which has led to browsers (especially Safari) to place restrictions on first-party storage as well.
Accessing cookies in a third-party context is necessary for some benign features of the web, such as persisting user authentication across the domains of an organization (SSO), or for passing information about user’s marketing consent from one part of the organization to another.
However, cookie access in a third-party context can be abused as well, because it can be used for cross-site tracking without the user’s consent or awareness.
A common thread in the rhetoric is that browsers want to quench cross-site tracking. Here’s how Safari describes it:
Imagine a user who first browses example-products.com for a new gadget and later browses example-recipies.com for dinner ideas. If both these sites load resources from example-tracker.com and example-tracker.com has a cookie stored in the user’s browser, the owner of example-tracker.com has the ability to know that the user visited both the product website and the recipe website, what they did on those sites, what kind of web browser was used, et cetera. This is what’s called cross-site tracking and the cookie used by example-tracker.com is called a third-party cookie. In our testing we found popular websites with over 70 such trackers, all silently collecting data on users.
In essence, cross-site tracking utilizes centralized tracking domains for scripts to communicate with from the sites the user actually visits. These tracking domains leverage third parties’ access to browser storage (mainly cookies) to build profiles of all the sites the user has visited.
To continue the examples from the previous chapters, when the user’s browser makes a request for image.imagestore.com while on the blog.ecommerce.cookiestatus.com website, the endpoint at image.imagestore.com will now know that the request originated from blog.ecommerce.cookiestatus.com, as this is included in the
referer [sic] headers.
Thus the endpoint at image.imagestore.com could now check if the user has an identifier cookie set on that domain, and they can augment the profile for that identifier with knowledge that the user has visited blog.ecommerce.cookiestatus.com.
If the user then visits another page on the internet that also communicates with image.imagestore.com, then that endpoint will be privy to yet another origin, and they can keep building the profile.
This is the essence of cross-site tracking - using a consolidated and centralized store (e.g. a cookie) to collect information from different domains.
Browsers’ main weapon against cross-site tracking is restricting storage access. Because there are valid reasons for cross-site tracking (persisting user authentication, shopping baskets, consent status), tracking protection methods restrict storage access for third parties that have been identified and classified as compromising user privacy.
The Chrome browser is, for now, devoid of any significant tracking protection measures with regard to storage access. However, they have contributed to the discussion with their privacy sandbox initiative, as well as with upcoming features involving cookie restrictions and referrer policies.
Mozilla Firefox, for example, describes their own effort like this:
In order to help give users the private web browsing experience they expect and deserve, Firefox will strip cookies and block storage access from third-party tracking content, based on lists of tracking domains by Disconnect.
This approach of comparing the third-party domains against a curated list is utilized also by Microsoft Edge. Here’s how they introduce Edge’s tracking prevention:
We’ve added a new component to Microsoft Edge, Trust Protection Lists**,** that contains the latest information on which organizations may be trying to track users on the web. This component allows us to be flexible with where we source details on what a tracker is and when we deliver updated lists to our users.
The Brave browser, similarly, pulls in tracking domains from multiple sources. Notably, Brave combines prescribed lists (from e.g. EasyList and uBlock Origin) with a more dynamic list based on crawl data (PageGraph).
With list-based protection, the browser maintains a list of domains against which each outgoing HTTP request from the site is pattern-matched. If there is a match between the request target and one of the domains in these lists, the request is blocked.
This means that browsers can block both downloading script resources and HTTP requests to tracking endpoints (e.g. image pixels).
The biggest problems with list-based protection are:
The Safari browser has opted for a different tact. Instead of a binary approach (blocked vs. not blocked) and a set list of domains, Safari’s Intelligent Tracking Prevention uses multiple methods to restrict the storage access for third parties that are algorithmically classified as having cross-site tracking capabilities. Here’s how they describe the classification process:
A machine learning model is used to classify which top privately-controlled domains have the ability to track the user cross-site, based on the collected statistics. Out of the various statistics collected, three vectors turned out to have strong signal for classification based on current tracking practices: subresource under number of unique domains, sub frame under number of unique domains, and number of unique domains redirected to. All data collection and classification happens on-device.
Note that in early 2020, WebKit’s tracking protections were extended to block all third-party cookies without exception. Thus the algorithmic classification no longer applies to how third-party storage is accessed, but it is still used for other tracking-related protections (such as downgrading the referrer).
However, Safari’s approach is binary in a sense - you can either enable all cross-site tracking or none.
Cliqz has a similar tact. This is explained in detail in this research paper, and in this blog post. Basically, they combine local and global evaluation of the data passed to and from the web browser to establish heuristical models for identifying potential tracker connections.
Cliqz’ approach is two-fold. First, they purge identifiers from the HTTP requests that could be misused for tracking. Second, they block cookie access in third-party context, unless the user interacts with the third-party domain (e.g. in a widget).
A global safe set is compiled from the actions Cliqz’ anti-tracking mechanism takes on each individual browser, and this global research data is used to fine-tune the local behavior of Cliqz’ tracking protections.
The algorithmic approach is effective because it identifies potential tracking domains dynamically and without using a centralized list. This means that there’s less overhead in pattern-matching the HTTP requests as the list of domains for the browser would only include those the browser has actually communicated with.
The algorithm also ensures that locally hosted tracking domains and reverse proxies would also be under scrutiny (unless served in a same-site context).
The main problems with this approach are:
Note that for false positives blocking access to cross-origin storage, ITP offers the Storage Access API. However, there is no provision in ITP to remove a domain from the list of classified domains, which means that first-party protections would still apply.