/cc @jkarlin for Chrome's experimental implementation.

Safari is partitioning service workers so that a service worker of an iframe B in a top level page A will be using the partition of top level page A.
This makes the loading more consistent in general (whether intercepted or not, the iframe loads will use the same partition) and improves on privacy.

Very interested. We'd like to mitigate security issues such as x-site search.

Chrome's experimenting with double keying by (top-frame origin, url) as well as triple-keying (top-frame origin, initiator origin, url). Triple keying protects caches of frames within a page from each other. The performance hit from double-keying seems reasonable at first glance, but it's important that we address x-origin prefetch in a multi-keyed cache world. We don't yet have data on triple-keying.

This issue should also consider the differences between partitioned http cache and partitioned origin storage. I believe webkit's default partitioning include both http and origin storage. I don't think the chrome experiment includes any origin storage partitioning, though.

+1

It would be nice to try to factor out cache key computation to support not only this, but things like variants, etc.

Mozilla is interested in partitioning other bits as well, but for this issue I'd like to focus solely on the HTTP cache. Some of the infrastructure we might be able to reuse for the other bits mentioned above, but I don't think there's any strong reason to couple them from the start.

WebKit also partitions LocalStorage on eTLD+1 and used to partition cookies up until a couple of months ago (now the same cookies for third parties are just blocked instead).

In the case of partitioned LocalStorage, it is also not persisted which makes into a slightly weird SessionStorage.

I think eTLD+1 makes a lot of sense for partitioning unless we’re seeing (or expect to see) attacks that would be fixed with origin partitioning. However, as Youenn said, we’d be willing to harmonize with other implementers for consistency.

I'm a proponent of origin as it's the security boundary for most aspects of the browser and easier to reason about.

/cc @sleevi

Since the cache attacks are not that involved it seems rather risky to not do origin-based as it would mean a compromise of any example.com domain could be used to attack sensitive.example.com.

Another question is how we deal with x-origin <link rel=prefetch>. Which cache key does the prefetch use? If it winds up in the prefetching page's cache, it's a waste of network. But how do we know which key should be used?

I know of two options to make x-origin prefetch still work:

1. Allow prefetched resources to be used once within 5 minutes after prefetching, regardless of the cache key. This opens a one-way communication channel between the page that prefetched the resources and the one that consumes them.

2. Allow prefetched resources to be used once regardless of cache key so long as the page loading the resource was navigated to directly (for some definition of directly) by the page that performed the prefetch. This also forms a one-way communication channel between the page that prefetched and the one that used it, but they had a channel available anyway (link decoration).

/cc @yoavweiss @kinu

@jkarlin, there is an on-going implementation of prefetch with double key caches in WebKit.
So far, the implementation does not take into account which page is consuming the prefetch.
#881 is related.

Great, let's leave the prefetch discussion in #881 then. We're still doing the work to compare performance of double vs triple keying the network stack. Sorry for taking so long. Note that we're planning on using this key for the entire network stack (memory cache, disk cache, socket pools, etc).

In terms of a spec for the double keyed cache, would appreciate inputs on what's a good place to spec it, possibly the Fetch whatwg spec.

@shivanigithub if you want to help with this that'd be great! My thinking here involved changes to the Fetch and HTML standards. In particular:

• Change HTML such that it ends up exposing a "first-party origin" field on its environment settings object. This will likely require changes to document object creation and worker creation to store the state and changes to the environment settings object to expose it (similar to how we do it for other such state, such as referrer policy).
• Change Fetch such that it copies a request's client's first-party origin on a new first-party origin field on the request object.
• Change Fetch such that whenever it talks about "the HTTP cache" it instead gets an HTTP cache via the first-party origin somehow. I'm not sure how detailed we want to make this, but we probably want to at least have a couple of words describing what it means to get an HTTP cache for a particular origin. Perhaps this can borrow wording from how we deal with connections.

Hope that helps!

@annevk I suspect we'd also need to update connection pools as well to extend that concept. Or were you thinking of doing it separately? I wasn't sure if #904 (comment) extended to those changes as well?

I ask, because I'm wondering if it makes sense if, similar to how "connection" is defined as an aggregate of both origin and credentials, it might make sense to define the concept as an aggregate function (which is made up of, for now, first-party origin, a singular value), which would then

1. Allow you to extend the definition if there are other attribute keys (e.g. TBB uses the TOR circuit ID as part of the key, IIRC)
2. Allow that concept to be reused between the "connection group" and "HTTP cache".

Incrementalism also works, I just wanted to make sure that was your goal.

@sleevi I'd like changes to connections to be a separate change, but it does make sense to me to iterate toward that. Would you mind opening an issue on that and elaborate a bit on the thinking behind it there? I understood there to be an issue with sites being able to reach the global connection limit, but that would not necessarily disappear with a first-party origin key on connection pools I think.

Filed #917. My understanding is that UAs doing this partitioning are doing so for privacy reasons, and hopefully #917 explains why those privacy reasons aren't functionally achievable without a similar partitioning/keying of the connection pool.

