Skip to content

Conversation

@chrisdavidmills
Copy link
Contributor

Description

This PR updates the Bounce tracking mitigations article to add Firefox information and a definition of stateful/stateless bounces.

Motivation

Additional details

Related issues and pull requests

@chrisdavidmills chrisdavidmills requested a review from a team as a code owner November 14, 2025 11:18
@chrisdavidmills chrisdavidmills requested review from pepelsbey and removed request for a team November 14, 2025 11:18
@github-actions github-actions bot added Content:Other Any docs not covered by another "Content:" label size/s [PR only] 6-50 LoC changed labels Nov 14, 2025
@github-actions
Copy link
Contributor

Copy link
Contributor

@mb mb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for writing up bounce tracking. Looks very well written.

- 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 first shipped bounce tracking protection in [ITP 2.0](https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Safari doesn't ship bounce-tracking-mitigation (as defined in the draft). They ship their own mitigation that is list based. See https://privacycg.github.io/nav-tracking-mitigations/#mitigations-safari


- 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/).
- Chromium's implementation of bounce tracking mitigations was shipped in version 116, and works when user settings block third-party cookies (other engines block third-party cookies by default).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially interesting to mention that icoginto in chrome has third party cookies disabled by default. I.e. mentioned in https://privacysandbox.com/news/privacy-sandbox-next-steps/ (and still true)

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`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not just eTLD+1 is a term, but the term site itself implies eTLD+1 and is correctly used in this context. Could also be linked in this context: https://developer.mozilla.org/en-US/docs/Glossary/Site


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".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The paragraph itself is correct. I'm not so sure how relevant it is to include on the page. stateless bounces covers more bounce-trackers and is more effective. The spec moved in this direction and I'm not sure how much we want to cover "old revisions" of specs on mdn.

I somewhat hijacked https://bugzilla.mozilla.org/show_bug.cgi?id=1990831 to request dev-docs for bounce tracking itself (because that was the most recent bug that aligned us with the spec), but didn't mean to request covering the stateless vs stateful part of the spec discussion if not necessary.

Copy link
Member

@pepelsbey pepelsbey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Content:Other Any docs not covered by another "Content:" label size/s [PR only] 6-50 LoC changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants