Canvas і WebGL: чому «додати шум» часто недостатньо

Canvas і WebGL часто подають як просту кнопку в антидетект-браузері: увімкнув шум, отримав новий відбиток і пішов працювати. Насправді все складніше. Сайти використовують відбитки Canvas і WebGL тому, що вони відображають не лише особливості браузера, а й увесь процес формування зображення системою: від відеокарти й драйверів до ОС, шрифтів і параметрів рендерингу. Саме ця комбінація дає змогу відрізняти пристрої один від одного та перевіряти, чи виглядає середовище справжнім. Водночас варто розуміти, що згенероване зображення може на 100% збігатися з тим, яке дає відеокарта зі схожої серії. Наприклад, Nvidia GeForce RTX 4060 може давати той самий результат, що й Nvidia GeForce RTX 5080. Серії різні, але конкретний результат рендерингу може збігатися. Також варто сказати, що дві відеокарти з однаковою назвою можуть генерувати трохи різні зображення.

Дослідники писали про це ще в роботі Pixel Perfect: Fingerprinting Canvas in HTML5: один і той самий тест Canvas/WebGL дає стабільний результат на тій самій зв’язці браузера, ОС і графічного стека. Tor Browser у своїй документації теж називає Canvas одним із помітних ризиків для fingerprinting і пояснює, що хеш намальованого зображення може працювати майже як трекінг-cookie, якщо його нічим не обмежувати: The Design and Implementation of the Tor Browser.

Головна думка така: проблема не в самому факті «у мене є фіксований або навіть унікальний Canvas». Проблема починається тоді, коли відбиток виглядає неприродно, змінюється хаотично або конфліктує з іншими параметрами профілю. Тобто не відповідає такому самому Canvas, який мав би з’явитися на ідентичній конфігурації ОС, шрифтів і відеокарти.

Що сайт отримує через Canvas

Canvas — це звичайний HTML API для малювання. Сайт може створити невидимий для користувача canvas, намалювати на ньому текст, фігури, градієнти, емодзі та лінії з різним згладжуванням, а потім використати результат.

Для користувача нічого не відбувається: вікно не блимає, картинка не з’являється. Але в пам’яті браузера залишається набір пікселів. Його можна захешувати й отримати короткий рядок.

Чому в різних людей виходять різні значення:

• різні ОС по-різному згладжують шрифти, і системні шрифти, зокрема емодзі-шрифти, теж відрізняються між ОС;
• різні GPU і драйвери трохи по-іншому рахують графіку;
• набір установлених шрифтів впливає на фінальне зображення;
• браузери й версії графічних бібліотек можуть давати невеликі відмінності у фінальному рендері.

Це не означає, що Canvas сам по собі завжди дає унікальний відбиток для конкретної людини. Але він додає ще один шар даних до загальної картини. Разом із User-Agent, параметрами екрана, часовим поясом, мовою та WebGL це допомагає сайтам розрізняти пристрої й оцінювати, чи виглядає середовище реальним або підміненим.

Що додає WebGL

WebGL схожий на Canvas, але працює через графічний пайплайн. Сайт може не лише намалювати картинку та порівняти пікселі, а й запросити графічні параметри: підтримувані розширення, ліміти, точність шейдерів і те, наскільки узгоджено виглядають vendor і renderer.

Для антифроду важливий не окремий параметр, а узгодженість. Якщо профіль каже «звичайний Chrome на macOS», а WebGL виглядає як серверний Linux із програмним рендерером, це помітно. Якщо User-Agent заявляє один тип пристрою, а графічний стек схожий на інший, це теж не виглядає органічно.

Чому простий JS-шум може палити сильніше, ніж допомагати

Найпростіший спосіб «захистити» Canvas — перехопити методи на кшталт HTMLCanvasElement.prototype.toDataURL і підмінити результат через JavaScript. Так працює багато JS-розширень і саморобних патчів: сайт запитує картинку, а скрипт трохи змінює пікселі або повертає заздалегідь підготовлену відповідь.

Проблема в тому, що така підміна теж помітна.

Сайт може перевіряти не лише фінальний хеш, а й поведінку функцій. Наприклад, у нативних JavaScript-функцій є характерне представлення через Function.prototype.toString(). MDN показує, що вбудовані функції повертають рядок із [native code]: Function.prototype.toString(). Якщо метод перевизначений неакуратно, це видно одразу.

У Castle є хороший практичний розбір: вони показують, як canvas-noise часто реалізують через перехоплення toDataURL, і які перевірки допомагають помітити підміну: Detecting noise in canvas fingerprinting.

Canvas, який постійно змінюється, не гарантує, що браузер користувача не викличе підозр. Іноді відбувається навпаки: сайти бачать нестандартну поведінку, коли браузер відрізняється від звичайного Chrome і працює зі зміненими нативними API.

