Bounce Tracking Protection

[johnwilander]

In the spirit of a community group, we’d like to share some of our Intelligent Tracking Prevention (ITP) research and see if cooperation can get us all to better tracking prevention for a problem we call bounce tracking.

Safari’s Old Cookie Policy

The original Safari default cookie policy, circa 2003, was this: Cookies may not be set in a third-party context unless the domain already has a cookie set in a first-party context. This effectively meant you had to “seed” your cookie jar as first party.

Bounce Tracking

When working on what became ITP, our research found that trackers were bypassing the third-party cookie policy through a pattern we call "bounce tracking" or "redirect tracking." Here's how it works:

1. The content publisher's page embeds a third-party script from tracker.example.
2. The third-party script tries to read third-party cookies for tracker.example.
3. If it can't, it redirects the top level to tracker.example using window.location or by hijacking all links on the page.
4. tracker.example is now first party and sets a cookie—it seeds its cookie jar.
5. tracker.example redirects back to the original page URL or to the intended link destination.
6. The tracker.example cookie can now be read back in third-party contexts.

Modern tracking prevention features generally block both reading and writing cookies in third-party contexts for domains believed to be trackers. However, it's easy to modify bounce tracking to circumvent such tracking prevention. Step 5 simply needs to pass the cookie value in a URL parameter, and step 6 can stash it in first-party storage on the landing page.

Bounce tracking is also hard to defend against since at the time of the request, the browser doesn’t know if it’ll be redirected.

Safari’s Current Defense Against Bounce Tracking

ITP defends against bounce tracking by periodically purging storage for classified domains that the user doesn’t interact with. Doing navigational redirection is one of the conditions that can get a domain classified by ITP so being a “pure bounce tracker” that never shows up in a third-party context does not suffice to avoid classification. The remaining issue is potential bounce tracking by sites that do not get their storage purged, for instance due to the fact that the user is logged in to the site and uses it.

Can Privacy CG Find a Comprehensive Defense?

We believe other browsers with tracking prevention have no defense against bounce tracking (please correct if this is inaccurate) and it seems likely that bounce tracking is in active use. Because we've described bounce tracking publicly before, we don't consider the details in this issue to be a new privacy vulnerability disclosure. But we'd like the Privacy CG to define some kind of defense.

Here are a few ideas to get us started:

• Adopt ITP’s current defense. This could be done as a periodic purge of cookies for websites without user interaction or combined with a classifier that only subjects domains that show bounce tracking behavior to this periodic purge.
• Detect bounce tracking patterns and put offenders in a SameSite=Strict jail. This would mean the user can still be logged in to the offending websites by loading them directly, but they would see no cookies when they engaged in bounce tracking. Note though that a bounce tracker can navigate publisher.example–>tracker.example–>tracker.example–>destination.example where the second navigation to tracker.example is same-site and will possibly reveal SameSite=Strict cookies. SameSite=Strict cookies may have to be hardened against this kind of attack.
• Detect bounce tracking patterns and put the offenders on some kind of block list. This could be done on-device based on web browsing or centralized through crawls. However, it would lead to broken page loads.
• Detect a redirect on the response and re-raise the bounce request without cookies. This has load performance costs, could break some OAuth flows, and only addresses the “carry ID forward” part of the tracking, not the “user X clicked link Y on website Z” part. This protection would also be vulnerable to correlation between the initial request carrying cookies and the re-raised one.
• Purge non-SameSite=Strict cookies after the domain has shown bounce tracking behavior or by combining it with the block list approach mentioned above.

[pes10k]

Some context, we did some measurement of this ~1 yr ago.

https://brave.com/redirection-based-tracking/

I'd be very interested in other numbers folks might be have, especially as it might help us understand how this risk compares against other risks on the platform. (not that we shouldn't trace down every leak in the platform, but interested in the highest-marginal-benefit ranking)

[jackfrankland]

To highlight a similar mechanism for completeness, sorry if it's documented elsewhere and not considered bounce tracking:

