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

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.)

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).

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?

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?).

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.

Per https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md it seems that @wanderview et al plan to use

<top-frame-site>

I don't think that is accurate. The SW partitioning proposal would effectively key on <top-frame-site, document-site> where the document-site is equal to the service worker origin's site. This is enforced by service workers being same-origin to any controlled documents.

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.