Чимало користувачів переконані, що відкриття вкладки інкогніто або робота в приватному вікні надійно приховує активність у мережі. У стандартній моделі цифрової безпеки закриття приватного вікна дійсно видаляє файли cookie поточної сесії, сховище localStorage та бази даних IndexedDB. Однак комерційні трекінгові мережі та брокери даних розробили значно глибші механізми спостереження, вбудовані у базові мережеві протоколи. Використовуючи особливості системного кешування, аналітичні платформи формують стійкі міжсесійні маркери, відомі як суперкукі.

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

[Веб-браузер користувача]
  │
  ├─ Звичайні файли Cookie    ──> [Видаляються при виході з інкогніто]
  ├─ LocalStorage / IndexedDB ──> [Видаляються при виході з інкогніто]
  │
  ├─ Таблиця станів HSTS      ──> [Зберігається в мережевому профілі]
  └─ База кешу фавіконів      ──> [Спільна для всіх вікон та вкладок]

Принципи роботи суперкукі на базі HSTS

Стандарт HTTP Strict Transport Security (HSTS), описаний у документі IETF 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 лише для піддоменів, що відповідають одиниці. Піддомени, що відповідають нулю, або не отримують заголовок, або взагалі не запитуються через HTTPS.
  2. Фаза зчитування стану: Під час наступних сесій або на інших партнерських ресурсах скрипт надсилає HTTP-запити зображень (http://bitXX...) до всіх 32 піддоменів. Якщо піддомен уже містить запис HSTS, браузер самостійно замінює протокол на https://. Якщо запису немає, запит відправляється у відкритому вигляді через звичайний http://.
  3. Відновлення коду користувача: Сервер аналізує порти отриманих запитів: захищений порт 443 (HTTPS) чи стандартний порт 80 (HTTP). Співвідносячи звернення до порту 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). Завдяки цьому стан, зафіксований на сайті A, не зчитується безпосередньо із сайту B.
  • Тимчасові таблиці HSTS у приватному режимі: Оновлені версії браузерів створюють ізольовану тимчасову таблицю HSTS для приватного вікна, яка знищується після завершення сесії.

Проте ізоляція на рівні браузера не вирішує проблему аналізу мережевих метаданих:

  1. Маскування через CNAME першої сторони: Коли власники сайту делегують піддомен аналітичній компанії через DNS CNAME, скрипт працює під виглядом першої сторони, нівелюючи міжсайтову ізоляцію.
  2. Спільні системні модулі WebView на мобільних пристроях: На Android та iOS сторонні програми часто відображають веб-вміст через системний WebView, де мережевий стек та кеш нерідко є спільними і не мають суворої ізоляції приватного режиму.
  3. Кореляція за мережевими метаданими: Навіть за умов локального розділення кешу трекінгові платформи пов'язують окремі сегменти воєдино за зовнішньою IP-адресою, номером автономної системи провайдера (ASN) та відбитком клієнта TLS.

Нейтралізація профілювання за допомогою RiceGuard

Захисні засоби браузера ізолюють локальні файли, але не можуть приховати мережеві фактори, які використовуються для зв'язування цифрових слідів. Коли аналітичний сервер отримує пакети з різних ізольованих областей, він звіряє зовнішню IP-адресу та маршрутизацію провайдера.

VPNRice забезпечує надійний захист на третьому мережевому рівні (Layer 3) за допомогою архітектури RiceGuard:

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

Практичні поради щодо налаштування пристрою

Для ефективного запобігання відстеженню через протокольний кеш рекомендується:

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