1. The content publisher's page embeds a third-party script from tracker.example.
2. The third-party script tries to read third-party cookies for tracker.example.
3. If it can't, it injects a tracker.example iframe on the publisher's page.
4. User clicks on content in the iframe (intentionally or via click-jacking).
5. Using window.open, a new tab/window is opened for tracker.example.
6. tracker.example window is now first party and can read or write cookies.
7. tracker.example window accesses a function on tracker.example iframe, via window.opener, to pass an identifier.
8. tracker.example window closes itself, and was only open for a short amount of time.
9. Identifier can be passed to initial third-party script via postMessage and stored in first-party storage for continued tracking on the site.

[johnwilander]

To highlight a similar mechanism for completeness, sorry if it's documented elsewhere and not considered bounce tracking:

1. The content publisher's page embeds a third-party script from tracker.example.
2. The third-party script tries to read third-party cookies for tracker.example.
3. If it can't, it injects a tracker.example iframe on the publisher's page.
4. User clicks on content in the iframe (intentionally or via click-jacking).
5. Using window.open, a new tab/window is opened for tracker.example.
6. tracker.example window is now first party and can read or write cookies.
7. tracker.example window accesses a function on tracker.example iframe, via window.opener, to pass an identifier.
8. tracker.example window closes itself, and was only open for a short amount of time.
9. Identifier can be passed to initial third-party script via postMessage and stored in first-party storage for continued tracking on the site.

Interesting. Have you seen this in the wild for tracking purposes? I wouldn't call it bounce tracking, rather insta-popup tracking or brief popup tracking. Maybe file as individual issue? I'd love to hash it out.

[othermaciej]

We should definitely defend against this kind of pop-up based tracking if it's being exploited. (Unfortunately, it sounds rather similar to pop-up based OAuth flows.)

[othermaciej]

Some context, we did some measurement of this ~1 yr ago.

https://brave.com/redirection-based-tracking/

I'd be very interested in other numbers folks might be have, especially as it might help us understand how this risk compares against other risks on the platform.

This is cool data!

I had a hard time figuring out how prevalent bounce tracking is from that post, or in particular the subset we are calling bounce tracking. Bounce tracking is a subset of first-party redirect tracking (which also includes things like URL shorteners, or sites that send all outgoing links through a redirect) which in turn is a subset of redirect tracking (which can include redirects in third-party context). But I couldn't even figure out how prevalent redirect tracking in general is. Help appreciated!

As mentioned by John, we know that at least one significant tracking firm was providing bounce tracking for Safari users across a number of sites, before ITP rendered it ineffective. We don't know current prevalence though.

[pes10k]

@othermaciej thanks! We used the measurements to estimate how often users would hit bounce trackers, using a bunch of random walks of the web, weighted by initial website popularity. Not perfect of course, but a useful first cut.

Our initial plan was to use the above to identify bounce tracking domains (e.g. domains that have storage read or written to, but were only intermediate in some bounce). E.g.

1. click link on popular site
2. arbitrary number of other eTLD+1s the user is 301'ed or otherwise, where something storage related happens
3. finally land on another eTLD+1 thats distinct from all the above.

the "2"s in the above are what got counted in the research behind the blog post, and what we started building lists of. The short term plan was to just block storage on these domains, even in 1p context, until there was a user gesture.

We had some more ideas too that were promising, but have (so far) been triaged down, since we didn't think this was where the best "privacy bang for the buck was", but the partial list includes:

• stage all storage between navigations, during redirection chains, and discard if it looked like bounce tracking
• use the list to identify places we could continuously probe, and strip URL / query information off during navigations where the redirection chain wound up in the same place, to identify params that could be removed or altered w/o effecting the where the navigation wound up
• see if we could figure out which params in the intermediate step contained the final URL destination information, and if so, if we could just extract that when leaving the initial domain and "short circuit" the user to the final domain.

(all "white boarding stage stuff", but where our mind was at at the time)

[empijei]

Thanks for publishing this proposal!

