Chrome changes how its cache system works to improve privacy

Google has changed how a core component of the Chrome browser works in order to add additional privacy protections for its users.

Known as the HTTP Cache or the Shared Cache, this Chrome component works by saving copies of resources loaded on a web page, such as images, CSS files, and JavaScript files.

The idea is that when a user revisits the same site or visits another website where the same files are used, Chrome will load them from its internal cache, rather than waste time re-downloading each file all over again.

This component has been present not only inside Chrome but inside all web browsers since the early days of the internet, where it served as a bandwidth-saving feature.

In all browsers, the cache system usually works in the same way. Each image, CSS, or JS file saved in the cache receive a storage key that is usually the resource’s URL.

For example, the storage key for an image would be the image URL itself: https://x.example/doge.png.

When the browser loads a new page, it would search for the key (URL) inside its internal cache database and see if it needed to download the image or load it from the cache.

The old HTTP Cache system was open to abuse

Unfortunately, across the years, web advertising and analytics firms realized that this very same feature could also be abused to track users.

“This mechanism has been working well from a performance perspective for a long time,” said Eiji Kitamura, Developer Advocate at Google.

“However, the time a website takes to respond to HTTP requests can reveal that the browser has accessed the same resource in the past, which opens the browser to security and privacy attacks.”

These include the likes of:

• Detect if a user has visited a specific site: An adversary can detect a user’s browsing history by checking if the cache has a resource that might be specific to a particular site or cohort of sites.
• Cross-site search attack: An adversary can detect if an arbitrary string is in the user’s search results by checking whether a ‘no search results’ image used by a particular website is in the browser’s cache.
• Cross-site tracking: The cache can be used to store cookie-like identifiers as a cross-site tracking mechanism.

Cache partitioning activated in Chrome 86

But with Chrome 86, released earlier this week, Google has rolled out important changes to this mechanism.

Known as “cache partitioning,” this feature works by changing how resources are saved in the HTTP cache based on two additional factors. From now on, a resource’s storage key will contain three items, instead of one:

• The top-level site domain (http://a.example)
• The resource’s current frame (http://c.example)
• The resource’s URL (https://x.example/doge.png)

By adding additional keys to the cache pre-load checking process, Chrome has effectively blocked all the past attacks against its cache mechanism, as most website components will only have access to their own resources and won’t be able to check resources they have not created themselves.

There are, however, some scenarios where the cache might intersect, but the attack surface is far smaller than before. (See here for all the edge cases)

Coming to other browsers

Google has been testing cache partitioning since Chrome 77, released in September 2019, and said the new system wouldn’t have any impact on users or developers.

The only ones who will see a change are website owners who are most likely to observe an increase in network traffic by around 4%.

Cache partitioning is currently active only in Chrome but is also available to other browsers based on the Chromium open-source code, all of which are most likely to deploy it as well in the upcoming months. This includes the likes of Edge, Brave, Opera, Vivaldi, and others.

Mozilla has also announced similar plans to implement Chrome’s cache partitioning mechanism, but there’s no deadline when this will land in Firefox just yet.

Apple, the other major browser vendor, has been using a limited cache partitioning system 2013. However, Safari’s cache partitioning system only uses two checks (#1 and #3), instead of Chrome’s more thorough three checks.

“Cache partitioning is a good practice that most of the browsers created by major companies should be utilizing,” John Jackson, an Application Security Engineer at Shutterstock, told ZDNet today.

“It’s been repeatedly proven over the years that side-channel attacks occur as a result of a unified cache. Side-channel attacks have resulted in attackers acquiring tokens, email addresses, credit card numbers, phone numbers, browsing history, etc.

“It’s good to see that Google is getting the ball rolling on a security practice that should have already been implemented,” Jackson added.

READ MORE HERE