Ready for Trial: Bounce Tracking Mitigations

494 views
Skip to first unread message

Ben Kelly

unread,
May 15, 2023, 12:42:14 PM5/15/23
to blink-dev

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”.Shows an example of a "bounce back" where site1.example redirects to tracker.example, cookies are accessed, and then redirects back to the original site.

Shows an example of "bounce through" where site1.example redirects to tracking.example. cookies are accessed, and then redirects to site2.example.

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; e.g. localstorage, indexedDB, etc.

  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.


Note, this algorithm operates on sites defined by eTLD+1. So "foo.example.site" and "bar.example.site" are both treated as just "example.site".


It's also important to note that deletion also only occurs when third-party cookies are blocked. This means that initially only users that have opted-in to blocking third-party cookies or are using Incognito mode will be protected from bounce tracking. The feature will roll out to all users later when third-party cookie deprecation moves forward.

Won't this break authentication/payments/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 with DevTools open.

  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 visited this demo page and clicked the "bounce me" link, then you would expect to see a devtool issues like:


image.png


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


image.png


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.


Ben Kelly

unread,
May 30, 2023, 2:00:04 PM5/30/23
to blink-dev
FYI, this is now available in a more readable format here:

Reply all
Reply to author
Forward
0 new messages