Repository navigation
Should network state be keyed beyond the top-level site #1035
Description
See shivanigithub/http-cache-partitioning#2 and #943 for some background. Currently the (proposed) prose allows for an additional key, but doesn't define what it is.
Activity
gsnedders commentedon Sep 14, 2021
I think we want to continue to allow an additional implementation defined key; there are different trade-offs here and one can imagine features like Firefox/Safari's (Intelligent) Tracking Protection making different trade-offs here depending on setting. In principle this should be transparent, and I'm unaware of much breakage caused by different cache keying. One can also imagine different strategies being taken by different UAs in "private browsing mode".
cc @johnwilander
annevk commentedon Sep 14, 2021
For this issue I'm mainly interested in whether we consider it a security issue or not. And whether Chrome's solution addresses that comprehensively or not. (And I guess there's also a question as to whether a comprehensive solution is needed or something is better than nothing at all.)
MattMenke2 commentedon Sep 14, 2021
The reason for additional keys is to protect spying across cross-site frames in the same tab, which is much more a security issue than a privacy one. Sites can coordinate to provide each other this information, if they want, but extracting it from other sites without their cooperation is a cross-site attack.
For the record, Chrome's solution is to use iframe site and an additional bit set for iframes - so an attacker can potentially figure out what's loaded in other frames / what other frames navigate to, but not what they're doing internally.
The potential issues with Chrome's scheme are around performance (If https://a.com loads https://b.com resources, which then populate an https://b.com iframe, we'd need a new set of https://b.com connections for the iframe), resource exhaustion, and potentially making certain resource exhaustion attacks marginally easier (e.g, can max out the socket pools with fewer domains).
annevk commentedon Sep 22, 2021
So from shivanigithub/http-cache-partitioning#2 my best understanding is that Chrome uses
<top-frame-site, document-site>as key for most network state, except for the HTTP cache where
<top-frame-site, document-site, is-iframe-navigation>is used.
Per https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md it seems that @wanderview et al plan to use
<top-frame-site>for service workers and storage in general.
Wouldn't that mean that if you adopt service workers and cache resources therein you have a vulnerability you previously did not?
MattMenke2 commentedon Sep 22, 2021
Do you mean SWs are more vulnerable than the non-SW behavior where they previously were not (which is true-ish, assuming SW's aren't currently more vulnerable than the non-SW case), or that SW's are more vulnerable than they previously were (which I don't think is the case?).
annevk commentedon Sep 22, 2021
Yeah, I'm saying that if we were to consider this to be a security vulnerability the solution for service workers (storage) does not seem adequate. Websites that adopt service workers would become vulnerable to attacks this defends against.
wanderview commentedon Sep 22, 2021
I don't think that is accurate. The SW partitioning proposal would effectively key on
<top-frame-site, document-site>where thedocument-siteis equal to the service worker origin's site. This is enforced by service workers being same-origin to any controlled documents.wanderview commentedon Sep 22, 2021
Service workers could carry the "iframe-navigation bit" forward through a pass-through fetch if we wanted to. Ideally this would be tied to the destination, but it could also be a separate flag.
recvfrom commentedon Feb 14, 2025
To give my understanding of the current state, at least w.r.t. the HTTP cache:
Since the discussion in this thread is a few years old, I was wondering if there might be any new thoughts regarding standardizing HTTP cache partitioning by more than top-level site. WDYT? Is additional keying for the HTTP cache in Safari / Firefox something that is being / might be considered?
Regarding the issue discussed for service worker caching, would it make sense to track that problem in a separate issue?
CC @artines1 @bvandersloot-mozilla
[1] https://webkit.org/tracking-prevention/#partitioned-third-party-http-cache
[2] https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#network_partitioning
[3] https://hg.mozilla.org/mozilla-central/rev/94ed4d6361b3
MattMenke2 commentedon Feb 14, 2025
I think it's worth noting that the connection layers of Chrome's network stack are keyed only on top-level site + is-cross-origin. Chrome also has a nonce used in some cases (fenced frames) that disables caching and partitions the connection layers as well, and it's introducing another enum for certain cases where requests need to be isolated, but we still want them cached to disk (Currently targeted at the new federated login APIs, which I can't remember the name of, and certain Protected Audiences fetches). The enum will apply to connections and the HTTP disk cache.
annevk commentedon Feb 27, 2025
cc @sysrqb
theIDinside commentedon Jan 5, 2026
I think that it should be. Currently, none of the browsers have any way of distinguishing, for Reporting API purposes (NEL, specifically that relies on determine network partition key), between two processes (or just two different tabs) that has the same origin stuff, but different end point configurations.
This can be seen in a test currently written in gecko here which means that, two different tabs or iframes (the test uses iframes), can pollute each other's endpoints, because the keying is not unique enough. It needs to be more unique, than effectively just top level origin for things like Reporting API (or at least NEL).