Contact emails
shiva...@chromium.org, jka...@chromium.org
Explainer
https://github.com/whatwg/fetch/issues/904
Design docs/spec
TAG review
Not yet started
Summary
The HTTP cache is currently one-per-profile, with a single namespace for all resources regardless of origin or renderer process. This opens the browser to a side-channel attack where one site can detect if another site has loaded a resource by checking if it’s in the cache.
This feature will partition the HTTP cache using top frame origin (and also possibly the subframe origin) to prevent documents from one origin from knowing if a resource from a cross-origin document load was cached or not.
From a performance perspective, preliminary experiments with partitioning using top-frame-origin show that the cache hit rate drops by about 4% but changes to first contentful paint aren’t statistically significant and the overall fraction of bytes loaded from the cache only drops from 39.1% to 37.8%. This may change as we flesh out the implementation and progress to larger populations but it’s an encouraging start.
Motivation
Cache attacks have been exploited for the following:
Cross-site search attack: There exist cross site search attack proofs-of-concept which exploit the fact that some popular sites load a specific image when a search result is empty. By opening a tab and performing a search and then checking for that image in the cache, an adversary can detect if an arbitrary string is in the user’s search results.
Detect if a user has visited a specific site: If the cached resource is specific to a particular site or to a particular cohort of sites, an adversary can detect user’s browsing history by checking if the cache has that resource.
In addition to the above cache attacks, the cache can also be used to store cross-site super-cookies as a fingerprinting mechanism. To clear them the user has to delete their entire cache (not just a particular site). Since fingerprinting is neither transparent nor under the user’s control, it results in tracking that doesn’t respect user choice.
Interoperability and Compatibility
Mozilla is interested in this and Safari has long since implemented a variant of it by using eTLD+1 to partition the cache. This is the github issue with inputs from various browsers.
Firefox: Public support
Edge: No public signals
Safari: Public support
Web developers: This is not a breaking change, but it will have performance considerations for some organizations. For instance those that serve large volumes of highly cacheable resources across many sites (e.g., fonts and popular scripts). This needs to be balanced with the privacy and security concerns and the fact that sites often use different versions of popular libraries, reducing the benefits of such caching. It’s also worth reiterating that Safari has already partitioned its cache and that Firefox has signaled that it wants to as well.
Security
It is an enhancement of security as detailed in the threat model document linked above.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
It is intended to be tested by web platform tests.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5730772021411840
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1f29f0a0-acc1-41e6-838b-90ad87baebdf%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z5uf2hykrbppqq%40cicero2.linkoping.osa.
Was it considered to not do so if the response cache header is set to public, or adding a magic op-in global cache header?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKvVKiV_x%3DDC2zuc-z2NCFqthfVMeT9L_TS2o6cyujjMbpJVUA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1f29f0a0-acc1-41e6-838b-90ad87baebdf%40chromium.org.
--/* Opera Software, Linköping, Sweden: CEST (UTC+2) */
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z5uf2hykrbppqq%40cicero2.linkoping.osa.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/298c2807-20f7-4852-b845-2cc9cedbf0b2%40chromium.org.
Are there plans to somehow partition the (service worker) cache API? If yes, this might have very observable effects and if not, this HTTP cache partitioning will only help in simple cases, right?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BYVbgCWyKVuLZpjzd%3DZ2XbvDiOMKCCGiAKQUpe7JXkRA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/298c2807-20f7-4852-b845-2cc9cedbf0b2%40chromium.org.
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/6KKXv1PqPZ0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaDou6%2BnsTFJMCsFreYqszVWxmWgwe9mfQ5mVCD11UNoLA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/39f62836-9263-4bcd-b4fd-d26fe8c8484a%40chromium.org.
Not only that, but also wasm compiled code and js bytecode wont be shared.Its another big perf and resources lose
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKvVKiU_94RH9%2Bu%3Dz54BrNXW_AArma3YFiGu4eO3WB2oDddY3w%40mail.gmail.com.
Context: I created and operate https://pika.dev/cdn.
First off, thanks for the hard work and thoughtful considerations you all have put into this important security feature so far.
To build on Kevin's post, this suggested change would kill the cache efficiency story of cross-origin CDNs, which is troubling to me for a few reasons. The ability to cache resources across domains is a huge benefit to using cross-origin CDNs at scale. The more use that they get, the more likely cache hits are, and the faster those websites become (potentially loading instantly, or at the very least faster than if they'd served JS on their own origin). Two examples:
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
tldr: https://twitter.com/rektide/status/1156261839623401472
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/6KKXv1PqPZ0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9319a175-3e18-4ad4-a9fa-4ea723089331%40chromium.org.
Maybe I'm missing it, but scrolling up, I don't see anyone showing the increase in cache misses. We do have some numbers that I've seen in internal documents, and they are happily much lower than you might think. Googlers, can we publish them?
To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9319a175-3e18-4ad4-a9fa-4ea723089331%40chromium.org.
Maybe I'm missing it, but scrolling up, I don't see anyone showing the increase in cache misses. We do have some numbers that I've seen in internal documents, and they are happily much lower than you might think. Googlers, can we publish them?
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/6KKXv1PqPZ0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78iq%2Bahg8H59kR6RjDXrW%2Bx-Fnwepg7AZWgw0XnOFLrkVQ%40mail.gmail.com.
That continues to have the same problem (as I think was already
mentioned upthread). It's not up to you to decide that it's okay to
reveal that a user visited a site.
Also, we here don't have all the information necessary to determine what the full risk is, what the consequences are, and how much reduction of risk is 'enough'.
On Tue, Aug 27, 2019 at 10:02 AM Anne van Kesteren <ann...@annevk.nl> wrote:
On Tue, Aug 27, 2019 at 5:02 PM Ben Kelly <wande...@chromium.org> wrote:
> Is the risk reduced if we can determine the resource is linked from a statistcally significant number of sites in the wild? For example, some list of hashes of "widely shared resources" based on http archive, etc.
Things that come to mind:
1. Building the infrastructure to support such assertions.
2. Authorities that block N-M of those sites and are interested in who
visits the remainder.
3. Or instead of authorities, there might be other groupings of such
sites that are not immediately apparent, such that only one of them is
in a different language and likely has a different audience, etc.
At the last W3C TPAC there was some hallway discussion among
implementers on how to do cross-site caches and nobody was really able
to come up with a privacy-preserving scheme. Doesn't mean there isn't
one of course, but it seems quite tricky.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/6KKXv1PqPZ0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.
I agree, some sort of "safelist" seems tough on multiple fronts.That continues to have the same problem (as I think was alreadymentioned upthread). It's not up to you to decide that it's okay to
reveal that a user visited a site.To challenge this assertion: As a cross-site CDN owner with cross-site caching enabled (either always on or through some opt-in header), you are signaling to site owners that it has this small potential vulnerability. And then that site owner has the choice to either use that service, or not. The nice thing about public CDNs is that they are rarely (never?) the only option, and a security conscious user could host those assets themselves.
--I see that as more of an agreement between the service and the site owner, making this call based on the context & information that they have.The real risk (as I understand it) that we're all working to mitigate is that this is currently on for everyone by default, and not that public CDNs alone are good targets for this sort of attack & worth the performance hit.On Tuesday, August 27, 2019 at 10:33:09 AM UTC-7, Chris Palmer wrote:Also, we here don't have all the information necessary to determine what the full risk is, what the consequences are, and how much reduction of risk is 'enough'.On Tue, Aug 27, 2019 at 10:02 AM Anne van Kesteren <ann...@annevk.nl> wrote:On Tue, Aug 27, 2019 at 5:02 PM Ben Kelly <wande...@chromium.org> wrote:
> Is the risk reduced if we can determine the resource is linked from a statistcally significant number of sites in the wild? For example, some list of hashes of "widely shared resources" based on http archive, etc.
Things that come to mind:
1. Building the infrastructure to support such assertions.
2. Authorities that block N-M of those sites and are interested in who
visits the remainder.
3. Or instead of authorities, there might be other groupings of such
sites that are not immediately apparent, such that only one of them is
in a different language and likely has a different audience, etc.
At the last W3C TPAC there was some hallway discussion among
implementers on how to do cross-site caches and nobody was really able
to come up with a privacy-preserving scheme. Doesn't mean there isn't
one of course, but it seems quite tricky.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/6KKXv1PqPZ0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78iq%2Bahg8H59kR6RjDXrW%2Bx-Fnwepg7AZWgw0XnOFLrkVQ%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/695baa88-a67c-4254-afe9-31667199eb9e%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e97c1ff4-8baa-48b1-9468-c67a9b7e4c11%40chromium.org.
For reference, this doc, started by Mozilla, captures the discussions around privacy-preserving cross-origin caching that occurred at the last TPAC.
On Fri, Aug 30, 2019 at 12:58 AM Dominic Farolino <d...@chromium.org> wrote:
> I wonder how many extra MB or GB of space a users cache will be after this change.--I guess similar to the average cache size of Safari users, since Chrome isn't the first implementation to explore making this sort of change. Also you'll probably be interested in https://groups.google.com/forum/#!msg/mozilla.dev.platform/eFx-93iBPpU/Hs4jUZRgDgAJ.I know a lot of people have been asking about the current metrics Chrome has collected, and for a deeper explanation as to why the team doesn't think this change will be as detrimental as some think. The current metrics that have been recorded are pretty early, so I believe the team is simply waiting for the data to become more representative of reality before publishing as much as possible to the public, to help everyone better-understand the anticipated impact.
On Friday, August 30, 2019 at 12:32:26 AM UTC+9, rek...@gmail.com wrote:I guess this is the proof we need that Google Chrome is not in the pocket of Google Fonts. I foresee much much much font redownloading in the future. I wonder how many extra MB or GB of space a users cache will be after this change.
I am distressed & saddened the idea of cache is being so heavily regressed for a couple very niche security concerns, that would be better served by some specific content security policy directives. This move feels like an affront to the harmonious web, a shattering & breaking up of a long valued & treasured piece. It breaks the idea of a CDN completely. This is remarkably bold, for so little, such niche tiny wins.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e97c1ff4-8baa-48b1-9468-c67a9b7e4c11%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e97c1ff4-8baa-48b1-9468-c67a9b7e4c11%40chromium.org.
--Kenji BAHEUXProduct Manager - ChromeGoogle Japan
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eb7005e4-55e5-4a1d-b911-31d8a0ee2f8f%40chromium.org.
Thanks for sharing these details Shivani!Once concern I have is that double (or tripple) keying caches may disproportionately hurt smaller sites than big sites if they rely more heavily on 3p resources. If that were the case it might be lost in our metrics since the majority of page loads in Chrome are for the most popular sites. Would it be possible to slice the analysis in the explainer in some way (eg. top-10k origins vs. not) to try to test and quantify this?Thanks,Rick
On Thu, Sep 19, 2019 at 5:16 AM Shivani Sharma <shiva...@chromium.org> wrote:
Here is the explainer for this work.
It goes into the details of the metrics in the section "Impact on metrics" for various categories like network traffic, page performance and cache misses. It also gives the metrics for specific types of resources like 3rd party fonts, css and js files, although at this time the 3rd party resource metrics are fairly new and we will watch how these numbers change over the next few weeks and update them here.
On Thursday, August 29, 2019 at 9:49:20 PM UTC-4, Kenji Baheux wrote:
For reference, this doc, started by Mozilla, captures the discussions around privacy-preserving cross-origin caching that occurred at the last TPAC.
On Fri, Aug 30, 2019 at 12:58 AM Dominic Farolino <d...@chromium.org> wrote:
> I wonder how many extra MB or GB of space a users cache will be after this change.--I guess similar to the average cache size of Safari users, since Chrome isn't the first implementation to explore making this sort of change. Also you'll probably be interested in https://groups.google.com/forum/#!msg/mozilla.dev.platform/eFx-93iBPpU/Hs4jUZRgDgAJ.I know a lot of people have been asking about the current metrics Chrome has collected, and for a deeper explanation as to why the team doesn't think this change will be as detrimental as some think. The current metrics that have been recorded are pretty early, so I believe the team is simply waiting for the data to become more representative of reality before publishing as much as possible to the public, to help everyone better-understand the anticipated impact.
On Friday, August 30, 2019 at 12:32:26 AM UTC+9, rek...@gmail.com wrote:I guess this is the proof we need that Google Chrome is not in the pocket of Google Fonts. I foresee much much much font redownloading in the future. I wonder how many extra MB or GB of space a users cache will be after this change.
I am distressed & saddened the idea of cache is being so heavily regressed for a couple very niche security concerns, that would be better served by some specific content security policy directives. This move feels like an affront to the harmonious web, a shattering & breaking up of a long valued & treasured piece. It breaks the idea of a CDN completely. This is remarkably bold, for so little, such niche tiny wins.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e97c1ff4-8baa-48b1-9468-c67a9b7e4c11%40chromium.org.
--Kenji BAHEUXProduct Manager - ChromeGoogle Japan
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
+1, Thanks for putting that document together Shivani to give the rest of us some insight into to the data you're seeing.The data seems to show an impact on 3rd part cache hits/misses of anywhere between ~4-12%, depending on strategy & content type. That is significant, and I'm really surprised to see that not translate into any statistically significant change to page performance. That seems to imply that caching is not strongly related to page performance, which can't be true... right? Am I missing something obvious? Or, to echo Rick's comment, could the type of site profiled be impacting the data in some unexpected way?
Thanks for sharing these details Shivani!Once concern I have is that double (or tripple) keying caches may disproportionately hurt smaller sites than big sites if they rely more heavily on 3p resources. If that were the case it might be lost in our metrics since the majority of page loads in Chrome are for the most popular sites. Would it be possible to slice the analysis in the explainer in some way (eg. top-10k origins vs. not) to try to test and quantify this?
On Wed, Sep 18, 2019 at 9:14 PM Rick Byers <rby...@chromium.org> wrote:Thanks for sharing these details Shivani!Once concern I have is that double (or tripple) keying caches may disproportionately hurt smaller sites than big sites if they rely more heavily on 3p resources. If that were the case it might be lost in our metrics since the majority of page loads in Chrome are for the most popular sites. Would it be possible to slice the analysis in the explainer in some way (eg. top-10k origins vs. not) to try to test and quantify this?Thanks!I am looking into it if some of the core metrics can be sliced between popular vs other pages.