Chrome 76 closed a loophole that allowed sites to detect when the Incognito Mode was being used, but a bypass for it has already been discovered.
The Incognito Mode, or private browsing, allows users to access websites without having unwanted cookies saved on disk and without being tracked by certain websites.
Prior to Chrome 76, the FileSystem API was disabled by default in Incognito Mode, and websites started tracking the API to determine whether the user was browsing normally or not. Now, Chrome makes the FileSystem API available in Incognito Mode as well, thus closing the loophole.
However, this does not resolve the issue where websites can detect whether Incognito Mode is in use, thus delivering a different experience to users.
Developer Jesse Li discovered that, although the FileSystem API is used in Incognito Mode, Chrome stores data written to the API in memory instead of saving it to disk.
“When we choose to use memory, we make some tradeoffs: RAM is temporary storage, making it an attractive medium for incognito. But side effects include smaller space and higher speed than disk,” Li notes.
Thus, websites could determine whether the user browses in Incognito Mode or not by measuring the speed at which data is written to the FileSystem API.
For that, websites would simply need to benchmark the filesystem by repeatedly writing large strings to it and then measuring how long that takes. Thus, the site could then determine when the data is written to memory, since the operation is faster than when writing to disk.
The developer says that 100 iterations of the benchmark show that the writes to disk take up to 3 or 4 times longer than writes to memory. The proof-of-concept code is available on GitHub.
The proposed benchmarking process takes minutes, making it much slower than the operation of determining whether the FileSystem API is in use or not, but can still do its job, especially for long Incognito Mode browsing sessions.
Another limitation of the attack is that its effectiveness depends on the device’s hardware configuration and on whether additional operations are performed in the background. The method might also produce false-positives in certain situations.
“The final limitation is that the attack doesn’t really detect incognito mode – it detects the backing storage of the FileSystem API, which turns out to be a decent proxy for detecting incognito mode,” Li notes.
Although slower and less reliable, this technique could prove more difficult to patch, given the decision to store data in memory instead of on disk. However, Google could simply address the issue by using the same storage medium for both Incognito and Normal mode.
Last year, some Chrome developers apparently determined that such an attack could be possible, and suggested an alternative implementation that would only keep the metadata in memory, but encrypt the files on disk.
“This would address the risk of sites using timing to differentiate between in-memory and disk backed storage, as well as eliminate the difference in available quota and filesystem types (temporary vs. persistent),” a March 2018 document reads.
However, this implementation would still make it possible to identify the use of Incognito Mode by determining whether the metadata exists, the developer notes.
Related: Chrome 76 Patches 43 Vulnerabilities
Related: Google Boosts Chrome Protection Against Deceptive Sites
