Chrome 76 had a loophole in the implementation of the FileSystem API that allows you to determine from a web application the use of incognito mode. Starting with Chrome 76, instead of blocking access to the FileSystem API, which was used as a sign of Incognito mode activity, the browser no longer restricts the FileSystem API, but cleans up changes made after the session. As it turns out, the new implementation disadvantages that make it possible to determine the activity of incognito mode as before.
The essence of the problem is that the session with the FileSystem API in incognito mode is temporary, and the data is not saved to disk and is kept in RAM. Respectively, the time of saving data via the FileSystem API and the deviations that arise (when saving in RAM, constant characteristics are recorded, while when writing to disk, the delays change) you can confidently judge whether the page is being viewed in incognito mode or not. The disadvantage of this method is the rather lengthy process of measuring deviations, which can last about a minute ().
At the same time, one more thing remains unfixed in Chrome 76 , which allows you to judge the activity of incognito mode based on an assessment of the restrictions set via the API . For temporary storage used in incognito mode, different limits are set than for full storage on disk.
Let us remind you that sites operating on the model of providing full access via a paid subscription (paywall) are interested in defining incognito mode. To attract a new audience, such sites provide new users with demo full access for some time, which is actively used to bypass paywalls. The easiest way to access paid content in such systems is to use incognito mode, in which the site believes that the user has opened the page for the first time. Publishers are not happy with this behavior, so they actively used a loophole associated with the FileSystem API to impose a requirement to disable incognito mode to continue browsing.
Source: opennet.ru