demo · v134

The cache-only bounce tracker

PrivacyCG documented the loophole that drove this update: a bounce tracker that doesn’t touch cookies or storage — it just serves a unique image per user, lets the HTTP cache memorize the ETag, and re-reads it on the next bounce. Pre-Chrome 134 the mitigations only fired on storage access, so the tracker survived. Toggle the tracker’s storage usage and pick a browser version to see whether it gets flagged.

probing Storage Access & Bounce mitigations…
Bounce mitigations run inside the browser session manager — they aren’t observable from a page. This page reproduces the algorithm in JS using the exact rules from the spec.

Bounce sequence

A typical tracker redirect chain: the user clicks a link on a publisher, an intermediate hop loads in <100 ms with no UI, and the user lands on the destination.

1. publisher
news.example/article
2. bounce
tracker.example/r?u=…
3. destination
store.example/product
4. user returns
news.example/article
5. user bounces again
tracker.example/r?u=…

The algorithm in one line

// Pre-Chrome 134:
flagged = bouncedQuickly && (accessedCookies || accessedStorage);

// Chrome 134+:
flagged = bouncedQuickly && (accessedCookies || accessedStorage || writtenHttpCache);

see also