Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions files/en-us/glossary/etld/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,8 @@ However, this does not work as a general rule, because many registrars allow org

Because this is a matter of the registrar's policies, it's impossible to tell algorithmically whether a given domain name suffix (like `ac.uk`) is publicly registrable or not. The [Public Suffix List](https://publicsuffix.org/) is a list of all suffixes under which organizations can directly register names: that is, it is a list of eTLDs.

## eTLD+1

The related concept **eTLD+1** means an eTLD plus the next part of the domain name. Because eTLD+1s are registrable, all domains with the same eTLD+1 are owned by the same organization.

For example, all the following are eTLD+1 domains:
Expand Down
2 changes: 1 addition & 1 deletion files/en-us/glossary/site/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ page-type: glossary-definition
sidebar: glossarysidebar
---

Informally, a _site_ is a website, which is a collection of web pages, served from the same domain, and maintained by a single organization.
Informally, a _site_ is a website, which is a collection of web pages, served from the same domain, and maintained by a single organization (as defined by {{Glossary("eTLD#etld1", "eTLD+1")}}).

Browsers sometimes need to distinguish precisely between different sites. For example, the browser must only send [`SameSite`](/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) cookies to the same site that set them.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -6,17 +6,17 @@ spec-urls: https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking
sidebar: privacy
---

**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.
**Bounce tracking mitigations** (called **bounce tracking protection** in some browsers) is a feature that enhances user privacy by protecting against **bounce tracking**. This article explains what bounce tracking is, and how bounce tracking mitigations work.

## Bounce tracking defined

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.
Bounce tracking (also known as **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.

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.

Bounce tracking can be done in a couple of different ways:

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`.
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 is then redirected back to `site1.example`.

<!--

Expand All @@ -33,7 +33,7 @@ Bounce tracking can be done in a couple of different ways:

![An illustration of a bounce back example](bounce-back.svg)

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`).
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 is then redirected to another site (`site2.example`).

<!--

Expand Down Expand Up @@ -65,14 +65,22 @@ The process works as follows:
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.
3. If the site does not have any user interaction and third-party cookies are blocked, then its state will be deleted.

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`.
The heuristic operates on {{glossary("site", "sites")}} (as defined by {{Glossary("eTLD#etld1", "eTLD+1")}}). As a result, both `foo.site1.example` and `bar.site1.example` are treated as `site1.example`.

### Stateful versus stateless bounces

Earlier implementations flagged only sites that are part of a "stateful bounce", meaning a "bounce" where the redirect site sets state information (such as a cookie). This was changed because other forms of state — such as network state — are set automatically but can still be manipulated to track users. When you consider these types of state, every bounce becomes effectively stateful, so it is not useful to consider "stateful bounces" as a distinct group.

Implementations were therefore updated to work in "stateless mode".

## Specifications

{{specifications}}

## Browser support

- Chromium's implementation of bounce tracking mitigations was shipped in version 116.
- Firefox [also supports it](https://firefox-source-docs.mozilla.org/toolkit/components/antitracking/anti-tracking/bounce-tracking-protection/).
- Safari first shipped bounce tracking protection in [ITP 2.0](https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/).
- Chromium's implementation of bounce tracking mitigations was shipped in version 116, and works when user settings block third-party cookies. Chromium has third-party cookies disabled by default only when in Chrome Incognito mode (or the equivalent in other browsers, such as Microsoft Edge's InPrivate mode). Browsers based on non-Chromium rendering engines always block third-party cookies by default.
- Firefox [supports bounce tracking protection](https://firefox-source-docs.mozilla.org/toolkit/components/antitracking/anti-tracking/bounce-tracking-protection/) when [Enhanced Tracking Protection](https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop) is set to strict mode.
- Firefox has kept its existing [redirect tracking protection](/en-US/docs/Web/Privacy/Guides/Redirect_tracking_protection) features alongside bounce tracking protection as it provides a cross-browser approach that doesn't rely on a known tracker list.
- Firefox updated its implementation to run in stateless mode in [version 145](/en-US/docs/Mozilla/Firefox/Releases/145).
- Safari doesn't implement bounce tracking mitigations as defined in the [specification](#specifications). Safari has its own list-based bounce tracking protection, which was first shipped in [ITP 2.0](https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/). See also the [Safari](https://privacycg.github.io/nav-tracking-mitigations/#mitigations-safari) description in the specification.