Унікальний відбиток — не завжди хороший відбиток

В антидетект-маркетингу часто звучить фраза «100% unique fingerprint». Звучить красиво, але для довіри це сумнівна мета.

Сайтам важлива не унікальність заради унікальності. Їм важливі стабільність, правдоподібність і відповідність очікуваним кластерам пристроїв. Звичайний користувач рідко виглядає як випадково зібраний набір параметрів: один GPU від Windows-ноутбука, шрифти від Linux, часовий пояс з однієї країни, мова з іншої, WebGL-рендерер із третьої.

Дослідження Hiding in the Crowd добре показує логіку «натовпу»: автори зібрали понад 2 мільйони браузерних відбитків і виявили, що не всі вони унікальні. Але вони також наголошують на важливій речі: якщо в неунікального відбитка змінюються окремі ознаки, він із великою ймовірністю стає унікальним. Для антидетекту це прямий урок: ламати один параметр без узгодження з іншими небезпечно.

Підсумок такий: якщо ваш відбиток генерації зображення унікальний, найімовірніше, ви використовуєте слабкий антидетект-браузер. Водночас варто орієнтуватися на власний сценарій. Якщо сайти, з якими ви працюєте, не банять вас за унікальний Canvas fingerprint, можна продовжувати так працювати. Але якщо саме унікальний Canvas fingerprint створює проблеми, має сенс вимкнути шуми, працювати на профілях із тією ж ОС, що й у вашої реальної машини, і підбирати відеокарти з рендерингом, максимально близьким до вашої реальної GPU.

Який підхід виглядає природніше

Робоча мета — не «новий хеш при кожному запуску». Робоча мета — профіль, який виглядає цілісно.

Нормальний Canvas/WebGL-профіль має бути:

• стабільним усередині одного профілю;
• узгодженим з ОС, браузером, GPU, екраном, шрифтами та мовою;
• достатньо поширеним, щоб не виглядати екзотикою;
• без грубих JS-хуків, які сайт може побачити зсередини сторінки;
• передбачуваним: якщо шум використовується, він не повинен хаотично стрибати між двома викликами того самого тесту.

До речі, великі privacy-браузери теж не зводять захист до «рандому на кожен піксель». Brave описує свій підхід як randomization-захист із seed на профіль і сайт, щоб значення залишалися стабільними там, де це потрібно: Fingerprinting defenses 2.0. Це не інструкція з антидетекту, але хороший приклад нормальноï інженерної логіки: захист має зменшувати зв’язуваність, а не перетворювати браузер на набір випадковостей.

Як ми підходимо до цього в 0detect

У 0DETECT ми виходимо з простої ідеї: Canvas і WebGL не можна розглядати окремо від усього профілю. Недостатньо просто «поміняти хеш». Браузер має виглядати як реальне, цілісне середовище.

Це видно і в нашій документації зі створення профілю. Ми описуємо профіль як “автоматично сформовану колекцію відбитків, зібраних із реальних пристроїв”, а не як набір випадкових значень: Створення профілю.

У загальних налаштуваннях профілю ми задаємо не лише User-Agent і версію браузера. Там само є ОС, версія релізу, роздільна здатність екрана, масштабування, назва пристрою, MAC-адреса, шрифти, мова, часовий пояс і геолокація. Частина цих параметрів за замовчуванням підбирається з урахуванням зовнішнього IP, наприклад мова, часовий пояс і координати. Це важливо, тому що графічний відбиток не повинен жити окремо від географії, мережі й платформи.

У блоці “Обладнання” ми окремо показуємо, що Canvas/WebGL пов’язані з апаратною частиною профілю: CPU cores, RAM, відеокарта, звукова карта, WebGL, Canvas, Client Rects і медіапристрої.

Ми емулюємо відеокарту та її параметри на основі реальних відбитків користувацьких пристроїв. WebGL отримує апаратний шум, який імітує природні реальні пристрої. Canvas отримує апаратний шум у рендерингу, щоб приховати реальні графічні характеристики машини. Це краще описує задачу, ніж фраза «просто зробити новий Canvas-хеш».

Саме тому для нас важливі три речі.

Перша — узгодженість. WebGL renderer, Canvas, шрифти, екран, ОС, User-Agent, мова та мережа мають складатися в одну історію. Якщо профіль виглядає як MacBook, він не повинен віддавати сигнали, характерні для серверного Linux.

Друга — стабільність. Один і той самий профіль не повинен щоразу перетворюватися на новий пристрій. Для антифрод-системи різка зміна графічного відбитка всередині звичного акаунта виглядає не як приватність, а як ризик.

Третя — мінімізація видимих слідів підміни. Що більше логіки винесено в JS-ін’єкції на сторінці, то вищий шанс бути викритим. Якщо ваш антидетект-браузер робить підміни всередині базового коду, слідів у JavaScript-середовищі не залишається.