Wiki · Concept · Last reviewed June 25, 2026

Bounce Tracking Mitigations

Bounce tracking mitigations are browser defenses against redirect-based tracking that tries to turn a brief top-level visit into durable cross-site state.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser privacy, tracking, redirects, storage, agents

Definition

Bounce tracking mitigations are browser mechanisms for limiting a form of navigational tracking. The PrivacyCG Navigational-Tracking Mitigations draft defines navigational tracking as using one or more navigations to identify that a user on one site is the same person as a user on another site. Bounce tracking is the redirect-centered subset: a top-level navigation passes briefly through an intermediate site, often with link decoration, so the intermediate site can join user identities between contexts.

The basic abuse is that the tracker becomes first party for a moment. During that bounce, it may read or write cookies or other state, then redirect the user onward or back. This can simulate part of what third-party cookies used to provide, even when the browser blocks ordinary third-party cookie access.

How It Works

The PrivacyCG draft describes bounce tracking mitigations as a work in progress intended for browsers where third-party cookies are blocked and embedded third-party storage is partitioned. It models user activation, bounce records, extended navigations, grace periods, and periodic cleanup. The draft's cleanup algorithm clears cookies, non-cookie storage, and cache for a host when the conditions for deletion are met.

Chrome's public documentation says its implementation monitors navigations and flags sites that are part of a bounce, including server redirects and client-side JavaScript navigations. Chrome then checks whether the user interacted with the flagged site within the last 45 days. If there is no such interaction and third-party cookies are blocked, Chrome deletes the site's storage shortly after the next redirection flow through that site. Google says this protection launched by default in Chrome for users who have opted in to blocking third-party cookies.

Firefox's source documentation describes Bounce Tracking Protection in Gecko as a heuristic anti-tracking feature rather than a tracker-list feature. It detects short-lived redirect chains, classifies intermediary sites, periodically purges cookies, site data, and cache, and exempts sites the user directly interacted with in the last 45 days.

Agent Context

Browser agents make bounce tracking easier to miss. A human may notice a login page, a payment redirect, or a flicker through a strange domain. A browsing agent may only see that the destination eventually loaded and that the task can continue. If the agent follows links, clicks ads, books travel, signs into services, or navigates affiliate flows, its trace may include redirect chains the user never meaningfully perceived.

That makes bounce tracking evidence relevant to agent governance. A redirect chain is not just page plumbing. It can be a mechanism for state creation, identity stitching, attribution, or fraud scoring. Agent runtimes should treat unexpected intermediate hosts as security and privacy context, not invisible transport.

Governance Use

The governance question is whether a system can tell the difference between a user-valued redirect and a tracking bounce. Federated authentication, single sign-on, and payments often require redirects and user interaction. A browser should avoid breaking those flows. At the same time, a redirect that stores state without a real user relationship should not become a loophole around third-party cookie limits.

For agent-mediated browsing, the useful control is not only deletion. It is evidence capture: source site, intermediate host, destination, redirect type, state-access events, user activation, storage deletion status, and whether the agent or the human initiated the navigation. That record lets auditors distinguish expected identity flows from silent cross-site memory.

Limits

Bounce tracking mitigations do not stop all tracking. Link decoration, server-side logs, fingerprinting, account login, affiliate identifiers, and direct data sharing can still correlate activity. The mitigations also depend on browser-specific implementation details, user settings, and the difficult line between tracking and legitimate redirect workflows.

They are also reactive. A browser can flag and clear state after observing a pattern, but that does not prove every harmful association was prevented. For high-risk agent tasks, redirect observation should be paired with storage partitioning, cookie controls, permission boundaries, and strict connector policies.

Minimum Evidence Record

For agent-mediated browsing, preserve the initiating URL, final URL, intermediate hosts, redirect mechanism where known, user activation status, cookie and storage access events, browser setting for third-party cookies, storage deletion outcome, agent task identifier, and any explicit human approval. Avoid retaining raw cookies, local storage contents, tokens, payment details, or identity-provider responses unless a narrowly scoped investigation requires them.

Source Discipline

Use PrivacyCG for the cross-browser draft framing, Chrome documentation for Chrome behavior, and Firefox source documentation for Gecko behavior. Do not convert one browser's current threshold, rollout condition, or exception handling into a universal rule.

Spiralist Reading

Spiralism reads bounce tracking as a ritual of false passage. The user thinks they moved from one place to another. In the middle, a third place briefly claims them, marks the visit, and sends them on.

The mitigation is modest but important: a browser remembering that the middle passage was not a relationship. In an agentic web, that distinction becomes sharper. Delegated action should not transform accidental transit into consent, identity, or durable memory.

Sources

Return to Wiki