Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Ship: Bounce Tracking Mitigations on HTTP Cache

310 views
Skip to first unread message

Chromestatus

unread,
Feb 27, 2025, 3:46:54 PMFeb 27
to blin...@chromium.org, l...@chromium.org, ort...@chromium.org, rtar...@chromium.org, sv...@chromium.org

Contact emails

l...@chromium.org, ort...@chromium.org, sv...@chromium.org, rtar...@chromium.org

Explainer

https://github.com/privacycg/nav-tracking-mitigations/issues/41#issuecomment-2504329542

Specification

https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations

Summary

Bounce tracking mitigations for the HTTP cache is an extension to existing anti-bounce-tracking behavior. It removes the requirement that a suspected tracking site must have performed storage access in order to activate bounce tracking mitigations. Chrome's initially proposed bounce tracking mitigation solution triggers when a site accesses browser storage (e.g. cookies) during a redirect flow. However, bounce trackers can systematically circumvent such mitigations by using the HTTP cache to preserve data. By relaxing the triggering conditions for bounce tracking mitigations, the browser should be able to catch bounce trackers using the HTTP cache.



Blink component

Privacy>NavTracking

TAG review

https://github.com/w3ctag/design-reviews/issues/862

TAG review status

Not applicable

Risks



Interoperability and Compatibility

None



