Repository navigation
Double-keyed HTTP cache #904
Description
The idea here is that the "browser's address bar origin" is an additional key for its HTTP cache, to prevent certain classes of attacks.
Safari ships a variant of this (uses registrable domain, not origin), but seems willing to adjust to origin. Other implementers are interested in shipping and are at various stages of experimentation.
This will require making all accesses of "the HTTP cache" more contextual, by accessing the HTTP cache of X whereby X is some defined origin. (Other ideas welcome, @mnot?)
I'm not sure where to store the defined origin. We could do a browsing context ancestor walk and that might be okay as I think all fetches always require a fully active document, but would be nice to have that confirmed.
(I'm also assuming that auxiliary browsing contexts are not special here and behave like other top-level browsing contexts for the purposes of this.)
cc @youennf @whatwg/security
Activity
mikewest commentedon May 9, 2019
/cc @jkarlin for Chrome's experimental implementation.
youennf commentedon May 9, 2019
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.
jkarlin commentedon May 9, 2019
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.
wanderview commentedon May 9, 2019
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.
mnot commentedon May 9, 2019
+1
It would be nice to try to factor out cache key computation to support not only this, but things like variants, etc.
annevk commentedon May 10, 2019
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.
johnwilander commentedon May 10, 2019
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.
jkarlin commentedon May 10, 2019
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
annevk commentedon May 10, 2019
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.
jkarlin commentedon May 17, 2019
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:
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.
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
youennf commentedon May 17, 2019
@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.
22 remaining items
shivanigithub commentedon Sep 26, 2019
Created a pull request for the spec change: #943
shivanigithub commentedon Jan 10, 2020
The html spec change to define top-level origin is in progress at: whatwg/html#4966
jkarlin commentedon Jan 10, 2020
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.
Define the top-level origin of an environment settings object
annevk commentedon Mar 24, 2020
#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.
Define HTTP cache partitioning
Define HTTP cache partitioning
rugabunda commentedon Jul 10, 2020
@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
"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.
"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,
rugabunda commentedon Jul 10, 2020
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. "
Remove third-party caching misconception
Remove third-party caching misconception (#4517)
Define HTTP cache partitioning