Многие пользователи полагают, что открытие вкладки в режиме инкогнито надежно защищает от сетевого наблюдения. В традиционной модели безопасности закрытие приватного окна действительно удаляет стандартные файлы cookie, записи localStorage и базы IndexedDB. Однако коммерческие трекинговые сети и агрегаторы профилей применяют более глубокие методы, эксплуатирующие архитектуру базовых сетевых протоколов. Используя встроенные механизмы кэширования, аналитические платформы формируют устойчивые сквозные идентификаторы — суперкуки.

Двумя наиболее долговечными векторами скрытого отслеживания состояния выступают таблицы HTTP Strict Transport Security (HSTS) и деревья перенаправлений кэша фавиконов. Эти технологии используют функции производительности и безопасности веб-обозревателей для прямой записи цифрового маркера на устройство пользователя без применения классических cookie-файлов.

[Веб-браузер пользователя]
  │
  ├─ Стандартные Cookie       ──> [Очищаются при выходе из инкогнито]
  ├─ Хранилище LocalStorage   ──> [Очищается при выходе из инкогнито]
  │
  ├─ Таблица состояний HSTS   ──> [Сохраняется в сетевом профиле]
  └─ База кэша фавиконов      ──> [Общая для всех окон и вкладок]

Архитектура суперкуки на базе HSTS

Протокол HTTP Strict Transport Security (HSTS), стандартизированный в документе RFC 6797, предписывает браузеру обращаться к указанному домену исключительно по зашифрованному протоколу HTTPS. Когда веб-сервер отправляет заголовок ответа Strict-Transport-Security: max-age=31536000; includeSubDomains, клиент фиксирует локальное правило безопасности. На протяжении следующих 365 дней любая попытка открыть этот хост через незашифрованный HTTP автоматически преобразуется внутри браузера в HTTPS до отправки пакетов в физическую сеть.

Данный механизм создавался для предотвращения атак с понижением протокола, однако он непреднамеренно формирует один бит сохраняемого состояния: хост либо внесен в локальную таблицу HSTS (значение 1), либо отсутствует в ней (значение 0).

Сеть трекинговых серверов (tracker-network.example)
  ├── bit00.tracker-network.example (Флаг HSTS установлен = 1)
  ├── bit01.tracker-network.example (Флаг HSTS сброшен    = 0)
  ├── bit02.tracker-network.example (Флаг HSTS установлен = 1)
  └── ... (от 32 до 64 отдельных поддоменов)

