In Chrome 76, a vulnerability was patched addressed a loophole in the implementation of the FileSystem API, which allowed web applications to detect the use of incognito mode. Starting with Chrome 76, instead of blocking access to the FileSystem API, which was used as an indicator of incognito mode activity, the browser has ceased to restrict the FileSystem API but cleansed any changes made after a session. It turned out that the new implementation flaws that, as before, allow detecting incognito mode activity.
The essence of the problem is that a session using the FileSystem API in incognito mode is temporary, and data is not saved to disk but kept in RAM. Accordingly, the time it takes to save data via the FileSystem API and the resulting deviations (while saving in RAM, constant characteristics are recorded, whereas when writing to disk, delays vary) allows for a fairly confident judgment on whether a page is being viewed in incognito mode or not. The drawback of this method is the quite lengthy process of measuring deviations, which can take about a minute ().
At the same time, another issue remains unresolved in Chrome 76, which allows judging incognito mode activity based on the assessment of imposed limitations through the API . The limits set for the temporary storage used in incognito mode differ from those when full storage is used on disk.
Recall that websites interested in detecting incognito mode are those operating on a subscription-based model (paywall). To attract new audiences, such sites provide new users with full access for a limited time, which is actively exploited to bypass the paywall. The simplest way to access paid content in such systems is to use incognito mode, during which the site believes the user has opened the page for the first time. Publishers are unhappy with this behavior, so they have actively used the loophole related to the FileSystem API to require users to disable incognito mode to continue viewing.
Source: opennet.ru
