Google is testing larger cache sizes in Chrome to reduce cache partioning impact
Google introduced support for partitioning the cache of the company's Chrome web browser when it launched Chrome 86 earlier this year. The feature changes how web browsers cache content. Previously, web browsers like Chrome used a single cache to store content. One benefit of this approach is that all sites may make use of a cached resource, say a web font or image to speed up the loading of a page or application.
Use of a single cache opened up the door for attacks as sites could check for the existence of cached entries for use in tracking and other attacks.
A partitioned cache renders these attacks useless as sites are no longer able to probe the cache for existing resources. Sites use their own cache that is unique to them.
Downside to using a cache for each site is that performance may take a hit. Since resources cannot be shared anymore across sites, it is necessary to download these for each site that is accessed in the browser, even if the file is identical.
Google believes that the privacy gains are worth the performance impact, and other browser makers seem to agree, as Mozilla plans to launch network partitioning, the organizations name for the feature, in Firefox 85 in January 2021.
Chrome engineers want to test if increasing the cache size of the browser will reduce the impact the new partitioning feature has on the performance of the web browser. Bleepingcomputer was the first to spot the new commit, but it is unclear if the test is already underway or if Google plans to run it in the future.
The commit enables experimentation with different cache sizes in the browser to see if it improves the performance.
This CL adds the code to enable experimentation of different cache sizes. Now that cache will be partitioned, it makes sense to see if increasing the cache size helps offset some performance impact by lowering the eviction rate.
Other information is not available, including the cache size settings that google plans to experiment with, and whether it is possible to block the experiment or manage it from Chrome directly.
Cross-site tracking is bad, but what about one site tracking ? Google and the other privacy rapists have in this context adapted their message to suggest this part is not even privacy invading at all. We hear some sites bragging that they’re big enough that they’re fine with building a profile of us only on their own web property if they can’t do more any more for legal or other reasons. I’ll go on blocking all the tracking identifiers I can find when I can, partitioning is not enough. A likely inexhaustive enumeration of those, beyond HTTP cache discussed here:
https://github.com/privacycg/storage-partitioning#user-content-user-agent-state
Out of curiosity, why does this cache partitioning strictly require extra and duplicate storage space? Could browsers not just obfuscate any cache checks? For example random delays, or randomly loading resources from the network anyway? This strict splitting into different cache sections appears to be the easiest and most secure, but is also wasteful. In my experience, Chrome’s disk cache performance is already somewhat questionable on classic HDDs.
I think one of the main issues are checks for unique files, e.g. files that are only used by a certain site.
*partitioning (in the title)
also people in countries with a little bit less developed infrastructure might get somewhat annoyed by downloading bootstrap and jquery every third site the visit, again and again and …
we don’t event have httt/2 hosting where I live so cdns are best what we can do to speed up our sites
oh well..