When browsing the web with Google Chrome, some sites are using a method to determine if a visitor is in a regular browsing session or in incognito mode. As this can be considered a breach in privacy, Google will be changing how a particular API works so that web sites can no longer utilize this technique.

Chrome supports the FileSystem API, which allows sites to create a virtual file system that lives within the sandbox of the browser. This allows sites that utilize large assets, such as online games, to download these assets to a virtual file system so that they do not have to download them each time they are needed.

Currently the FileSystem API is not available in incognito sessions, because it leaves files behind and could be considered a privacy risk.

This allows sites to check if a user is incognito mode, by simply attempting to use the FileSystem API. If they are to able to, then the visitor is in a regular browsing session, otherwise they are in incognito mode.

In a Chrome Gerrit post started this week and updated earlier this morning, Google has stated that they are changing the FileSystem API so that it can be used in incognito mode, without the risks to privacy.

A design document explains that if a user is in a regular browsing session they will continue to use physical storage for the virtual file system, but when using incognito mode they will use in-memory storage instead. This will allow the file system to be cleared when the incognito session is closed and leave no traces on the hard disks.

The proposed solution is to keep both the metadata and the actual files in memory: Use the in-memory leveldb backend to store file metadata

Split ObfuscatedFileUtil into a class that interacts with the metadata (SandboxPrioritizedOriginDatabase) and a delegate that touches the filesystem.

Implement an alternative delegate that keeps the data in memory instead of storing it on disk.

Implement a version of SandboxFileStream{Reader,Writer} that interacts with the new delegate of ObfuscatedFileUtil instead of reading and writing from the user’s profile directory

This project is being implemented by Ramin Halavati, a senior software engineer at Google, who hopes to have it ready for Chrome 74.

According to the design document, there are some concerns related to performance and speed when using in-memory storage in incognito. When visiting sites that utilize the FileSystem API, Chrome incognito mode will utilize more memory to store the virtual file system.

Speed If a site actually uses the FileSystem API (and doesn’t just try to detect incognito mode), it’ll consume memory in the browser process. Security Since the data is kept in memory in the browser process, a malicious website could try to exhaust the memory of the browser process and make it more likely to crash. The website, however, has to announce how large the requested filesystem should be, so we can protect against this by rejecting overly large requests.

The other concern is that an abusive site could crash the browser process by attempt to utilize all of the available memory. To fix this, Google will require the site to state in advance how much memory would be required.

This feature should be landing in Chrome Canary soon and will be enabled through the "enable-filesystem-in-incognito" flag on the chrome://flags screen.