|Originally deployed in||1.30.0|
|Latest update deployed in||1.32.1|
|Latest update includes||All cross-origin referrers stripped to origin.|
|User controls||Site-specific and global controls for:
Cliqz uses an algorithmic classification model for identifying trackers with cross-site tracking capabilities.
This model is run both locally (in the user's browser) and globally (derived from a global database, periodically updated with data from local contexts).
To understand this better, read this research paper:
You can also browse the whotracks.me service to learn about the status of the global tracker database Cliqz uses.
Known trackers have third-party cookie access blocked. There is a heuristical model in place to determine exceptions to this rule. The model includes (source):
Cookies that are set on classified domains without first-party interaction (i.e. as third-party cookies) have a maximum expiration set to 1 hour.
How first-party cookies expire is determined by a) whether the domain the cookies are set on is a classified domain, and b) how frequently the classified domain is visited in first-party context.
If the domain is not a classified domain, first-party cookies have a maximum expiration of 7 days (if set without the
HttpOnly flag) or 30 days (if set with the
If the domain is a classified domain, then infrequent visits to the domain impose a maximum expiration of 7 days to the first-party cookie. If the domain is visited frequently, the maximum expiration is set to 30 days (with the
HttpOnly limitation same as above).
No current restrictions.
No current restrictions.
Cliqz strips all cross-origin referrers to origin only.
Example: The user clicks on a link from
referer HTTP header and the
https://www.company.com as the referrer. All non-navigational HTTP requests will truncate the referrer in a similar fashion.
Cliqz automatically purges potential user identifiers from the URL, headers, and POST data of third-party requests.
The model tokenizes all key-value pairs found, and then evaluates the values against a set of rules to determine if it's safe (should not be removed) or unsafe (should be removed).
This evaluation is done locally first, and then the values are compared against a global safe set (derived from data collected from global Cliqz usage). If the value is flagged as unsafe and does not have a match in the global set, it is purged from the request.
Example: If the browser sends a request to a third-party resource using something like
?userId=abcd-1234-efgh-5678 in the request URL, it's possible that this parameter will be stripped from the outgoing request so that the service receiving the request will not be able to access the data.
This article has an excellent overview of how this process works (beginning with chapter titled Unsafe Data Removal).