@annevk Thanks for the inputs. Looking into these.

@annevk Regarding the spec inputs, am I correct in understanding that the proposed "first-party origin" field on the the environment settings object is an output field populated by the browser to indicate the key being used and not an input to the browser?

I'm not entirely sure what you mean, but yes, the browser (i.e., user agent) is responsible for setting it.

Few clarifications for spec changes:
Chrome's experimenting with double keying (top-frame origin, url) as well as triple-keying (top-frame origin, frame origin, url). From a spec perspective how much in detail do we want to go in the contents of the partitioning key?
E.g. in the fetch spec, would something like this make sense:

[Already existing text]
A request has an associated cache mode, which is "default", "no-store", "reload", "no-cache", "force-cache", or "only-if-cached". Unless stated otherwise, it is "default".

[New text added following the above]
The user agent might partition the HTTP cache using a partitioning key and references to the HTTP cache in this spec refer to a partitioned cache, when applicable. If the cache is partitioned, it will be looked up using the request URL and the top-frame origin (and possibly also the frame origin) instead of just the request URL.

I think at the very least we should define top-level origin from first principles and use that as the key as all browsers plan to align on that. Allowing additional keys seems reasonable. I also think we should be more explicit and update the various lookup points to pass in the appropriate keys.

My current thinking is that for caches we want something analogous to https://fetch.spec.whatwg.org/#connections with a way to obtain a cache given some keying material.

+1 to this. It seems that, from an infrastructure perspective, declaring that the client has multiple caches, similar to how we do for connection pools (which would presumably be extended in #917), would work.

That is, a given request has an associated HTTP cache derived from the primary key(s) (e.g. the top-frame origin or the top-frame-origin+initiator). When performing an http-network-or-cache-fetch, the cache object for the request is used to fetch the request URL.

This would allow the rest of the infrastructure to naturally work, by conceptually stating there are multiple caches (similar to how Service Workers do with the Cache object). An implementation would be able to implement this using a single logical disk store by double-keying/triple-keying, which should be indistinguishable from the spec.

Thanks for the inputs! Makes sense to focus on updating the whatwg fetch spec for this change and the cache issue can take care of cleaning up the relevant cache key definitions in the IETF RFC.

Created a pull request for the spec change: #943

The html spec change to define top-level origin is in progress at: whatwg/html#4966

I wanted to loop back to the earlier discussion on origin vs eTLD+1 for partitioning the cache. We've come across sites where frames are significantly impacted by triple-keying with origin but not eTLD+1. As such, we intend to proceed with scheme+eTLD+1 instead of origin and (like site isolation) hope to transition to origin at a later point.

#943 is almost ready to land. Now would be a good time to speak up if you need more time to review or some such. Otherwise it'll go in tomorrow or Thursday I suspect.

The initial version uses the top-level site (not origin after all, mind) as the additional HTTP cache key.

@annevk @mozfreddyb, for efficiency concerns, implement local CDN emulation; similar to this firefox/chrome addon, probably the best example which currently covers the highest number of CDNs out there at the moment: https://codeberg.org/nobody/LocalCDN

"A web browser extension that emulates Content Delivery Networks to improve your online privacy. It intercepts traffic, finds supported resources locally, and injects them into the environment."

re: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/6KKXv1PqPZ0/discussion

1. "This month, July 2019, cdnjs served almost 190 billion requests ... Lodash (4.17.11) skyrocketed to the top of the list this month with 8.7 billion requests."[1]
   I imagine the cache efficiency lost due to this change for this CDN alone (jQuery, lodash, etc) will be massive.

2. "Approximately 100% of the Fortune 500 already use npm to acquire approximately 97% of their JavaScript code." [2]
   Pika is creating a CDN for modern npm packages that can run in the browser. The project is only a few months old today, but with ESM it becomes feasible for sites to load their npm dependencies from our CDN (or UNPKG, or another cross-origin CDN like it) in production. Basically, cdnjs for npm. In that world, every npm package would only be loaded once across all participating sites, and would then be cached and reused on future visits. Imagine if most sites never had to load React, ReactDOM, Preact, Vue, the 100 most popular npm packages, etc.

Obviously security is a huge concern, and I completely understand and appreciate the work being done here. But I'd want to make sure that an important performance story on the web isn't accidentally destroyed in the process.

If this proposal does continue to move forward, I'd at least want an opt-in proposal discussed, either via the existing Cache-Control header, a new header, or some other mechanism. I do not believe that either of the two concerns outlined above were reasonably serious: We're talking about a small number of CDN-related cookies, and in practice the "Detect if a user has visited a specific site" attack-surface would be negligible (and again, opt-in). I'm happy to contribute / get involved if time & effort is a blocker here.

Thanks again,

• FKS

The next step would be automated local CDN emulation which is separated into its own cache using a detection mechanism that determines if the same resource has been accessed over multiple websites; similar to privacy badger, which "If an advertiser seems to be tracking you across multiple [three] websites without your permission, Privacy Badger automatically blocks that advertiser from loading any more content in your browser. "