Help test bounce tracking mitigations

As part of our efforts to improve privacy on the web, the Chrome team has been actively working to prevent cross-site tracking of users. We plan to launch mitigations to limit tracking from a particular technique called «bounce tracking» later this year.

While we don’t expect many non-tracking sites will be adversely affected by these changes, we would like to invite developers to test this new feature with feature flags and provide feedback.

# What is bounce tracking?

Bounce tracking is a technique that allows a third-party site to store a cookie even when third-party cookies are blocked. Third-party tracking code included on a page can be used to redirect a user to a tracker’s site, where a cookie can be set, then back to the original page. This redirection can often happen so quickly that a user may not even notice.

Bounce tracking can either be done as a «bounce back» or as a «bounce through».

In both instances, users may be unaware they have visited tracker.example. They may believe they have only visited site1.example or tried to navigate to site2.example.

# What is Chrome planning to change?

Chrome intends to protect users from bounce tracking by periodically deleting state for these tracking sites. The process will work as follows:

1. Chrome will monitor navigations and internally flag sites that are part of a «stateful bounce». This means a navigation redirected through the site, and that the site accessed state during the redirection. This includes both server-initiated redirections and client-side redirections where JavaScript programmatically triggers a navigation. Accessing state includes both cookies and other types of storage; for example, localstorage, indexedDB, and so on.
2. Chrome will periodically examine the list of flagged sites and check to see if the user has actively used the site by interacting with it within the last 45 days. This interaction can occur before, during, or after the bounce was detected.
3. If the site does not have any user interaction and third-party cookies are blocked, then its state will be deleted.

We hope to launch these changes to users who have opted-in to blocking third-party cookies in early Q3 2023.

# Will this break other redirection flows?

The user interaction check is intended to protect non-tracking sites from deletion in cases where they also use a redirection flow. For example, SSO, federated authentication, and payment flows often perform these kinds of interactions. Accordingly, we don’t expect SSO, federated authentication, or payments flows to be impacted. For example, the act of logging into the identity provider, however, counts as a user interaction and prevents deletion.

# How can I tell if my site is impacted?

Bounce tracking mitigations are available to test with feature flags from Chrome version 115 (currently the latest Canary):

1. Create a new Chrome profile. An existing profile that you have used for web development might have interactions logged on the bounce site that your typical website users may not experience.
2. Set the flag at chrome://flags/#bounce-tracking-mitigations to «Enabled With Deletion».
3. Enable third-party cookie blocking in chrome://settings/cookies by selecting «Block third-party cookies».
4. Perform your workflow that involves redirections.
5. Open the Chrome DevTools Issues tab and look for a message titled «Chrome may soon delete state for intermediate websites in a recent navigation chain».
6. Force the bounce tracking deletion check to occur by going to the DevTools Application Panel, clicking on Bounce Tracking Mitigations under Background Services, and then pressing Force Run. Alternatively, you can wait up to two hours for the deletion to occur.
7. Perform your workflow that would expect to have state present on the site bounced through.

For example, if in step (4) you visit this demo page and select the «bounce me» link, then you can expect to see a DevTools issue:

Then, in step 6 you can force the deletion to occur immediately by using the DevTools Application Panel:

If you then revisit the demo and perform the bounce, you should see a new identifier produced because the state was cleared.

# Enterprise use cases

Some enterprises use managed devices in a way that automatically signs users into their SSO site. Since the user does not interact with the SSO site, this can cause Chrome to treat the site as a bounce tracker.

To mitigate this issue enterprises can use cookie policies to enable third-party cookies for the SSO site. This will then prevent bounce tracking mitigations from taking effect for that site.

# Feedback

You can provide feedback in the Chromium bug tracker using the «Privacy>NavTracking» component. Feedback can also be left as a W3C PrivacyCG Navigation-based Tracking Mitigations issue.