Bounce tracking mitigations

Reduce or eliminate the ability of bounce tracking to recognize people across contexts.

Published on

Translated to: 日本語

Implementation status

This document outlines a new proposal for bounce tracking mitigations.

Why do we need this proposal?

Browser vendors are now actively removing third-party cookies from the web. Consequently, some platform trackers are introducing bounce tracking.

Key Term

Bounce tracking is a method of circumventing anti-tracking browser settings. This allows third-party vendors to set and read first-party cookies.

The bounce tracking mitigations proposal aims to:

  • Reduce or eliminate the ability of bounce tracking to recognize people across contexts.
  • Prevent stateful bounces from simulating third-party cookies when third-party cookies are disabled, either due to browser policy or user settings.
  • Avoid breaking supported use cases valued by the user that are implemented using stateful redirects.
  • Mitigate the impact of short-lived domains that may not be adequately addressed by other privacy interventions that rely on blocklists.
  • Avoid using block or allow lists to decide which websites are affected.

How will bounce tracking mitigations work?

Our proposal will address bounce tracking in the following use cases:

  • Third-party cookie simulation: Sites that use redirection to a third-party tracker to create a cookie bypass browser settings. To mitigate this issue, the browser could wipe the tracker's domain storage.
  • Outgoing redirection: Sites that redirect all outgoing links through a tracker domain. To mitigate this issue, the browser could wipe the tracker's domain storage.

Out-of-scope use cases

Redirect flows that are out-of-scope include: federated authentication, SSO and payments. This is because these flows, while similar to bounce tracking scenarios, involve direct user interaction. You can find further information in the explainer.

  • Federated authentication: Federated authentication occurs when a user clicks on a Login with Identity Provider button on the web, for example, Facebook, GitHub, or Google.
  • Single sign-on: When a site uses single sign-on (SSO), the user expects to log in with the identity provider once and then be automatically logged-in for all visits on other sites.
  • Payments: There are a wide variety of payment flows in use on the web today and the proposal aims to have them continue functioning.

How will bounce tracking mitigations be enforced?

This proposal doesn't have any additional API surface, instead it changes the behavior of the browser.

At a high level the proposal is for the browser to automatically delete storage for a site (eTLD+1) when both the following conditions are true:

  • The browser believes that state has been stored during a redirect bounce.
  • The browser has not had any signals that the user is performing a supported use case on the site (eTLD+1).

Clarifying these definitions will be a key part of the bounce tracking mitigation effort.

Enforcement for bounce tracking mitigation is still in discussion.

Security considerations

There are some security considerations for this proposal that have been outlined in the bounce tracking mitigations explainer.

When will bounce tracking mitigations be available?

This proposal largely only adds value when third-party cookies are disabled. Third-party cookies can be used to achieve mostly the same results as bounce tracking. Therefore it is not a goal to enable these mitigations when third-party cookies are enabled.

Engage and share feedback

The bounce tracking mitigations proposal is under active discussion and subject to change in the future. If you have any feedback, we'd love to hear it.

Updated on Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.