[ad_1]
When browsing the web with Google Chrome, some sites use a method to determine whether a visitor is in a normal browser session or in incognito mode. To the extent that this can be considered a breach of confidentiality, Google will change the operation of a particular API so that websites can no longer use this technique.
Chrome supports the FileSystem API, which allows sites to create a virtual file system residing in the browser's sandbox. This allows sites that use large resources, such as online games, to download these resources to a virtual file system, without having to download them whenever necessary.
Currently, the FileSystem API is not available in private browsing sessions because it leaves files behind and can be considered a risk to privacy.
This allows sites to check if a user is in incognito mode, simply trying to use the FileSystem API. If they can, the visitor is in a normal browsing session, otherwise he is in private browsing mode.
In a Chrome Gerrit article launched this week and updated earlier in the morning, Google announced that it was modifying the FileSystem API so that it could be used in private browsing mode without risk for confidentiality.
A design document explains that if a user is in a normal browsing session, he will continue to use physical storage for the virtual file system, but when using the incognito mode, he will instead use storage in memory. This will allow the file system to be erased when closing the private browsing session and leave no trace on the hard drives.
The proposed solution is to keep the metadata and the actual files in memory:
-
Use the level-db backend in memory to store file metadata
-
Divide ObfuscatedFileUtil into a class that interacts with the metadata (SandboxPrioritizedOriginDatabase) and a delegate that touches the file system.
-
Implement an alternate delegate that keeps the data in memory instead of storing it on disk.
-
Implementing 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, senior computer engineer at Google, who hopes to get it ready for Chrome 74.
According to the design document, performance and speed of use of memory storage in private browsing mode are problematic. When visiting sites using the FileSystem API, the Chrome incognito mode uses more memory to store the virtual file system.
Speed
If a site is actually using the FileSystem API (and not only trying to detect incognito mode), it will use memory in the browser process.
security
Since the data is stored in memory in the browser process, a malicious website might try to drain the memory of the browser process and make it more likely to crash. However, the website must indicate the size of the file system requested, so that we can protect ourselves against this by rejecting requests that are too large.
The other concern is that an abusive site could crash the browser process using all available memory. To solve this problem, Google will ask the site to indicate in advance how much memory is needed.
This feature should soon be available in Chrome Canary and will be enabled via the "enable-filesystem in incognito" flag of the chrome: // flags screen.
[ad_2]
Source link