Системы слежения объединяют эти единичные бинарные флаги в полноценное числовое значение:

  1. Фаза записи состояния: При посещении страницы со скриптом аналитики браузер в фоновом режиме выполняет серию скрытых запросов к 32 уникальным поддоменам (bit01–bit32). Для каждого бита расчетного идентификатора (например, 11010010...) сервер отправляет HTTPS-ответ с заголовком HSTS только для поддоменов, соответствующих единице. Поддомены с нулевым битом либо не получают заголовок, либо запрашиваются по обычному протоколу.
  2. Фаза считывания состояния: При повторном визите или переходе на партнерский сайт скрипт отправляет HTTP-запросы изображений (http://bitXX...) ко всем 32 поддоменам. Если для поддомена уже сохранена запись HSTS, браузер сам переключает протокол на https://. Если записи нет, запрос уходит в открытом виде как http://.
  3. Восстановление идентификатора: Серверная сторона фиксирует, на какой порт поступили запросы: на защищенный порт 443 или на порт 80. Сопоставляя порт 443 с единицей, а порт 80 с нулем, трекер восстанавливает точный 32-битный номер пользователя менее чем за 300 миллисекунд.

Поскольку классические меню очистки истории браузера разделяют «Файлы cookie и данные сайтов» и «Сетевые параметры безопасности», таблицы HSTS часто сохраняются даже после удаления временных файлов.

Идентификация через системный кэш фавиконов

Кэширование значков веб-сайтов (фавиконов) создает еще более скрытый вектор отслеживания. Современные браузеры сохраняют фавиконы в отдельной базе данных SQLite (например, таблица Favicons в Chromium) для мгновенного отображения вкладок, закладок и истории без сетевых задержек.

В отличие от стандартного кэша HTTP, подчиняющегося директивам Cache-Control, загрузка фавиконов исторически происходила вне строгой изоляции документа:

[Модуль навигации браузера]
  │
  ├─ Шаг 1: Запрос основного HTML-документа
  │
  ├─ Шаг 2: Обнаружение тега <link rel="icon" href="/node-A.ico">
  │
  ├─ Шаг 3: Обращение к локальной базе SQLite фавиконов
  │     ├── Значок найден: чтение с диска (запрос в сеть не отправляется)
  │     └── Значок отсутствует: отправка HTTP GET на сервер
  │
  └─ Серверный анализ: регистрация входящих запросов для составления бинарного кода

Исследователи на симпозиуме USENIX Security доказали, что аналитический сервис может выстроить адаптивное дерево перенаправлений HTTP 302 через последовательность фавиконов. Если браузер уже сохранил значок на предыдущем шаге, он использует локальную копию и прекращает сетевой обмен. Если значок отсутствует, инициируется сетевой запрос. Анализируя цепочку поступивших пакетов, сервер вычисляет точный бинарный путь пользователя, формируя аппаратный идентификатор.

Ограничения встроенных механизмов защиты браузеров

Разработчики браузеров внедрили ряд полезных защитных мер:

  • Партиционирование состояния (State Partitioning): Современные движки используют двойные ключи разделения кэша (Total Cookie Protection в Firefox и Network State Partitioning в Chromium). Записи привязываются к паре (top_level_site, resource_site). Благодаря этому маркеры, установленные на одном сайте, изолированы от другого.
  • Временные таблицы HSTS в приватном режиме: Новые версии браузеров создают изолированную таблицу HSTS для приватного окна и уничтожают ее при закрытии сессии.

Однако изоляция на уровне браузера не решает проблему корреляции сетевых метаданных:

  1. Маскировка CNAME от первого лица: Когда владельцы сайта делегируют поддомен трекинговому сервису через запись CNAME, скрипт функционирует в рамках доверенного домена, нейтрализуя межсайтовое разделение.
  2. Общие системные модули WebView: На мобильных платформах сторонние приложения отображают контент через системный WebView, который часто использует общий сетевой стек без строгой изоляции приватных профилей.
  3. Связывание профилей через метаданные сети: Даже при разделении кэша серверы аналитики связывают разрозненные сегменты данных воедино через публичный IP-адрес клиента, номер автономной системы провайдера (ASN) и отпечаток TLS.

Нейтрализация профилирования с помощью RiceGuard

Защитные механизмы браузера изолируют локальные файлы, но бессильны перед сетевыми факторами, которые трекеры используют для деанонимизации. Получая запросы из разных изолированных областей, сервер аналитики сопоставляет их по публичному IP-адресу и маршруту провайдера.

VPNRice решает эту задачу на сетевом уровне L3 благодаря протоколу RiceGuard:

[Браузер и приложения на устройстве]
  │
  │ (HSTS-пробы / Опросы поддоменов / Запросы фавиконов)
  ▼
[Виртуальный интерфейс RiceGuard]
  │
  ├─ Криптографический туннель Chacha20-Poly1305 (RFC 8439)
  ├─ Защищенный шлюз DNS с блокировкой утечек (порты 53 / 853)
  │
  ▼
[Кластер выходных серверов VPNRice]
  │
  ├─ Защищенный общий пул публичных IP-адресов
  ├─ Разрыв привязки к ASN домашнего провайдера
  │
  ▼
[Целевые веб-ресурсы и системы трекинга]
  1. Разрыв сетевых маркеров идентичности: RiceGuard направляет весь трафик устройства через защищенные туннели WireGuard. Когда трекер фиксирует запросы к поддоменам HSTS или кэшу фавиконов, источником выступает IP-адрес серверного пула VPNRice. Аналитическая сеть теряет возможность связать кэш с домашним подключением или географической локацией.
  2. Изоляция DNS-запросов: Считывание битов HSTS требует отправки десятков быстрых запросов к поддоменам (bit01–bit32). RiceGuard направляет обработку DNS исключительно на собственные серверы без ведения журналов. Локальные наблюдатели и вышестоящие операторы связи не могут зафиксировать аномальные всплески DNS-трафика.
  3. Ротация точек выхода: Распределение соединений между различными серверными узлами предотвращает накопление долговременных профилей, исключая возможность сшивки разрозненных кэш-записей.

Практические рекомендации по защите профиля

Для комплексного предотвращения слежки через сетевой кэш протоколов рекомендуется:

  • Регулярно очищать базу HSTS: В браузерах на базе Chromium откройте служебную страницу chrome://net-internals/#hsts, укажите подозрительный домен в поле «Delete domain security policies» и подтвердите удаление.
  • Проверять изоляцию сети в Firefox: В конфигурации about:config убедитесь, что параметр privacy.partition.network_state имеет значение true для строгого разделения кэша и соединений по домену документа.
  • Использовать постоянное туннелирование L3: Поддерживайте постоянное активное подключение VPNRice на компьютерах и смартфонах. Шифрование всех исходящих пакетов гарантирует, что артефакты протоколов и кэшированные данные не раскроют реальный сетевой адрес и параметры вашего оборудования.