In Chrome 76 was a loophole in the implementation of the FileSystem API, allowing web applications to detect the use of incognito mode. Starting from Chrome 76, instead of blocking access to the FileSystem API, which was used as an indicator of incognito activity, the browser no longer restricted the FileSystem API but cleared the changes made after the session. As it turned out, the new implementation flaws that still allow determining incognito mode activity.
The essence of the problem is that a session with the FileSystem API in incognito mode is temporary, and data is not stored on disk but remains in RAM. Accordingly, the time it takes to save data via the FileSystem API and the resulting deviations (when saving in RAM, constant characteristics are recorded, while when writing to disk, the delays change) allows for a quite confident judgment of whether the page is being viewed in incognito mode or not. The drawback of the method is the rather lengthy process of measuring deviations, which can take about a minute ().
At the same time, in Chrome 76, another issue remains unresolved , allowing the determination of incognito mode activity based on the evaluation of limitations set through the API . The limits set for the temporary storage used in incognito mode are different than those for full disk storage.
It is worth noting that websites interested in detecting incognito mode are those operating under a paywall model. To attract new audiences, such sites provide new users with temporary full access, which is actively used to bypass paywalls. The simplest way to gain access to paid content in these systems is to use incognito mode, where the site assumes the user has opened the page for the first time. Publishers are not satisfied with this behavior, so they have actively exploited the loophole associated with the FileSystem API to enforce turning off incognito mode for continued viewing.
Bron: opennet.ru
