Bounce Tracking: The Redirect You Never See

For roughly two decades, cross-site tracking had an easy mechanism. A tracker embedded a pixel or a script on thousands of sites, the browser sent that tracker's cookie along with every one of those requests, and the tracker assembled a browsing history from requests it never had to solicit. The user visited one site; the tracker was present on all of them.

Browsers dismantled that. Safari began restricting third-party cookies in 2017, Firefox followed with Enhanced Tracking Protection, and Chrome's storage partitioning work made third-party state per-top-level-site rather than global. The passive read stopped working.

Bounce tracking is the response. If the tracker cannot be read as a third party, the tracker arranges to briefly become a first party.

The mechanism, step by step

Consider a link in a marketing email or on a social platform. The visible destination is a retailer. The actual href points somewhere else.

1. You click. The browser navigates to click.tracker.example/r?u=retailer.example/shoes&c=9f2a.
2. That request is a top-level navigation. As far as the browser is concerned, tracker.example is now the site you are on. Its cookies are first-party cookies. Its storage is first-party storage.
3. The tracker's server reads the cookie it set the last time you bounced through it, which contains a persistent identifier. If there is no cookie, it mints one.
4. It records the pair: identifier a1b2c3, came from the newsletter, going to the shoes page.
5. It responds with a 302 to retailer.example/shoes?cid=a1b2c3, handing the identifier forward in the URL.
6. The retailer's page loads and reads cid from its own URL. The retailer now holds the tracker's identifier in its own first-party context, where it can be stored and sent back later.

Total elapsed time is one network round trip. No content is drawn. The address bar may flicker. On a slow connection you sometimes see the intermediate domain for an instant, which is the only direct evidence most people will ever get.

Stateful and stateless variants

The version above is stateful bounce tracking. It depends on the tracker keeping a cookie on its own domain and recognising you when you pass through again. It is the more powerful form, because the identifier survives between visits and links together sites that share nothing else.

There is a stateless variant, and it is the one most people have actually seen. The redirector stores nothing. It simply appends an identifier that was already in the inbound URL, forwarding a value the sender knew, so the destination learns which recipient clicked. That is link decoration, and the distinction matters for defence: stripping URL parameters helps against the stateless form and does nothing about the stateful one, because the stateful identifier lives in a cookie you cannot see from the address bar.

In practice the two are combined. The bounce sets or reads the cookie, then decorates the outbound URL with what the cookie said.

What browsers actually do about it

Every mitigation shipped so far shares one design. Because a navigation to a site is indistinguishable, in the moment, from a visit you intended, browsers cannot block the bounce. They allow it and then delete what it left behind.

Approach	What it does
Safari, Intelligent Tracking Prevention	Classifies domains with cross-site tracking behaviour, and purges storage for a classified domain that appears in a redirect chain without a genuine user interaction.
Firefox, redirect tracking protection	Part of Enhanced Tracking Protection since 2020. Periodically clears cookies and site data for domains on its tracking list that you have not interacted with directly.
Chrome, Bounce Tracking Mitigations	Detects sites that appear in navigation chains, write state, and receive no user interaction, then deletes that state.
Standards work	The W3C Privacy Community Group has been specifying navigational tracking mitigations so the behaviour is defined rather than per-vendor heuristics.

The common element is also the weak point: without user interaction. All three implementations decide whether to delete state by asking whether you have meaningfully engaged with that domain recently. That question has to be answered by heuristic, and heuristics have edges.

Where the heuristics break

A tracker that also runs a site you use is exempt from its own countermeasure. If the redirector's domain is one you log into, click around, or type into, the browser records interaction and stops treating its state as tracking residue. This is not a hypothetical case. The largest ad networks are operated by companies whose consumer products you visit daily, and the redirect domain can be placed on the same registrable domain as the product.

A second edge is timing. Deletion is periodic, not immediate. Between the bounce and the sweep there is a window in which the identifier is live and can be read again by another bounce. A tracker that sees enough traffic can keep an identifier permanently fresh by ensuring you pass through more often than the deletion interval.

A third is that deleting the tracker's own cookie does not retract the identifier it already handed to the destination site. Step six put cid=a1b2c3 in the retailer's URL, and the retailer's first-party storage is not subject to any of this. The bounce is a one-time transfer, and the transfer completed.

Cookie deletion is a defence against continuity, not against disclosure. What the tracker learned during the bounce is already somewhere else.

What this looks like from the user's side

There are two things worth knowing, and one of them is uncomfortable.

The useful one: you can see this happening. Open the developer tools network panel, enable the option to preserve the log across navigations, and click a link from a newsletter or a social feed. The redirect chain is fully visible, with the 302 responses and the Set-Cookie headers. Doing this once on a marketing email is a clearer education than any article, this one included.

The uncomfortable one: the countermeasures are graded on a curve, and the grade depends on which browser you use and whether the tracker's operator also owns a site you like. Most fingerprinting defences go the same way. Deterministic identifiers get harder to maintain, probabilistic reconstruction gets more valuable, and the industry moves toward whichever one the current mitigation does not cover.

Practical measures that hold up:

• Use a browser that partitions and expires third-party state by default, and leave the strictest tracking protection setting on. It will not cover the interacted-domain case, and it covers the rest.
• Strip tracking parameters before sharing or opening links. This handles the stateless half. Several browsers now do it automatically for a known parameter list.
• Separate contexts. A browser profile that only ever handles email links, kept apart from the one where you are logged in, denies the bounce anything durable to correlate. See profile compartmentalization.
• Treat email links as the highest-risk case. A link in a message already knows who you are before you click it. The bounce is how that knowledge travels onward to the web.

The pattern worth taking away

Bounce tracking is what happens when a defence is built on a category rather than on a capability. Third-party cookie blocking assumed that "third party" was a stable property of a request. It is not. It is a property of the current navigation, and the tracker gets to influence the navigation.

Every subsequent countermeasure has inherited that problem, which is why they are all after-the-fact deletions rather than refusals. The web's security model has no way to express "this navigation was not the user's intent," so the browser reconstructs intent from behaviour, and behaviour can be arranged.

At Haven we spend most of our attention on message contents and on the metadata around them, which is a different problem from web tracking. The connection is that both are cases where a system's protections are described in terms of what an adversary is called, and an adversary who can change what they are called goes straight through. It is worth knowing which of your protections are defined that way.