#1062: TAG spec review of Stateless Bounce Tracking Mitigations

Visit on Github.

Opened Feb 27, 2025

こんにちは TAG-さん!

I'm requesting a TAG review of Bounce Tracking Mitigations.

With browser vendors now actively working to remove third-party cookies from the web, some platform trackers are moving to bounce tracking. This technique involves navigating to a tracker domain at the top level of a browser tab, setting a first-party cookie or storing data in the HTTP cache, and then quickly redirecting away using a request that encodes the value of that first-party cookie or contents of the HTTP cache. Bounce tracking semantically functions like setting a third-party cookie. This spec outlines a proposal for mitigating the privacy impact of bounce trackers.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/862
  • Relevant time constraints or deadlines: Q1 2025
  • The group where the work on this specification is currently being done: PrivacyCG
  • The group where standardization of this work is intended to be done (if different from the current group): N/A
  • Major unresolved issues with or opposition to this specification: N/A
  • This work is being funded by: Google

You should also know that...

This is intended to only cover "bounce tracking mitigations" which is one part of the nav-tracking-mitigations repository. (The Privacy chairs asked for it to be included this repo and due to Bikeshed tooling support it became a single document. Please disregard other parts of the document other than the section on Bounce Tracking Mitigations.)

This tag review is a continuation of https://github.com/w3ctag/design-reviews/issues/862. Since then, the spec has evolved to also look for "stateless bounces" (in other words, ignoring the requirement for cookie access) to prevent usage of the HTTP cache as a means to store data. Additionally, Mozilla is positive with the changes.

Note that there are two explainers: one for the original feature and another to explain a modification. Not all of the spec has not been merged and exists as a pull request at the time of writing. Apologies in advance for the inconvenience.

Discussions