Redirect tracking protection
Firefox 79 includes protection against redirect tracking. This document describes how the protections work.
Redirect tracking defined
Redirect tracking is an abuse of cross-site navigation in which a tracker momentarily redirects a user to their website for the purpose of using first-party storage to track that user across websites.
Redirect trackers work by forcing you to make an imperceptible and momentary stopover to their website as part of that journey. So instead of navigating directly from the review website to the retailer, you'll end up navigating to the redirect tracker first rather than to the retailer. This means that the tracker is loaded as a first party. The redirect tracker associates tracking data with the identifiers they have stored in their first-party cookies and then forwards you to the retailer.
Redirect tracking protection explained
To protect against redirect tracking Firefox periodically clears cookies and site data from trackers. We only clear this data from storage if the user is blocking tracking cookies (i.e., the
network.cookie.cookieBehavior pref is set to
4). Support for other cookie policies is tracked by Bug 1643045.
What origins are cleared?
An origin will be cleared if it fulfills the following conditions:
- It has stored cookies or accessed other site storage (e.g. localStorage, IndexedDB, or the Cache API) within the last 72 hours. Since cookies are per-host, we will clear both the
httpsorigin variants of a cookie host.
- The origin is classified as a tracker in our Tracking Protection list.
- No origin with the same base domain (eTLD+1) has a user-interaction permission.
- This permission is granted to an origin for 45 days once a user interacts with a top-level document from that origin. "Interacting" includes scrolling.
- Although this permission is stored on a per-origin level, we will check whether any origin with the same base domain has it, to avoid breaking sites with subdomains and a corresponding cookie setup.
What data is cleared?
Firefox will clear the following data:
- Network cache and image cache
- DOM Quota Storage (localStorage, IndexedDB, ServiceWorkers, DOM Cache, etc.)
- DOM Push notifications
- Reporting API Reports
- Security Settings (i.e. HSTS)
- EME Media Plugin Data
- Plugin Data (e.g. Flash)
- Media Devices
- Storage Access permissions granted to the origin
- HTTP Authentication Tokens
- HTTP Authentication Cache
Storage clearing ignores origin attributes. This means that storage will be cleared across containers and isolated storage (i.e. from First-Party Isolation).
How frequently is data cleared?
Firefox clears storage based on the firing of an internal event called
idle-daily, which is defined by the following conditions:
- It will, at the earliest, fire 24h after the last
- It will only fire if the user has been idle for at least 3min (for 24-48h after the last
idle-daily) or 1min (for >48h after the last
This means that there are at least 24 hours between each storage clearance, and storage will only be cleared when the browser is idle. When clearing cookies, we sort cookies by creation date and batch them into sets of 100 (controlled by the pref
privacy.purge_trackers.max_purge_count) for performance reasons.
Redirect tracking protection can be enabled or disabled by flipping the
privacy.purge_trackers.enabled preference in
about:config. Furthermore, it will only run if the
network.cookie.cookieBehavior pref is set to
5 in Firefox 79+ onwards (
5 as of Firefox 80).
Different log levels can be set via the
For debugging purposes, it's easiest to trigger storage clearing by triggering the service directly via the Browser Console command line. Note that this is different from the normal Web Console you might use to debug a website, and requires the
devtools.chrome.enabled pref to be set to
true to use it interactively. Once you've enabled the Browser Console you can trigger storage clearing by running the following command:
await Components.classes["@mozilla.org/purge-tracker-service;1"] .getService(Components.interfaces.nsIPurgeTrackerService) .purgeTrackingCookieJars();
The time until user interaction permissions expire can be set to a lower amount using the
privacy.userInteraction.expiration pref. Note that you will have to set this pref before visiting the sites you want to test — it will not apply retroactively.
WebKit first shipped redirect tracking protection in ITP 2.0 (they refer to the same attack as bounce tracking). As of July 2020, there are several significant differences between WebKit's implementation and Firefox's implementation:
- The list of origins to be cleared in Firefox is based on our tracking protection list; WebKit relies on ITP's classification.
- Firefox's definition of "interaction" includes user scrolling when visiting the origin as a first party; WebKit's does not.
- Firefox will not clear data for an origin if it has received interaction as a first party in the last 45 days of calendar time; WebKit's interaction window is 30 days of browser use (e.g. days in which the user has had at least one interaction with Safari).