Intent to ship: Network Partitioning # Summary There are many tracking vectors that can be used by advertising networks to track users across websites. One major category of tracking vectors is known as “Supercookies,” which are stored in browsers and are difficult for users to detect and remove. The network state can be abused by trackers as a “Supercookie” to track users. For example, the HTTP cache was not designed for storing data like cookies, but it can be abused for the purposes of tracking or identifying users [0][1].
Client-Side Storage Partitioning [2] has outlined the strategy that we are going to adopt to protect users from the aforementioned problem. As a part of it, Network partitioning implements the protection for network state. When enabling network partitioning, Firefox will use the top-level site, i.e., its URL’s scheme and URL’s host’s registrable domain (eTLD+1), as an additional key for network state. In other words, when doing an HTTP cache entry lookup, it will not only use the URL to search the entry but use the URL keyed by the top-level site. Note that partitioning network state could have a performance impact because the network caches cannot be reused for different top-level sites. A resource that has been cached for one top-level site still needs to make a network request if another top-level site loads the same resource. This could increase the overall loading time. The protection of the Network Partitioning covers assorted network state, including - HTTP cache - Image cache - Favicon cache - Connection pooling - StyleSheet cache - DNS - HTTP authentication - Alt-Svc - Speculative connections - Font cache - HSTS - OCSP - Intermediate CA cache - TLS client certificates - TLS session identifiers - Prefetch - Preconnect - CORS-preflight cache We have enabled Network Partitioning since Firefox 78 in Nightly channel and Firefox 83 in the early Beta channel. We will enable it by default in Firefox 85. As Network Partitioning ships we will be running studies to monitor the performance impact of these changes, and may adjust the timeline if we find that it has a severe impact. # Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1590107 # Standard https://privacycg.github.io/storage-partitioning/ https://fetch.spec.whatwg.org/#http-cache-partitions # Platform coverage All # Preference privacy.partition.network_state # DevTools bug N/A # Other browsers Safari: Safari has shipped the network partitioning since 2013, see https://bugs.webkit.org/show_bug.cgi?id=110269. Chrome: Chrome has sent an intent-to-ship for partitioning the HTTP cache[3]. And they have implemented the CORS-preflight cache partitioning. The metrics of the performance impact of enabling HTTP cache partitioning in Chrome have been summarized here[4]. # Web-platform-tests https://github.com/web-platform-tests/wpt/blob/master/fetch/http-cache/split-cache.html https://github.com/web-platform-tests/wpt/blob/master/cors/preflight-cache-partitioning.sub.window.js [0]: https://polict.net/blog/web-tracking-via-http-cache-xs-leaks/ [1]: https://github.com/xsleaks/xsleaks [2]: https://privacycg.github.io/storage-partitioning/ [3]: https://groups.google.com/a/chromium.org/g/blink-dev/c/NUR-gpWxSZ4/m/9boB-VrlBwAJ [4]: https://github.com/shivanigithub/http-cache-partitioning#impact-on-metrics Best, Tim Huang, _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
