Intent to ship: Network Partitioning

[Tim Huang]

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,