Googlers hate it! This one weird trick lets websites dodge Chrome 76’s defenses, detect you’re in Incognito mode

Institute For Ethical Hacking Course and Ethical Hacking Training in Pune – India

Extreme Hacking | Sadik Shaikh | Cyber Suraksha Abhiyan

Credits: The Register

A week ago, Google released Chrome 76, which included a change intended to prevent websites from detecting when browser users have activated Incognito mode.

Unfortunately, the web giant’s fix opened another hole elsewhere. It enabled a timing attack that can be used to infer when people are using Incognito mode.

On Sunday, developer Jesse Li described a novel method to detect when Chrome users have activated Incognito mode using Chrome’s FileSystem API: it is possible to benchmark the speed at which files can be written to disk using this software interface.

The technique is similar to one proposed last month by security researcher Vikas Mishra. He found that browser’s Quota Management API, for managing temporary and persistent storage, can be used to infer the presence or absence of Incognito mode.

Incognito mode in Chrome sounds as if it keeps users anonymous online. But it doesn’t. It simply prevents browsing activity from being stored in the History log and it erases local HTTP cookies and site data from memory when the Incognito session ends (rather than writing the data to local storage). Its purpose is to prevent other people using the same browser on the same device from being able to look at an in-browser record of past browsing sessions.

Web publishers with paywalls dislike Incognito mode because it prevents the setting of cookies to limit article consumption among non-paying visitors. To fight such freeloading, some paywalled websites include code that detects whether Chrome users have access to the FileSystem API – it used to be disabled when Incognito mode was active.

To eliminate this inconsistently, Google engineers in March last year proposed a plan to make the FileSystem API available when Incognito mode is active. The change debuted behind a flag in Chrome 74 and was turned on by default in Chrome 76. But Incognito mode can still be detected.

What Li found was that the FileSystem API performs differently when Incognito mode is active. By conducting a series of write speed benchmarks, Li demonstrated that normal write operations are more irregular and take about three to four times longer than write operations when Incognito mode is active. The source codeis available on GitHub.

The technique is slower and less reliable than determining whether the FileSystem API is available – it takes tens of seconds to conduct the measurements and different hardware configurations affecting timing data. But Li contends the issue is difficult to patch because Incognito mode stores data in memory while normal mode stores data to disk.

“The only way to prevent this attack is for both Incognito mode and normal mode to use the same storage medium, so that the API runs at the same speed regardless,” Li wrote.

In Google’s design document, Jochen Eisinger, director of engineering for Chrome, suggested timing attacks could be addressed by keeping only metadata in memory and encrypting files to disk rather than storing both metadata and files in memory when Incognito mode is active.

Google did not respond to a request for comment about whether it intends to explore this alternative approach to prevent timing and storage-based inferences about Incognito mode.

Li however is skeptical that a different strategy would lead to improved privacy. “While it’s resistant to our attacks, it leaves behind metadata: even if the data itself cannot be decrypted, its mere existence provides evidence of incognito usage, and leaks when the user last used incognito mode and the approximate size of the data they wrote to disk,” Li’s post claims.

According to Eisinger, Google intends to deprecate and eventually remove the FileSystem API eventually because it hasn’t been adopted by other browser vendors and appears to be used mainly to detect Incognito mode.