I would like to point out that adding on-device based models could potentially harm privacy and security of users so I think that the crawlers-based approaches that you suggest should be preferred.

[johnwilander]

Thanks for publishing this proposal!

I would like to point out that adding on-device based models could potentially harm privacy and security of users so I think that the crawlers-based approaches that you suggest should be preferred.

Hi! We are well aware of that research. However, it's the observability of global state that's problematic, not the global state itself. And when looking at the observability you have to weigh it against just letting a tracking vector exist. Often you'll find that removing the tracking vector does more for privacy than avoiding the observability of global state. Ideally, you have neither.

For browsers without comprehensive tracking prevention on by default, cookies, web storage, and HTTP cache are readily available global state that's observable cross-site. I.e. that's where you have to start if observability of global state is something you want to defend against.

[kushal]

The remaining issue is potential bounce tracking by sites that do not get their storage purged, for instance due to the fact that the user is logged in to the site and uses it.

Distinguishing legitimate federated sign-on scenarios and legitimate analytics and affiliate scenarios from permissionless bounce tracking seems quite hard. As it is, the "user interaction" signal currently in ITP seems likely to have both false positives and false negatives with the consequence of making it harder for users to stay logged in to authentication providers they care about.

As @othermaciej points out

We should definitely defend against this kind of pop-up based tracking if it's being exploited. (Unfortunately, it sounds rather similar to pop-up based OAuth flows.)

[empijei]

However, it's the observability of global state that's problematic, not the global state itself.

Observing the side effects that you mentioned in the proposal would be trivial, that's why I proposed to go for the shared state across all users. Since we are trying to address the problem let's try to tackle it once and for good. I feel like moving the tracking capability to a different vector would be less beneficial than removing it completely.

(I think that if there is a local model that changes navigation behavior it will probably always be observable)

IMO tracking users based on a list shared across millions of them would likely be more complicated.

For browsers without comprehensive tracking prevention on by default, cookies, web storage, and HTTP cache are readily available global state that's observable cross-site. I.e. that's where you have to start if observability of global state is something you want to defend against.

I agree something has to be done but not at the risk of harming security. This is not a situation in which the worst case is an ineffective mitigation like it would be for a poorly configured CSP, this is a case similar to the XSS auditor, which introduced XSLeaks in almost every website in existence for a debatable advantage over XSS.

Overall, I think the crawler solution would be more solid, I'm not against this proposal, jut here vouching for one of the options you put out 😸

[othermaciej]

Crawler-based classification has holes too, there may be trackers not detectable from the network position of the crawlers but that are detectable for a given user. (Due to geospecific redirects or even trackers identifying the IP block of the crawlers).

Going back to classification In this case, let's consider the proposal with single bit of "classified as a bounce tracker" that puts a site into SameSite=Strict jail. This is pretty hard to abuse. It's detectable only during an actual attempt at bounce tracking, and combining the bits into a usable unique ID requires bouncing through many (32ish) distinct domains every time serially, which is likely to be a prohibitive performance cost. And that bouncing will itself cause all of them to be identified as bounce trackers, so IDs of this form will self-destruct after only a few uses at most. Capping the length of redirect chains is also likely to be web compatible, at a level lower than what would be needed to pull this off.

Let me know if there's a mistake in this analysis.

That said, a combo of crawling and client-side detection may be the right balance.

[hober]

@snyderp, would it be fair to conclude from your comments on this issue that Brave would like to see this proposal taken up by the CG?

[pes10k]

I'm not sure I understand what the specific proposal is, but I'm very in favor of PrivacyCG working on this problem! :)

[johnwilander]

I'm not sure I understand what the specific proposal is, but I'm very in favor of PrivacyCG working on this problem! :)

We wanted to share this at an earlier stage than a crisp proposal to see if we can have this community group work its way through the issue and land in a shared solution. So the proposal is to take on the work of defining the vulnerability and enumerating defenses we believe work, possibly settling on a single one.

The outcome could be standards language which conveys that user agents may put restrictions A, B, and C in place to defend against attack X.