diff options
Diffstat (limited to 'toolkit/components/antitracking/docs/cookie-purging/index.md')
| -rw-r--r-- | toolkit/components/antitracking/docs/cookie-purging/index.md | 217 |
1 files changed, 217 insertions, 0 deletions
diff --git a/toolkit/components/antitracking/docs/cookie-purging/index.md b/toolkit/components/antitracking/docs/cookie-purging/index.md new file mode 100644 index 0000000000..7b8c76cd39 --- /dev/null +++ b/toolkit/components/antitracking/docs/cookie-purging/index.md @@ -0,0 +1,217 @@ +# Cookie Purging + +“Cookie Purging” describes a technique that will periodically clear +cookies and site data of known tracking domains without user interaction +to protect against [bounce +tracking](https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking). + +## Protection Background + +### What similar protections do other browsers have? + +**Safari** classifies sites as redirect trackers which directly or +shortly after navigation redirect the user to other sites. Sites which +receive user interaction are exempt from this. To detect bigger redirect +networks, sites may also inherit redirect tracker +[classification](https://privacycg.github.io/nav-tracking-mitigations/#mitigations-safari). +If a site is classified as a redirect tracker, any site pointing to it +will inherit this classification. Safari does not use tracker lists. + +When the source site is classified as a tracker, Safari will purge all +storage, excluding cookies. Sites which receive user interaction within +seven days of browser use are exempt. If the destination site's URL +includes query parameters or URL fragments, Safari caps the lifetime of +client-side set cookies of the destination site to 24 hours. + +**Brave** uses lists to classify redirect trackers. Recently, they have +rolled out a new protection, [Unlinkable Bouncing](https://brave.com/privacy-updates/16-unlinkable-bouncing/), +which limits first party storage lifetime. The underlying mechanism is +called “first-party ephemeral storage”. If a user visits a known +bounce-tracker which doesn’t have any pre-existing storage, the browser +will create a temporary first-party storage bucket for the destination +site. This temporary storage is cleared 30 seconds after the user closes +the last tab of the site. + +**Chrome** and **Edge** currently do not implement any navigational +tracking protections. + +### Is it standardized? + +At this time there are no standardized navigational tracking +protections. The PrivacyCG has a [work item for Navigation-based Tracking Mitigations](https://privacycg.github.io/nav-tracking-mitigations/). +Also see Apple’s proposal +[here](https://github.com/privacycg/proposals/issues/6). + +### How does it fit into our vision of “Zero Privacy Leaks?” + +Existing tracking protections mechanisms focus mostly on third-party +trackers. Redirect tracking can circumvent these mechanisms and utilize +first-party storage for tracking. Cookie purging contributes to the +“Zero Privacy Leaks” vision by mitigating this cross-site tracking +vector. + +## Firefox Status + +Metabug: [Bug 1594226 - \[Meta\] Purging Tracking Cookies](https://bugzilla.mozilla.org/show_bug.cgi?id=1594226) + +### What is the ship state of this protection in Firefox? + +Shipped to Release in standard ETP mode + +### Is there outstanding work? + +The mechanism of storing user interaction as a permission via +nsIPermissionManager has shown to be brittle and has led to users +getting logged out of sites in the past. The concept of a permission +doesn’t fully match that of a user interaction flag. Permissions may be +separated between normal browsing and PBM (Bug +[1692567](https://bugzilla.mozilla.org/show_bug.cgi?id=1692567)). +They may also get purged when clearing site data (Bug +[1675018](https://bugzilla.mozilla.org/show_bug.cgi?id=1675018)). + +A proposed solution to this is to create a dedicated data store for +keeping track of user interaction. This could also enable tracking user +interaction relative to browser usage time, rather than absolute time +([Bug 1637146](https://bugzilla.mozilla.org/show_bug.cgi?id=1637146)). + +Important outstanding bugs: +- [Bug 1637146 - Use use-time rather than absolute time when computing whether to purge cookies](https://bugzilla.mozilla.org/show_bug.cgi?id=1637146) + +### Existing Documentation + +- [https://developer.mozilla.org/en-US/docs/Web/Privacy/Redirect\_tracking\_protection](https://developer.mozilla.org/en-US/docs/Web/Privacy/Redirect_tracking_protection) + +- [PrivacyCG: Navigational-Tracking Mitigations](https://privacycg.github.io/nav-tracking-mitigations/) + + +## Technical Information + +### Feature Prefs + +Cookie purging can be enabled or disabled by flipping the +`privacy.purge_trackers.enabled` preference. Further, it will only run if +the `network.cookie.cookieBehavior` pref is set to `4` or `5` ([bug 1643045](https://bugzilla.mozilla.org/show_bug.cgi?id=1643045) adds +support for behaviors `1` and `3`). + +Different log levels can be set via the pref +`privacy.purge_trackers.logging.level`. + +The time until user interaction permissions expire can be set to a lower +amount of time using the `privacy.userInteraction.expiration` pref. Note +that you will have to set this pref before visiting the sites you want +to test on, it will not apply retroactively. + +### How does it work? + +Cookie purging periodically clears first-party storage of known +trackers, which the user has not interacted with recently. It is +implemented in the +[PurgeTrackerService](https://searchfox.org/mozilla-central/rev/cf77e656ef36453e154bd45a38eea08b13d6a53e/toolkit/components/antitracking/PurgeTrackerService.jsm), +which implements the +[nsIPurgeTrackerService](https://searchfox.org/mozilla-central/rev/cf77e656ef36453e154bd45a38eea08b13d6a53e/toolkit/components/antitracking/nsIPurgeTrackerService.idl) +IDL interface. + +#### What origins are cleared? + +An origin will be cleared if it fulfills the following conditions: + +1. It has stored cookies or accessed other site storage (e.g. + [localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API), + [IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API), + or the [Cache API](https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage)) + within the last 72 hours. Since cookies are per-host, we will + clear both the http and https origin variants of a cookie host. + +2. The origin is [classified as a tracker](https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage_Access_Policy#tracking_protection_explained) + in our Tracking Protection list. + +3. 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](https://searchfox.org/mozilla-central/rev/cf77e656ef36453e154bd45a38eea08b13d6a53e/toolkit/components/antitracking/PurgeTrackerService.jsm#205-213): + +- Network cache and image cache + +- Cookies + +- 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 + +**Note:** Even though we're clearing all of this data, we currently only +flag origins for clearing when they use cookies or other site storage. + +Storage clearing ignores origin attributes. This means that storage will +be cleared across +[containers](https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers) +and isolated storage (i.e. from [First-Party Isolation](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies#first-party_isolation)). + +#### How frequently is data cleared? + +Firefox clears storage based on the firing of an internal event called +[idle-daily](https://searchfox.org/mozilla-central/rev/cf77e656ef36453e154bd45a38eea08b13d6a53e/toolkit/components/antitracking/PurgeTrackerService.jsm#60,62,65), +which is defined by the following conditions: + +- It will, at the earliest, fire 24h after the last idle-daily event + fired. + +- It will only fire if the user has been idle for at least 3min (for + 24-48h after the last idle-daily) or 1 min (for >48h after the + last idle-daily). + +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. + +#### Debugging + +For debugging purposes, it's easiest to trigger storage clearing by +triggering the service directly via the [Browser Console command line](/devtools-user/browser_console/index.rst#browser_console_command_line). +Note that this is different from the normal [Web Console](/devtools-user/web_console/index.rst) +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: + +``` javascript +await Components.classes["@mozilla.org/purge-tracker-service;1"] +.getService(Components.interfaces.nsIPurgeTrackerService) +.purgeTrackingCookieJars() +``` + +<!--- +TODO: consider integrating +[https://developer.mozilla.org/en-US/docs/Web/Privacy/Redirect\_tracking\_protection](https://developer.mozilla.org/en-US/docs/Web/Privacy/Redirect_tracking_protection) +into firefox source docs. The article doesn’t really belong into MDN, +because it’s very specific to Firefox. +--> |