Chrome Incognito mode detection fix busted by researchers

Remember that Chrome update that stopped websites from detecting Incognito mode? Well, researchers claim to have found a way around it.

Chrome’s Incognito mode is supposed to let people use computers for browsing sessions without affecting that computer’s history or polluting the browser with session cookies. That means you can search for something on a computer without it showing up there, which is useful for everyone from victims of domestic abuse through to people searching for gifts.

People also discovered another use for incognito mode, though: getting past paywall sites. Incognito mode’s cookie blocking enabled people to start a fresh session with each visit. Visitors to metered paywall sites that provide a certain number of stories for free before demanding a subscription could effectively reset the meter each time they accessed the site.

Sites got wise to this and figured out a way to spot Chrome browsers in Incognito mode. In regular browsing sessions, Chrome uses the chrome.fileSystem API to read and write to the local filesystem. Google disabled that API in Incognito Mode because it never reads or writes cookies during those sessions.

Sites realised that they could check the existence of chrome.fileSystem in visiting Chrome browsers. If they asked for it and got an error message, they knew that the user was browsing in incognito mode and could respond with a message like this:

When Google launched Chrome 76, it stopped sites from using this technique by introducing a new kind of reader/writer for file streams. This wrote cookies to browser memory rather than to the local file system, where they would persist. This still looked like chrome.fileSystem to the querying website, meaning that the site wouldn’t get the missing API error message when looking for that API, and so couldn’t determine whether the visiting browser was in Incognito Mode.

Or, so Google thought – until now.

Security researcher Vikas Mishra noticed a loophole in the temporary storage that Chrome uses to hold website resources. He found that the temporary storage will allow a fraction of the device’s overall available storage for non-Incognito windows, but only allows 10% of the device’s memory for windows running in Incognito Mode, and caps it at 120Mb.

Sites viewed in non-Incognito Mode on most modern devices will quickly exceed 120Mb of temporary storage. Therefore, he inferred that any window with a 120Mb storage limit must be in Incognito Mode. He also helpfully provided a script that websites could implement.

Another researcher, Jesse Li, used a timing attack to detect Incognito Mode. He based it on the difference in speed of writing to memory rather than disk. He benchmarked write speeds by repeatedly writing large strings to the browser in both modes. The difference between the two benchmarks is large enough that he can tell which kind of storage system he’s writing to.

The problem is that the benchmark, which must be run each time a browser visits, takes “on the order of minutes or tens of seconds” to get enough data. Background processes may introduce noise that muddies the benchmarks, and if you’re using a system where the disk is memory (such as an OS run on a USB key), then it won’t work.

These are interesting exercises, but the first is easy to fix by adjusting a threshold, while the second is difficult to implement in practice. The real question here is how we got to a point where browser vendors and popular online publishers find themselves in an arms race to break browser-based privacy – and that involves a far longer discussion of the business models underpinning the web.

Surely there has to be a better model that works for everyone?