В Chrome 76 была лазейка в реализации FileSystem API, позволяющая определить из web-приложения применение режима инкогнито. Начиная с Chrome 76 вместо блокировки доступа к FileSystem API, которая использовалась как признак активности режима инкогнито, браузер перестал ограничивать FileSystem API, но очищал вносимые изменения после сеанса. Как оказалось, новая реализация недостатки, позволяющие как и раньше определять активность режима инкогнито.
Суть проблемы в том, что сеанс с FileSystem API в режиме инкогнито является временным, а данные не сохраняются на диск и держатся в оперативной памяти. Соответственно, время сохранения данных через FileSystem API и возникающие отклонения (при сохранении в ОЗУ фиксируются постоянные характеристики, в то время как при записи на диск задержки меняются) можно достаточно уверенно судить просматривается страница в режиме инкогнито или нет. Недостатком метода является достаточно длительный процесс измерения отклонений, который может продолжаться около минуты ().
При этом в Chrome 76 остаётся неисправлена ещё одна , позволяющая судить об активности режима инкогнито на основании оценки устанавливаемых ограничений через API . Для применяемого в режиме инкогнито временного хранилища устанавливаются иные лимиты, чем при полноценном хранении на диске.
Напомним, что в определении режима инкогнито заинтересованы сайты, работающие по модели предоставления полного доступа по платной подписке (paywall). Для привлечения новой аудитории подобные сайты предоставляют новым пользователями на какое-то время демонстрационный полный доступ, чем активно используются для обхода paywall. Самым простым способом получить доступ к платному контенту в таких системах является использование режима инкогнито, при котором сайт считает, что пользователь открыл страницу первый раз. Издателей такое поведение не устраивает, поэтому они активно использовали связанную с FileSystem API лазейку для вывода требования отключить режим инкогнито для продолжения просмотра.
මූලාශ්රය: opennet.ru