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