|
| 1 | +--- |
| 2 | +title: Bounce tracking mitigations |
| 3 | +slug: Web/Privacy/Guides/Bounce_tracking_mitigations |
| 4 | +page-type: guide |
| 5 | +spec-urls: https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations |
| 6 | +sidebar: privacy |
| 7 | +--- |
| 8 | + |
| 9 | +**Bounce tracking mitigations** is a browser feature that enhances user privacy by protecting against **bounce tracking**. This article explains what bounce tracking is, and how bounce tracking mitigations work. |
| 10 | + |
| 11 | +## Bounce tracking defined |
| 12 | + |
| 13 | +Bounce tracking (sometimes called redirect tracking) is an abuse of cross-site navigation in which a tracker redirects a user to their website for the purpose of setting a first-party cookie to track that user across other sites. The redirection can happen so quickly that a user may not even notice it. |
| 14 | + |
| 15 | +In effect, bounce tracking enables tracking cookies to be set even if the browser has [third-party cookies](/en-US/docs/Web/Privacy/Guides/Third-party_cookies) disabled. |
| 16 | + |
| 17 | +Bounce tracking can be done in a couple of different ways: |
| 18 | + |
| 19 | +1. As a "bounce back". In this case, the user starts on a website (`site1.example`), is navigated to a tracker site (`tracker.example`) where the tracking cookie is set, and then redirected back to `site1.example`. |
| 20 | + |
| 21 | + <!-- |
| 22 | +
|
| 23 | + Mermaid JS source: |
| 24 | +
|
| 25 | + flowchart LR |
| 26 | + A["site1.example"] -- 1: Navigate --> B["tracker.example"] |
| 27 | + B -- 2: Store cookie --> C[("Browser")] |
| 28 | + B -- 3: Redirect --> A |
| 29 | +
|
| 30 | + https://www.mermaidchart.com/ was used to generate the chart, with the "Default theme" |
| 31 | +
|
| 32 | + --> |
| 33 | + |
| 34 | +  |
| 35 | + |
| 36 | +2. As a "bounce through". In this case, the user starts on a website (`site1.example`), is navigated to a tracker site (`tracker.example`) where the tracking cookie is set, and then redirected to another site (`site2.example`). |
| 37 | + |
| 38 | + <!-- |
| 39 | + |
| 40 | + Mermaid JS source: |
| 41 | + |
| 42 | + flowchart LR |
| 43 | + A["site1.example"] -- 1: Navigate --> B["tracker.example"] |
| 44 | + B -- 3: Redirect --> C["site2.example"] |
| 45 | + B -- 2: Store cookie --> D[(Browser)] |
| 46 | + |
| 47 | + |
| 48 | + https://www.mermaidchart.com/ was used to generate the chart, with the "Default theme" |
| 49 | + |
| 50 | + --> |
| 51 | + |
| 52 | +  |
| 53 | + |
| 54 | +In both instances, users may be unaware they have visited `tracker.example`. They may believe they have only visited `site1.example` or tried to navigate to `site2.example`. |
| 55 | + |
| 56 | +## How Bounce tracking mitigations work |
| 57 | + |
| 58 | +Bounce tracking mitigations work by identifying tracker sites via a heuristic and periodically deleting cookies and other state data associated with them (other examples include [`localStorage`](/en-US/docs/Web/API/Web_Storage_API), [IndexedDB](/en-US/docs/Web/API/IndexedDB_API), [Cache API](/en-US/docs/Web/API/CacheStorage), and network state data). The feature avoids using block or allow lists to decide which websites are affected. |
| 59 | + |
| 60 | +It is critical that, while defending against bounce tracking, the browser doesn't interfere with legitimate, non-tracking redirection flow uses. For example, single sign-on (SSO), [identity federation](/en-US/docs/Web/API/FedCM_API#fedcm_concepts), and payment services generally involve redirecting the user to another site where they perform an action, updating state information as a result, then redirecting the user back to the original site. |
| 61 | + |
| 62 | +The process works as follows: |
| 63 | + |
| 64 | +1. The browser monitors navigations and flags sites that are part of a "bounce", meaning sites through which a navigation was redirected. This includes both server-initiated redirections and client-side redirections where JavaScript programmatically triggers a navigation. |
| 65 | +2. The browser periodically examines its list of flagged sites and checks to see if the user has actively used the site by interacting with it within the last 45 days. Example interactions include clicking a button, entering data into a form, and scrolling the site. The interaction can occur before, during, or after the bounce was detected. |
| 66 | +3. If the site does not have any user interaction and third-party cookies are blocked, then its state will be deleted. |
| 67 | + |
| 68 | +The heuristic operates on sites defined by {{Glossary("eTLD", "eTLD+1")}}. As a result, both `foo.site1.example` and `bar.site1.example` are treated as `site1.example`. |
| 69 | + |
| 70 | +## Specifications |
| 71 | + |
| 72 | +{{specifications}} |
| 73 | + |
| 74 | +## Browser support |
| 75 | + |
| 76 | +- Chromium's implementation of bounce tracking mitigations was shipped in version 116. |
| 77 | +- Firefox [also supports it](https://firefox-source-docs.mozilla.org/toolkit/components/antitracking/anti-tracking/bounce-tracking-protection/). |
| 78 | +- Safari first shipped bounce tracking protection in [ITP 2.0](https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/). |
0 commit comments