v134 · privacy / security
Redirect Chain Visualizer
Bounce trackers can carry identifiers through redirect chains and preserve them in HTTP cache state. Chrome 134's mitigation is browser-internal: classified bounce trackers have relevant cache and storage state purged without adding a new request or response header. Pick a scenario and trace what happens at each hop.
Chrome 134+ can support these mitigations; settings may still affect enforcement
A bounce tracker works by routing you through
tracker.example/?id=user123 — a domain it controls — before sending you to your destination. The tracker can attempt to store a unique cached response keyed to your ID, building a cross-site profile without setting cookies. Chrome 134 extends bounce-tracking mitigations so cache-only tracker state is cleared as part of the browser's existing classification and deletion flow.
Choose a redirect scenario
Hop-by-hop chain
Browser-internal mitigation trace
Select a scenario above to see the trace.
Why HTTP cache?
Cookies, localStorage, and IndexedDB are partitioned by top-level site in Chrome. But historically, the HTTP cache was shared — a tracker could check: "did I cache a response for this user's IP/config combo?" to correlate visits. Cache partitioning in Chrome 86+ partitioned the cache by (top-level site, frame site), and Chrome 134 extends bounce-tracking mitigations to also clear cache storage for classified trackers, closing this loophole.