FROST: як звичайний сайт може використати SSD як побічний канал для відстеження активності

Розбір FROST — дослідницької атаки через OPFS і SSD timing у браузері. Пояснюємо, що саме показали автори, звідки взялися 88.95%, чому це не “читання файлів з SSD”, які ризики для приватності і що можуть зробити браузери, продукти та користувачі.

08 черв. 2026 р.· 11 хв читання· Технології

Поговорити з PAS7 Studio про privacy-first web

Кому підійдеCTO та tech leadsFrontend і full-stack інженериProduct owners, які пишуть privacy claimsSecurity engineersЗасновники SaaS і вебпродуктівКористувачі, яким важлива приватність у браузері

Темна технічна сцена з ноутбуком, NVMe SSD і хвилями timing traces як ілюстрація FROST side-channel атаки

Поділитися

Коротко

Що сталося і чому це важливо

FROST звучить як новина в стилі “SSD шпигує за вами”. Реальність технічніша і цікавіша: SSD нічого сам не “відправляє”, але браузер може створити вимірюваний I/O-шум, а machine learning — витягнути з нього pattern.

Це атака на приватність, а не класичний “злам диска”.

Вона не читає ваші файли з SSD і не дає сайту прямий доступ до файлової системи.

Вона показує, що hardware-level побічні канали можна підняти до рівня звичайного web API.

Найбільш корисний висновок для продуктів: privacy design не можна зводити до cookie banner і incognito mode.

Як працює FROST: OPFS, SSD contention і timing trace

Найпростіша модель: атакувальний сайт не питає “який сайт відкритий?”, а постійно ставить SSD маленькі питання “наскільки швидко ти зараз відповідаєш?”.

OPFS дає браузеру файл, який реально живе на диску

Origin Private File System — це приватне сховище для конкретного origin. Воно не дає сайту читати довільні локальні файли, але дозволяє створювати й керувати файлами всередині sandboxed storage. Для FROST цього достатньо, бо потрібен не доступ до чужих файлів, а контрольовані I/O операції. [1][2][3]

SSD contention створює вимірюваний сигнал

Якщо інший сайт або застосунок паралельно створює disk activity, час доступу до OPFS-файлу може змінюватися. FROST збирає такі зміни як trace. Один trace не “розповідає історію”, але в масиві даних з’являється pattern. [1]

Класифікатор робить prediction, а не абсолютне знання

У website fingerprinting атаках модель навчається на відомих сайтах, а потім порівнює новий trace з тренувальними прикладами. Тому closed-world результати завжди треба читати як “серед заданого набору кандидатів”, а не “з усього інтернету”. [1]

Браузерна продуктивність має security cost

OPFS створювався для серйозних вебзастосунків: редактори, IDE, великі локальні datasets, offline-first apps. Проблема не в тому, що API “поганий”, а в тому, що продуктивні low-level можливості часто стають новими sensors. [2][3][4]

FROST перетворює доступ до OPFS-файлу на sensor: сайт створює I/O навантаження, міряє latency, збирає trace і класифікує активність за попередньо навченими профілями.

Звідки взялися 88.95% і що вони означають

У медіа цифра 89% легко перетворюється на страх. Для технічної оцінки важливо дивитися на метрику, сценарій і обмеження експерименту.

Closed-world означає, що модель вибирає з відомого набору класів. Якщо тест складається з top-50 сайтів, prediction питає приблизно: “на який із цих 50 профілів це найбільше схоже?”. У відкритому інтернеті кількість кандидатів, фонова активність, тип SSD, ОС, браузер, extensions, power mode і user behavior додають шум.

Це не применшує результат. Навпаки, сильна частина FROST у тому, що атака піднімає SSD side-channel у браузер без встановлення native malware. Але для чесної статті треба не продавати panic headline, а пояснювати threat model.

88.95%

F1 score для top-50 closed-world website fingerprinting на macOS з OPFS-based contention measurement. [1]

86.95%

Macro-averaged F1 score в open-world top-50 сценарії; paper також вказує open-world accuracy 96.72%. [1]

95.83%

F1 score для closed-world application fingerprinting експерименту на macOS через OPFS. [1]

Чим FROST не є

Правильне розуміння загрози допомагає не зробити дві помилки: недооцінити research або, навпаки, описати його як фантастичний spyware.

Це не читання файлів з вашого SSD. OPFS залишається origin-scoped і не відкриває сайту довільні локальні документи. [2][3]

Це не доказ, що будь-який сайт завтра на 89% побачить усю історію браузера. Результат прив’язаний до експериментального сетапу й класів, на яких модель навчалась. [1]

Це не проблема лише одного браузера. Paper згадує OPFS support у major browsers і обговорює Chrome, Firefox та Safari, але конкретні можливості й ліміти storage різняться. [1]

Це не причина вимикати весь modern web. OPFS потрібен легітимним застосункам; питання в mitigation, quota behavior, timing resolution, isolation і telemetry для abnormal storage usage. [1][4]

Чому cookie blocker або incognito не закривають такий клас атак

Cookie blocker працює проти storage-based tracking, де сайт прямо зберігає або читає ідентифікатор. Incognito зменшує persistence між сесіями. FROST належить до іншого класу: сайт вимірює поведінку апаратного ресурсу під час поточної сесії.

Це схоже на різницю між “хтось записав ваш номер у блокнот” і “хтось слухає шум за стіною, щоб здогадатися, що відбувається”. У другому випадку видалення блокнота не прибирає сам sensor.

Тому privacy engineering для сучасного web має включати не тільки consent/storage policy, а й side-channel thinking: таймери, shared resources, storage pressure, cache behavior, rendering pipeline, GPU/CPU/SSD contention, cross-origin isolation.

