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, rtarp...@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 <https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-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. Blink component Privacy>NavTracking <https://issues.chromium.org/issues?q=customfield1222907:%22Privacy%3ENavTracking%22> 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/sta ndards-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-mitigation s-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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Yes https://wpt.fyi/results/nav-tracking-mitigations?label=maste r&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/featu re/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 <https://chromestatus.com>. -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6521278f-0e87-4bb6-bcda-e38ee22c003cn%40chromium.org.
