Adding upstream version 115.7.0esr.upstream/115.7.0esr

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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.
+-->