Що можуть зробити браузери, продукти й користувачі

Для звичайного користувача FROST поки що research-grade загроза, а не масовий exploit kit. Але для браузерних платформ і продуктів із privacy claims це вже практичний сигнал.

Для браузерів

Paper обговорює варіанти mitigation: відстеження незвично великих OPFS writes across origins, сповіщення користувачів, обмеження OPFS як low-level I/O sensor, зменшення точності timing signals і сильніші permission/visibility моделі для high-impact storage behavior. Автори також вказують, що найсильніші mitigation можуть ламати легітимні workflows. [1]

Для вебпродуктів

Якщо ви будуєте SaaS, фінансовий кабінет, health portal або internal tools, не обіцяйте “повну приватність” лише тому, що у вас немає third-party cookies. Privacy claims мають враховувати browser platform leakage, third-party scripts, analytics, embedded content і side-channel surface.

Для користувачів

Тримайте браузер і ОС оновленими, не відкривайте випадкові high-risk сайти поруч із чутливими сесіями, використовуйте окремі browser profiles для банкінгу/адмінок/роботи, обмежуйте extensions і third-party scripts. Це не “фікс FROST”, але зменшує загальну площу browser privacy attacks.

Для security teams

Додайте side-channel ризики до threat modeling для вебзастосунків, які активно використовують storage APIs, WASM, high-frequency timers, workers, canvas/GPU або локальну обробку великих даних. Це особливо актуально для браузерних IDE, редакторів і offline-first продуктів.

Захист від side-channel атак рідко має одну кнопку. Частина роботи лежить на browser vendors, частина — на product/security командах, частина — на дисципліні користувача.

Практичні уроки для команд, які будують вебпродукти

Навіть якщо FROST ніколи не стане масовою атакою в такому вигляді, він добре показує, куди рухається risk surface сучасного web.

Не зводьте приватність до cookie banner

Browser fingerprinting і side channels можуть працювати без традиційних tracking identifiers. Ваша privacy позиція має говорити про data minimization, third-party dependencies, telemetry і client-side behavior.

Перевіряйте storage-heavy features окремо

Якщо продукт використовує OPFS, IndexedDB, local caches або великі offline datasets, додайте security review саме для storage behavior: quota, cleanup, partitioning, observability і user controls.

Ставте межі для third-party JavaScript

Кожен analytics/tag/chat/widget script отримує можливість виконувати код у browser context. Навіть якщо він не має доступу до ваших backend secrets, він впливає на privacy surface користувача.

Будуйте threat models на рівні платформи

Сучасний браузер — це ОС усередині ОС. CPU, GPU, storage, timers, workers, codecs, fonts і rendering можуть ставати датчиками. Threat model має це визнавати.

Пишіть чесні UX-повідомлення

Коли продукт каже “ми не відстежуємо вас”, користувач чує абсолют. Краще конкретизувати: які дані не збираються, які scripts є, як працює local storage, як видалити дані і які межі контролю.

Як ми б враховували це у web/security роботі

У landing pages і content-heavy сайтах ми за замовчуванням тримаємо код static-first: менше client runtime, менше сторонніх scripts, менше непотрібного local storage. Це не робить сайт “невразливим до side channels”, але прибирає багато зайвих точок, які часто з’являються без бізнес-причини.

Для SaaS і внутрішніх кабінетів підхід інший: потрібен окремий security review storage APIs, auth flows, analytics, session handling, embedded widgets і permissions. Особливо якщо продукт працює з фінансовими, медичними, юридичними або корпоративними даними.

Потрібен privacy/security review вебпродукту?

PAS7 Studio може пройтися по вашому frontend/runtime surface: third-party scripts, storage APIs, auth/session flows, analytics, CSP, headers, logs і privacy claims. Результат — не абстрактний аудит, а список конкретних змін для продукту.

Запланувати security review

Часті запитання

Чи може FROST прочитати мої файли з SSD?

Ні. FROST не дає сайту прямий доступ до довільних локальних файлів. Атака використовує OPFS для власного origin-scoped файлу і вимірює timing/latency, щоб робити fingerprinting активності. [1][3]

Чи означає 88.95%, що сайт бачить майже всі мої вкладки?

Ні. 88.95% — це F1 score у top-50 closed-world website fingerprinting експерименті на macOS. У реальному світі результат залежить від набору сайтів, фонової активності, ОС, SSD, браузера і шуму. [1]

Чи рятує режим інкогніто від FROST?

Інкогніто зменшує persistence cookies/storage між сесіями, але не є універсальним захистом від side-channel вимірювань у поточній сесії. Для такого класу атак потрібні browser-level mitigations і зменшення exposure до недовіреного JavaScript.

Чи це вже масова атака?

Публічно FROST описано як дослідницьку роботу. Вона важлива не тому, що кожен сайт уже так стежить, а тому, що показує практичний шлях від web API до hardware side-channel без native malware. [1]

Що робити власникам сайтів і SaaS?

Мінімізувати third-party scripts, тримати frontend static-first там, де це можливо, ревʼювати storage-heavy features, писати чесні privacy claims і додавати side-channel thinking у threat modeling продукту.

Джерела і що саме з них використано

Основні твердження про FROST у цій статті взяті з primary source — paper авторів. Документація OPFS використана для пояснення API, а не для оцінки результатів атаки.

Перевірено: 08 черв. 2026 р.Актуально для: Браузерна приватністьАктуально для: Вебзастосунки з OPFSАктуально для: SaaS і customer portalsАктуально для: Продукти з privacy claimsАктуально для: Security review вебплатформПеревірено з: FROST paper, DIMVA 2026Перевірено з: MDN Origin Private File System documentationПеревірено з: Chrome OPFS documentationПеревірено з: W3C File System specification