Приватные окна не просто скрывают историю — они меняют поведение Storage API, и именно на этой разнице сайты и ловят режим инкогнито.
Окна инкогнито и приватного просмотра обещают, что сайт не сможет узнать, что вы уже бывали на нём раньше. Они не обещают, что сайт не сможет понять, что вы находитесь в таком окне прямо сейчас — и вот уже десять лет издатели, рекламные сети и антифрод-инструменты пользуются именно этим пробелом. Поскольку приватное окно вынуждено вести себя иначе «под капотом» — другие лимиты хранилища, другое поведение на диске, — скрипт, зондирующий эти различия, зачастую способен с реальной уверенностью заключить «это приватное окно», не прочитав при этом ни единого cookie.
Ключевые выводы
- Приватный просмотр скрывает историю, а не поведение — такие API хранилища, как
navigator.storage.estimate(), по-прежнему сообщают реальные, измеримые различия между обычной и приватной сессиями. - Самый старый трюк Chromium измерял скорость записи в (ныне устаревший) FileSystem API, который в режиме инкогнито работал в памяти и был примерно в 3–4 раза быстрее реальной записи на диск, используемой в обычном режиме.
- После того как Chrome закрыл эту лазейку в 2019 году, скрипты обнаружения переключились на квоту хранилища, которую Chrome сообщает через
navigator.storage.estimate(), — меньшую и более единообразную в инкогнито, большую и пропорциональную размеру диска в обычном режиме. - С тех пор Chrome начал сообщать фиксированную, «предсказуемую» квоту в каждом режиме — специально для того, чтобы убить эту эвристику; это активное, продолжающееся исправление, а не окончательно решённый вопрос.
- У Firefox и Safari своя история признаков приватного режима — в основном вокруг того, что
localStorageиIndexedDBведут себя иначе (или вовсе отказывают) в приватной сессии. - Проверка отпечатка BrowserInsight на странице fingerprint check показывает сигналы хранилища, canvas и другие, которые ваш браузер раскрывает прямо сейчас — независимо от того, приватное это окно или нет.
Зачем сайтам вообще обнаруживать инкогнито
Два основных мотива — коммерческие, а не враждебные в смысле безопасности. Издатели с лимитированным доступом по подписке — самый известный пример New York Times — используют обнаружение инкогнито, чтобы читатели не могли сбрасывать счётчик бесплатных статей, каждый раз открывая новое приватное окно. Рекламные технологии и антифрод-инструменты используют его как ещё один сигнал: непропорционально большая доля трафика из приватных окон коррелирует с кликфермами рекламного мошенничества и злоупотреблением купонами/промокодами, поэтому пометка такого трафика пополняет более широкую оценку риска — так же, как системы обнаружения ботов объединяют множество слабых сигналов, а не полагаются на один.
Ни один из этих сценариев не требует определять, кто вы, — только то, приватное ли окно, которым вы пользуетесь прямо сейчас. Именно эта более узкая цель отличает технику от фингерпринтинга браузера: она не пытается построить постоянный идентификатор, а лишь отвечает на один вопрос «да/нет» на время загрузки страницы.
Трюк со скоростью записи FileSystem
Самая ранняя надёжная техника обнаружения инкогнито была нацелена на реализацию Chrome для (ныне устаревшего, специфичного только для Chromium) File and Directory Entries API — window.webkitRequestFileSystem и его собратьев. В обычном окне Chrome обеспечивал работу этого API реальными файлами на диске. В инкогнито, чтобы не оставлять никаких следов после закрытия окна, Chrome вместо этого использовал виртуальную файловую систему в памяти.
Память значительно быстрее диска, поэтому скрипт мог записать пакет временных файлов, замерить, сколько заняла запись, и получить чистый сигнал: если запись завершается в три-четыре раза быстрее базового уровня обычного режима, значит файловая система вообще не касалась диска, а значит окно приватное. Никакого запроса разрешения, никакого взаимодействия с пользователем — просто замер времени против API, который на тот момент был доступен по умолчанию.
Chrome закрыл именно эту лазейку в версии 76 (2019 год), переключив реализацию FileSystem в инкогнито на запись тоже на диск, а не в память, что устранило разрыв во времени. Это был прямой ответ на то, что кейс обнаружения пейволлов попал в поле зрения массовой прессы, — закрытие настоящей лазейки, а не косметическая заплатка.
Трюк с квотой StorageManager
Это исправление не положило конец игре в кошки-мышки — оно просто сдвинуло её на один API дальше. Каждый современный браузер предоставляет navigator.storage.estimate() — часть Storage API, — который возвращает промис, разрешающийся в текущее значение usage (использованного объёма) и quota (доступной источнику квоты):
// Illustrative sketch — not the exact detectIncognito heuristic
async function looksLikeIncognito() {
const { quota } = await navigator.storage.estimate();
const ONE_TWENTY_MB = 120 * 1024 * 1024;
// Historically: Chromium capped Incognito quota well below
// the large, disk-proportional value normal windows report.
return quota < ONE_TWENTY_MB;
}
В обычном режиме браузинга Chromium исторически вычислял сообщаемую квоту как долю от реального свободного места на диске — часто это десятки или сотни гигабайт. В инкогнито, поскольку профиль временный и обычно ограничен доступной оперативной памятью, а не диском, квота возвращалась значительно меньшей и сравнительно единообразной на разных машинах. Скрипту достаточно было проверить, упало ли сообщённое число ниже низкого порога (в публичных разборах в качестве отсечки обычно называют около 120 МБ), чтобы сделать уверенный вывод.
Именно эта эвристика — вместе со специфичными для Chromium запасными вариантами и отдельными проверками для Firefox, Safari, Edge и Opera — поддерживается как эталонная реализация с открытым исходным кодом в проекте Joe12387/detectIncognito на GitHub, который служит полезным первоисточником, показывающим, насколько разнообразными и специфичными для конкретного браузера со временем стали эти проверки.
У Firefox и Safari свои особенности
Пробел с квотой хранилища в Chromium привлекает больше всего внимания, потому что доля рынка Chrome делает его самой ценной целью, но у Firefox и Safari в разное время были собственные обнаруживаемые особенности приватного режима:
| Браузер | Исторический признак приватного режима | Первопричина |
|---|---|---|
| Chrome / Chromium | Скорость записи FileSystem (до 2019); квота хранилища (после 2019) | Файловая система в памяти; меньшая RAM-based квота |
| Safari | localStorage.setItem() выбрасывал ошибку превышения квоты | Приватный режим ограничивал квоту Web Storage до 0 байт |
| Firefox | indexedDB был null, либо запросы молча завершались ошибкой | IndexedDB годами была недоступна в приватных окнах |
Версия Safari была, пожалуй, самой грубой: годами вызов localStorage.setItem() внутри приватного окна немедленно выбрасывал исключение, потому что Safari устанавливал квоту хранилища в приватном режиме равной нулю, вместо того чтобы изолировать её. Достаточно было обернуть тестовую запись в один try/catch, чтобы обнаружить этот режим с почти идеальной точностью. Apple исправила это в Safari 11, снова сделав localStorage полностью доступным для записи в приватных окнах — данные просто хранятся в памяти и исчезают по завершении сессии, вместо того чтобы блокироваться полностью.
IndexedDB в Firefox рассказывала похожую историю, только с другой стороны: приватные окна либо вовсе не предоставляли объект indexedDB, либо запросы на открытие завершались ошибкой, которую скрипт мог перехватить так же легко, как исключение хранилища в Safari. С тех пор Firefox продвинулся к поддержке IndexedDB в приватном просмотре с помощью зашифрованного, привязанного к сессии хранилища, закрыв этот конкретный пробел так же, как Chrome закрыл свой пробел с FileSystem, — сделав реализацию приватного режима достаточно похожей на обычную, чтобы сигнал по времени/доступности исчез.
Десятилетие игры в кошки-мышки
Паттерн во всех браузерах одинаков — один и тот же цикл из трёх шагов, только на разных временных отрезках: деталь реализации выдаёт различие приватного режима → это различие превращается в оружие для обнаружения пейволлов или мошенничества → производитель переделывает реализацию приватного режима, чтобы устранить пробел, что обычно открывает где-то ещё меньший и более тонкий пробел. API хранилища продолжают оставаться полем боя, потому что вся суть приватного режима — вести себя иначе с данными, а это то единственное свойство, которое скрипты обнаружения всегда могут попытаться измерить.
Как обстоят дела в 2026 году
Трюк с квотой StorageManager всё ещё работает против текущей стабильной версии Chrome, но его дни, похоже, сочтены. Chrome постепенно внедряет меру смягчения под названием «предсказуемая сообщаемая квота хранилища», которая сообщает искусственную квоту — usage плюс меньшее из двух значений: 10 ГиБ или округлённый размер вашего диска — в любом режиме браузинга для сайтов без повышенных разрешений на хранилище, специально для того, чтобы обычные и инкогнито-окна становились неотличимыми по этому измерению. По состоянию на середину 2026 года это разворачивается для сайтов с ограниченными разрешениями на хранилище; сайты, которым предоставлено неограниченное хранилище или которые упираются в принудительную квоту, явно не затронуты, поэтому эта эвристика исчезла не везде и не сразу.
Практический вывод в том, что ни одна отдельная проверка хранилища не является надёжным детектором инкогнито, а ни одной из этих техник никогда не требовались cookie, canvas или постоянный идентификатор — это более узкая и быстро меняющаяся игра, чем фингерпринтинг, которая ведётся API за API, а не сигнал за сигналом.
Защищает ли инкогнито от фингерпринтинга?
Само по себе — нет, и это более важный момент, как только вопрос обнаружения решён в ту или иную сторону. Приватное окно меняет то, что сохраняется, — историю, cookie, кешированные данные форм, — но не то, что ваш браузер раскрывает на живой странице: тот же хеш canvas, та же строка рендерера WebGL, те же шрифты и характеристики экрана отображаются одинаково, независимо от того, приватное окно или нет. Если вы пользуетесь инкогнито в ожидании анонимности от фингерпринтинга, статья «Цифровой отпечаток браузера: как защитить приватность» объясняет, почему это ожидание не оправдывается и что на самом деле снижает раскрываемость.
Запустите проверку отпечатка BrowserInsight на странице fingerprint check один раз в обычном окне и один раз в приватном — базовые сигналы будут выглядеть почти идентично, и это самый наглядный способ увидеть, что «приватность» и «неотличимость по отпечатку» — две разные гарантии.
Часто задаваемые вопросы
Может ли сайт всегда определить, что я в режиме инкогнито?
Нет. Обнаружение всегда зависело от конкретной особенности реализации в конкретной версии браузера, а такие особенности со временем исправляют. Техника, которая надёжно работала в прошлом году, может незаметно перестать работать после обновления браузера, и наоборот — это нестабильная гонка вооружений, а не устоявшаяся возможность.
Останавливает ли очистка cookie или VPN обнаружение инкогнито?
Нет, потому что эти техники вообще никогда не смотрят на cookie или ваш IP-адрес. Они измеряют, как API хранилища ведут себя в текущей сессии, а это никак не связано с тем, что меняют VPN или очистка cookie.
Законно ли обнаруживать режим инкогнито?
Само по себе обнаружение не является незаконным, но то, что сайт делает с этой информацией, может поднимать отдельные правовые и этические вопросы — особенно когда это используется, чтобы обойти сознательный выбор приватности пользователя ради коммерческой выгоды, например, чтобы принудительно сбрасывать пейволл. Регулирование различается в зависимости от юрисдикции, и это не юридическая консультация.
Почему Chrome потребовались годы, чтобы полностью это исправить?
Потому что каждое исправление закрывало лишь одну конкретную лазейку, а фундаментальное ограничение — хранилище приватной сессии где-то обязано вести себя иначе, чем у обычной, — раз за разом открывало новые, более узкие пробелы. Исправление FileSystem в 2019 году никак не затронуло пробел с квотой StorageManager, а текущая мера смягчения квоты сама всё ещё разворачивается с исключениями, что хорошо иллюстрирует, насколько трудно полностью достичь «неотличимости по замыслу».
Заключение
Обнаружение инкогнито — более узкий и быстрее меняющийся родственник фингерпринтинга браузера: вместо того чтобы строить постоянный идентификатор из десятков сигналов, оно задаёт один вопрос — ведёт ли себя хранилище как приватная сессия? — используя тот API, который на данный момент способен на него ответить. Каждое исправление закрывает реальный пробел, а каждый новый пробел находят снова, и именно поэтому понимание механизма важнее, чем слепое доверие любому конкретному заявлению «инкогнито невозможно обнаружить».
Рекомендуем почитать:


