#1062: TAG spec review of Stateless Bounce Tracking Mitigations
Discussions
Comment by @MrPickles Feb 27, 2025 (See Github)
Also cc @Trikolon and @bvandersloot from Mozilla as FYI.
Discussed
Apr 1, 2025 (See Github)
Lola: I'm a bit confused, but you can assign me to this … is the spec to mitigate what they described? Hadley: There's two explainers about one spec Matthew: Not an expert, but interested in it … may have access to an expert soon Hadley: added @torgo as well
Discussed
Apr 1, 2025 (See Github)
Torgo: Missing Hadley and Matthew. Next week.
Comment by @lknik Apr 11, 2025 (See Github)
I support this proposal because this non-transparent method is being used since >10 years.
OpenedFeb 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:
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.