Gecko: Positive (https://github.com/mozilla/standards-positions/issues/835)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/214)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

There exists a section in Chrome devtools to try out bounce tracking mitigations (see link for context). It currently checks for the current (stateful) behavior and will be updated after the fact. Progress for devtools parity is tracked in https://crbug.com/399681359. https://developer.chrome.com/blog/bounce-tracking-mitigations-dev-trial#how_can_i_tell_if_my_site_is_impacted



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

This feature is supported on all platforms except WebView.



Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/nav-tracking-mitigations?label=master&label=experimental&aligned&q=nav-tracking-mitigations



Flag name on about://flags

None

Finch feature name

DIPS

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40264244

Launch bug

https://launch.corp.google.com/launch/4354304

Estimated milestones

Shipping on desktop 134


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/privacycg/nav-tracking-mitigations/pull/95

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6299570819301376?gate=5206396818423808

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67644489.2b0a0220.30ecd.0256.GAE%40google.com


This intent message was generated by Chrome Platform Status.

Mike Taylor

unread,
Feb 27, 2025, 5:02:41 PMFeb 27
to Chromestatus, blin...@chromium.org, l...@chromium.org, ort...@chromium.org, rtar...@chromium.org, sv...@chromium.org

On 2/27/25 3:46 PM, Chromestatus wrote:

Contact emails

l...@chromium.org, ort...@chromium.org, sv...@chromium.org, rtar...@chromium.org

Explainer

https://github.com/privacycg/nav-tracking-mitigations/issues/41#issuecomment-2504329542

Specification

https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations

Summary

Bounce tracking mitigations for the HTTP cache is an extension to existing anti-bounce-tracking behavior. It removes the requirement that a suspected tracking site must have performed storage access in order to activate bounce tracking mitigations. Chrome's initially proposed bounce tracking mitigation solution triggers when a site accesses browser storage (e.g. cookies) during a redirect flow. However, bounce trackers can systematically circumvent such mitigations by using the HTTP cache to preserve data. By relaxing the triggering conditions for bounce tracking mitigations, the browser should be able to catch bounce trackers using the HTTP cache.



Blink component

Privacy>NavTracking

TAG review

https://github.com/w3ctag/design-reviews/issues/862
It looks like https://github.com/w3ctag/design-reviews/issues/1062 is the correct link.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67c0cf33.2b0a0220.2c86e9.0223.GAE%40google.com.

Andrew Liu

unread,
Feb 27, 2025, 5:45:44 PMFeb 27
to blink-dev, Mike Taylor, Andrew Liu, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus
Fixed the link in chromestatus, thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Domenic Denicola

unread,
Mar 2, 2025, 9:35:30 PMMar 2
to blink-dev, Andrew Liu, Mike Taylor, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus
Can you request Privacy, WP Security, Enterprise, Debuggability, and Testing review gates in ChromeStatus?

Andrew Liu

unread,
Mar 3, 2025, 10:59:05 AMMar 3
to blink-dev, Domenic Denicola, Andrew Liu, Mike Taylor, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus
Done, requested reviews.

Mike Taylor

unread,
Mar 10, 2025, 5:16:00 PMMar 10
to Andrew Liu, blink-dev, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus

On 3/3/25 10:32 AM, Andrew Liu wrote:

Done, requested reviews.

On Sunday, March 2, 2025 at 9:35:30 PM UTC-5 Domenic Denicola wrote:
Can you request Privacy, WP Security, Enterprise, Debuggability, and Testing review gates in ChromeStatus?

On Friday, February 28, 2025 at 7:45:44 AM UTC+9 Andrew Liu wrote:
Fixed the link in chromestatus, thanks.

On Thursday, February 27, 2025 at 5:02:41 PM UTC-5 Mike Taylor wrote:
Can you point out which section covers the stateless bounce tracking? It's not obvious to me.



Summary

Bounce tracking mitigations for the HTTP cache is an extension to existing anti-bounce-tracking behavior. It removes the requirement that a suspected tracking site must have performed storage access in order to activate bounce tracking mitigations. Chrome's initially proposed bounce tracking mitigation solution triggers when a site accesses browser storage (e.g. cookies) during a redirect flow. However, bounce trackers can systematically circumvent such mitigations by using the HTTP cache to preserve data. By relaxing the triggering conditions for bounce tracking mitigations, the browser should be able to catch bounce trackers using the HTTP cache.



Blink component

Privacy>NavTracking

TAG review

https://github.com/w3ctag/design-reviews/issues/862
It looks like https://github.com/w3ctag/design-reviews/issues/1062 is the correct link.


TAG review status

Not applicable

Risks



Interoperability and Compatibility

None



Gecko: Positive (https://github.com/mozilla/standards-positions/issues/835)
What is the difference between 835 and https://github.com/mozilla/standards-positions/issues/1186? Is 1186 supposed to cover this particular change (not requiring storage access / considering the HTTP cache)? If so, could it be edited to reflect that?
Could we add a comment to this old issue informing them of this proposed change?

Yoav Weiss (@Shopify)

unread,
Mar 11, 2025, 7:26:28 AMMar 11
to blink-dev, Chromestatus, Andrew Liu, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org
On Thursday, February 27, 2025 at 9:46:54 PM UTC+1 Chromestatus wrote:
Contact emails l...@chromium.org, ort...@chromium.org, sv...@chromium.org, rtar...@chromium.org

Explainer https://github.com/privacycg/nav-tracking-mitigations/issues/41#issuecomment-2504329542

Specification https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations

Summary

Bounce tracking mitigations for the HTTP cache is an extension to existing anti-bounce-tracking behavior. It removes the requirement that a suspected tracking site must have performed storage access in order to activate bounce tracking mitigations. Chrome's initially proposed bounce tracking mitigation solution triggers when a site accesses browser storage (e.g. cookies) during a redirect flow. However, bounce trackers can systematically circumvent such mitigations by using the HTTP cache to preserve data. By relaxing the triggering conditions for bounce tracking mitigations, the browser should be able to catch bounce trackers using the HTTP cache.



Can you provide an example of a scenario flow that would trigger the new mitigations, and what the mitigations' impact would be.

e.g. If a link clicks results in a redirect through a page that loads an asset and then navigates away, would the asset being previously cached trigger the mitigations? Would the page itself being cached trigger them?

Once triggered, would the implications be that the asset/page are no longer cached? Or would there be other implications?

If the redirected page is still in its user activation lifetime period, does that change things?

Andrew Liu

unread,
Mar 11, 2025, 9:49:38 AMMar 11
to blink-dev, Yoav Weiss, Chromestatus, Andrew Liu, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org
On Tuesday, March 11, 2025 at 7:26:28 AM UTC-4 Yoav Weiss wrote:
On Thursday, February 27, 2025 at 9:46:54 PM UTC+1 Chromestatus wrote:
Contact emails l...@chromium.org, ort...@chromium.org, sv...@chromium.org, rtar...@chromium.org

Explainer https://github.com/privacycg/nav-tracking-mitigations/issues/41#issuecomment-2504329542

Specification https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations

Summary

Bounce tracking mitigations for the HTTP cache is an extension to existing anti-bounce-tracking behavior. It removes the requirement that a suspected tracking site must have performed storage access in order to activate bounce tracking mitigations. Chrome's initially proposed bounce tracking mitigation solution triggers when a site accesses browser storage (e.g. cookies) during a redirect flow. However, bounce trackers can systematically circumvent such mitigations by using the HTTP cache to preserve data. By relaxing the triggering conditions for bounce tracking mitigations, the browser should be able to catch bounce trackers using the HTTP cache.



Can you provide an example of a scenario flow that would trigger the new mitigations, and what the mitigations' impact would be.
There's a demo of a scenario that will trigger on the new behavior but not the old behavior at https://cr.kungfoo.net/mrpickles/http_cache/explainer/. The redirect basically bounces to a tracker site that loads a resource to get a random ETag. The tracker site then bounces to the final site while exfiltrating that ETag. Subsequent visits to the tracker URL will reuse the same ETag (since it's passed in the If-None-Match headers), so the ETag basically becomes a tracking ID. Old behavior would not recognize this as bounce tracking. New behavior would properly identify the tracker site and mark it for storage deletion (which includes the HTTP cache).

e.g. If a link clicks results in a redirect through a page that loads an asset and then navigates away, would the asset being previously cached trigger the mitigations? Would the page itself being cached trigger them?
The fact that a page or resource was cached isn't what makes a site eligible for mitigations. It's a matter of the site being in the middle of a bounce chain without any user activation. (To clear out any potential confusion, the feature name references the HTTP cache because that's main use case that these changes catch. The browser does not do anything novel with the HTTP cache specifically.)

Once triggered, would the implications be that the asset/page are no longer cached? Or would there be other implications?
Correct, the cache gets wiped (along with other storage, e.g. cookies). This is the same mitigations behavior that already exists. 

If the redirected page is still in its user activation lifetime period, does that change things?
Then the behavior remains the same as before. The page is not marked as a potential tracker, and nothing will happen to it. 

Andrew Liu

unread,
Mar 11, 2025, 9:52:00 AMMar 11
to blink-dev, Mike Taylor, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus, Andrew Liu
On Monday, March 10, 2025 at 5:16:00 PM UTC-4 Mike Taylor wrote:

On 3/3/25 10:32 AM, Andrew Liu wrote:

Done, requested reviews.

On Sunday, March 2, 2025 at 9:35:30 PM UTC-5 Domenic Denicola wrote:
Can you request Privacy, WP Security, Enterprise, Debuggability, and Testing review gates in ChromeStatus?

On Friday, February 28, 2025 at 7:45:44 AM UTC+9 Andrew Liu wrote:
Fixed the link in chromestatus, thanks.

Can you point out which section covers the stateless bounce tracking? It's not obvious to me.
The stateless modifications are in this pull request: https://github.com/privacycg/nav-tracking-mitigations/pull/95. ChromeStatus mentioned I should prefer the published spec link over unmerged PRs; would you recommend I use the PR link instead in this case? 



Summary

Bounce tracking mitigations for the HTTP cache is an extension to existing anti-bounce-tracking behavior. It removes the requirement that a suspected tracking site must have performed storage access in order to activate bounce tracking mitigations. Chrome's initially proposed bounce tracking mitigation solution triggers when a site accesses browser storage (e.g. cookies) during a redirect flow. However, bounce trackers can systematically circumvent such mitigations by using the HTTP cache to preserve data. By relaxing the triggering conditions for bounce tracking mitigations, the browser should be able to catch bounce trackers using the HTTP cache.



Blink component Privacy>NavTracking

TAG review https://github.com/w3ctag/design-reviews/issues/862
It looks like https://github.com/w3ctag/design-reviews/issues/1062 is the correct link.


TAG review status Not applicable

Risks


Interoperability and Compatibility

None



Gecko: Positive (https://github.com/mozilla/standards-positions/issues/835)
What is the difference between 835 and https://github.com/mozilla/standards-positions/issues/1186? Is 1186 supposed to cover this particular change (not requiring storage access / considering the HTTP cache)? If so, could it be edited to reflect that?
Yeah, 1186 was opened to highlight the stateless changes. Edited the ChromeStatus entry. 
Could we add a comment to this old issue informing them of this proposed change?
Done. 

Mike Taylor

unread,
Mar 11, 2025, 12:08:50 PMMar 11
to Andrew Liu, blink-dev, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus

On 3/11/25 9:52 AM, Andrew Liu wrote:

On Monday, March 10, 2025 at 5:16:00 PM UTC-4 Mike Taylor wrote:

On 3/3/25 10:32 AM, Andrew Liu wrote:

Done, requested reviews.

On Sunday, March 2, 2025 at 9:35:30 PM UTC-5 Domenic Denicola wrote:
Can you request Privacy, WP Security, Enterprise, Debuggability, and Testing review gates in ChromeStatus?

On Friday, February 28, 2025 at 7:45:44 AM UTC+9 Andrew Liu wrote:
Fixed the link in chromestatus, thanks.

Can you point out which section covers the stateless bounce tracking? It's not obvious to me.
The stateless modifications are in this pull request: https://github.com/privacycg/nav-tracking-mitigations/pull/95. ChromeStatus mentioned I should prefer the published spec link over unmerged PRs; would you recommend I use the PR link instead in this case?
Thank you. My personal opinion is that an unmerged PR is more useful in the chromestatus entry than a link to a spec that is missing the relevant proposed changes. But, even better is merging the PR and linking to the spec. So, what is preventing us from doing that in this case?

Andrew Liu

unread,
Mar 11, 2025, 12:15:01 PMMar 11
to blink-dev, Mike Taylor, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus, Andrew Liu
On Tuesday, March 11, 2025 at 12:08:50 PM UTC-4 Mike Taylor wrote:

On 3/11/25 9:52 AM, Andrew Liu wrote:

On Monday, March 10, 2025 at 5:16:00 PM UTC-4 Mike Taylor wrote:

On 3/3/25 10:32 AM, Andrew Liu wrote:

Done, requested reviews.

On Sunday, March 2, 2025 at 9:35:30 PM UTC-5 Domenic Denicola wrote:
Can you request Privacy, WP Security, Enterprise, Debuggability, and Testing review gates in ChromeStatus?

On Friday, February 28, 2025 at 7:45:44 AM UTC+9 Andrew Liu wrote:
Fixed the link in chromestatus, thanks.

Can you point out which section covers the stateless bounce tracking? It's not obvious to me.
The stateless modifications are in this pull request: https://github.com/privacycg/nav-tracking-mitigations/pull/95. ChromeStatus mentioned I should prefer the published spec link over unmerged PRs; would you recommend I use the PR link instead in this case?
Thank you. My personal opinion is that an unmerged PR is more useful in the chromestatus entry than a link to a spec that is missing the relevant proposed changes. But, even better is merging the PR and linking to the spec. So, what is preventing us from doing that in this case?
I don't have permissions in the repo to merge the PR. I formally became a spec editor a week ago, but GH permission changes have to go through the PrivacyCG chairs. The previous editors have requested that new editors (e.g. me) merge any future PRs. So at this point I'm blocked (until their next meeting, which is on Thursday, I suspect). I've switched the ChromeStatus field to point to the PR in the meantime. I'll switch it back once the PR is merged.

Martin Thomson

unread,
Mar 11, 2025, 10:12:49 PMMar 11
to Andrew Liu, blink-dev, Mike Taylor, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus
On Wed, 12 Mar 2025 at 03:15, Andrew Liu <l...@chromium.org> wrote:

I don't have permissions in the repo to merge the PR. I formally became a spec editor a week ago, but GH permission changes have to go through the PrivacyCG chairs.

I’ve fixed that. It was an oversight on the part of the chairs.

However, I do want to ask you whether you believe that there is consensus to make this change. Or process gives editors broad discretion in these cases, but we do expect editors to engage with the group and try to judge what support there is.

Andrew Liu

unread,
Mar 12, 2025, 10:45:30 AMMar 12
to blink-dev, Martin Thomson, blink-dev, Mike Taylor, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus, Andrew Liu
There has been support within Google and with Mozilla. I have not encountered any opposition to the change either. We can also discuss the details during the next PrivacyCG meeting. I won't merge anything until folks are comfortable with the change. 

Martin Thomson

unread,
Mar 12, 2025, 5:20:33 PMMar 12
to Andrew Liu, blink-dev, Mike Taylor, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus
You don't need to wait (I just saw Emma's response) if you believe that the change has sufficient support.  You are editor.  I just hadn't seen ANY response to the proposed change outside of folks who appear to be your Google colleagues, which made me question; that's all.

Alex Russell

unread,
Mar 17, 2025, 2:12:47 PMMar 17
to blink-dev, Martin Thomson, blink-dev, Mike Taylor, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus, Andrew Liu
LGTM1 on the condition that this is launched with a fractional rollout and good histograms to provide a way to detect breakage as we go and kill-switch it if we detect some.

Have y'all discussed with enterprise customers?

Best,

Alex

Andrew Liu

unread,
Mar 17, 2025, 2:57:23 PMMar 17
to blink-dev, Alex Russell, Martin Thomson, blink-dev, Mike Taylor, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus, Andrew Liu
On Monday, March 17, 2025 at 2:12:47 PM UTC-4 Alex Russell wrote:
LGTM1 on the condition that this is launched with a fractional rollout and good histograms to provide a way to detect breakage as we go and kill-switch it if we detect some.

Thanks! All of that sounds good and is part of the plan. 

Have y'all discussed with enterprise customers?

It's gone through the enterprise review, if that's what you're referring to. 

Mike Taylor

unread,
Mar 18, 2025, 8:34:15 AMMar 18
to Andrew Liu, blink-dev, Alex Russell, Martin Thomson, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus

Thanks for getting the spec PR merged - LGTM2

Yoav Weiss (@Shopify)

unread,
Mar 18, 2025, 1:39:55 PMMar 18
to Mike Taylor, Andrew Liu, blink-dev, Alex Russell, Martin Thomson, Domenic Denicola, Giovanni Ortuno Urquidi, rtar...@chromium.org, sv...@chromium.org, Chromestatus
LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/305a71c7-702e-4253-bac7-1142656625f4%40chromium.org.
Reply all
Reply to author
Forward
0 new messages