Аудіо-контекст та шрифти: Забуті вектори детекції мультиакаунтів

Більшість операторів антидетект-браузерів зосереджені на “великих” векторах фінгерпринтингу — canvas, WebGL, User-Agent. І поки вони ретельно налаштовують GPU профілі та Client Hints, детектори тихо фіксують AudioContext осциляції та шрифтові метрики. Ці два вектори залишаються в сліпій зоні більшості захисних рішень — і саме тому вони такі ефективні для детекції.

AudioContext: наука за звуковим відбитком

AudioContext fingerprinting — один із найточніших методів ідентифікації браузера, і при цьому один із найменш відомих серед практиків. Принцип роботи: Web Audio API використовує звукові алгоритми обробки, результати яких залежать від апаратного та програмного забезпечення пристрою.

Базовий тест виглядає так:

const context = new AudioContext();
const oscillator = context.createOscillator();
const analyser = context.createAnalyser();
const gain = context.createGain();
const scriptProcessor = context.createScriptProcessor(4096, 1, 1);

gain.gain.value = 0; // тихо — без реального звуку
oscillator.type = 'triangle';
oscillator.connect(analyser);
analyser.connect(scriptProcessor);
scriptProcessor.connect(gain);
gain.connect(context.destination);

oscillator.start(0);

Результат аналізу FFT-буфера analyser — унікальний числовий підпис, який залежить від реалізації звукових алгоритмів в ОС, драйверів аудіо, процесорної архітектури та навіть компілятора, яким зібрано браузер.

Чому такий рівень точності? Web Audio обробка включає DSP (Digital Signal Processing) алгоритми — FFT, convolution, biquad фільтри. Їх реалізація в різних браузерах та на різному залізі дає мікровідмінності в результатах обчислень з плаваючою точкою. Windows з WASAPI стеком дає інший результат, ніж macOS з CoreAudio, ніж Linux з ALSA.

Шари AudioContext fingerprinting

AudioContext fingerprint складається з кількох рівнів, і кожен дає незалежну точку ідентифікації.

Рівень 1: Oscillator output. Різні браузерні рушії обчислюють форми хвиль по-різному. Triangle wave на Blink (Chrome) vs Gecko (Firefox) vs WebKit (Safari) — різні числові послідовності в FFT виводі. Але навіть два Chrome браузери можуть давати різні результати на різному залізі через специфіку floating-point у CPU.

Рівень 2: SampleRate та baseLatency. AudioContext.sampleRate визначається аудіо-пристроєм системи. Типові значення: 44100 Hz (більшість систем), 48000 Hz (HDMI output або певні USB DAC), 22050 Hz (деякі мобільні пристрої). baseLatency відображає буферний розмір системи — різний для різних аудіо-конфігурацій.

Рівень 3: AudioParam granularity. Деякі сайти перевіряють як саме AudioParam.value округляється при установці. Реальні браузери мають специфічні правила precision, які залежать від реалізації.

Рівень 4: Timing fingerprint. AudioContext.currentTime збільшується з фіксованою частотою, але точність цих таймерів різна. Деякі детектори вимірюють drift між AudioContext.currentTime та performance.now().

Font Fingerprinting: складніше, ніж здається

Шрифти — класичний вектор фінгерпринтингу, але сучасні методи набагато витонченіші від простого переліку встановлених шрифтів.

Метод 1: Наявність шрифтів через CSS. Класичний підхід — рендерувати текст у прихованому елементі різними шрифтами та вимірювати розміри. Якщо розмір відрізняється від базового (fallback) шрифту — шрифт встановлено. Цей метод дозволяє перевірити сотні шрифтів за секунди.

function hasFont(fontName) {
  const s = document.createElement('span');
  s.innerHTML = 'mmMMMWWW';
  s.style.position = 'absolute';
  s.style.width = 'auto';
  s.style.fontSize = '300px';
  s.style.fontFamily = 'monospace'; // baseline
  document.body.appendChild(s);
  const baseWidth = s.offsetWidth;
  s.style.fontFamily = `'${fontName}', monospace`;
  const fontWidth = s.offsetWidth;
  document.body.removeChild(s);
  return baseWidth !== fontWidth;
}

Метод 2: Canvas font rendering. Рендеринг тексту через Canvas з конкретним шрифтом та аналіз пікселів — дозволяє виявити не просто наявність шрифту, а точні метрики рендерингу: kerning, hinting, anti-aliasing. Ці метрики різні навіть для однакового шрифту на різних ОС.

Метод 3: document.fonts.check(). CSS Font Loading API дозволяє програмно перевіряти наявність шрифтів. document.fonts.check('16px Arial') повертає true якщо Arial доступний. Детектори використовують це для швидкого сканування.

Метод 4: document.fonts enumeration. В деяких браузерах можна ітерувати document.fonts для отримання списку завантажених шрифтів. Хоча це обмежено веб-шрифтами та системними шрифтами, завантаженими сторінкою, поєднання з іншими методами дає точну картину.

Чому шрифти видають ОС точніше за User-Agent

Набір системних шрифтів — найнадійніший індикатор операційної системи. Windows 11 поставляється зі специфічним набором шрифтів (Segoe UI Variable, Cascadia Code), macOS Ventura має свій набір (SF Pro, New York), Ubuntu — свій (Ubuntu font family, Liberation Sans). Ці набори перетинаються, але не збігаються.

Ось чому шрифтовий фінгерпринт такий небезпечний: якщо ваш профіль заявляє Windows 11, але список виявлених шрифтів відповідає macOS — це невідповідність, яку не покриває підміна User-Agent.

Реальний набір системних шрифтів для Windows 11 (підмножина для перевірки):

Arial, Times New Roman, Courier New — universal
Segoe UI, Segoe UI Variable — Windows-specific
Calibri, Cambria, Candara — Microsoft Office fonts
Cascadia Code, Cascadia Mono — Windows Terminal fonts
Gabriola, Consolas — Windows-only system fonts

Для macOS Ventura:

Helvetica Neue, Geneva — macOS-specific
SF Pro Display, SF Compact — Apple system fonts (не доступні на Windows)
New York — Apple serif font
Hoefler Text — macOS-exclusive

Антидетект-браузер, що правильно підміняє UA на Windows 11, але виявляє SF Pro Display серед доступних шрифтів — миттєво розкривається.

Векторний аналіз: поєднання AudioContext та Font

Найсучасніші детектори не аналізують вектори окремо — вони будують мультивимірні профілі. AudioContext + Font fingerprint + Canvas + WebGL утворюють комбінований підпис, де кожен вектор підтверджує або спростовує інші.

Приклад атаки: профіль заявляє macOS 14 на Apple Silicon. Детектор перевіряє:

AudioContext sampleRate — 48000 Hz (типово для Apple Silicon Macs)
Наявність шрифтів SF Pro — так (правильно)
WebGL renderer — “Apple M2” (правильно)
Canvas — детерміновано, без артефактів Windows

Якщо один із цих елементів не збігається — профіль помічається як підозрілий. Якщо AudioContext дає sampleRate 44100 (типово для не-Apple пристроїв), але все інше каже macOS — невідповідність.

Практика захисту: що реально працює

AudioContext захист: правильний підхід — детерміноване спотворення результатів аудіо-обробки на основі seed профілю, а не рандомний шум. Seed визначає конкретні offset значення, які додаються до FFT результатів — результат стабільний між сесіями (реалістично), але унікальний для кожного профілю.

Santiago використовує audio:seed конфігурацію в Camoufox: seed=0 вимикає шум (реальний аудіо-вихід), позитивний seed дає детермінований унікальний вихід для кожного профілю. Для більшості операцій рекомендується унікальний позитивний seed на профіль.

Важливо: повна блокування AudioContext (new AudioContext() кидає помилку) — погана ідея. Багато легітимних сайтів використовують AudioContext для відтворення звуку та UI feedback. Блокування спричиняє функціональні зломи та саме по собі є детекційним сигналом.

Font захист: антидетект має надавати список шрифтів, узгоджений із декларованою ОС. Santiago дозволяє задати конкретний список шрифтів для профілю — цей список має відповідати реальному набору шрифтів для обраної ОС.

Для Windows 11 профілю — список шрифтів Windows 11. Для macOS Ventura — список macOS Ventura. Не треба включати всі шрифти — достатньо ключових маркерних шрифтів (SF Pro для macOS, Segoe UI Variable для Windows) плюс загальний набір.

Критична помилка: надто малий список шрифтів. Якщо профіль Windows 11 видає лише 10 шрифтів, тоді як реальна Windows 11 має 100+, детектор фіксує аномалію. Але і надмірно великий список (більше, ніж типово для ОС) — теж підозрілий.

SpeechSynthesis: третій забутий вектор

Пов’язаний із AudioContext вектор — SpeechSynthesis API. speechSynthesis.getVoices() повертає список доступних голосів для text-to-speech, і цей список специфічний для ОС.

Windows 11 має голоси: Microsoft David, Microsoft Zira, Microsoft Mark (US English) плюс мовні голоси. macOS: Alex, Samantha, Victoria, Fred, Karen, Moira, Rishi та десятки інших. Linux: залежить від встановлених пакетів, часто порожній список.

Якщо профіль заявляє macOS, але getVoices() повертає Microsoft David — невідповідність очевидна.

Santiago керує SpeechSynthesis через init script, що обмежує getVoices() до ОС-специфічного списку. Windows профілі отримують David/Zira/Mark, macOS профілі — Alex та відповідний набір.

Timing attacks через AudioContext

Окремий клас атак — timing-based fingerprinting через AudioContext. Створення та ініціалізація AudioContext займає різний час залежно від системи. Деякі детектори вимірюють performance.now() до та після new AudioContext():

Дуже швидко (< 1ms): підозріло — може бути mocked
Дуже повільно (> 100ms): підозріло — може бути virtualized
Нормально (5-30ms): типово для реального браузера

Аналогічно, час виконання аудіо-обробки через ScriptProcessorNode або AudioWorklet — предикативний для конкретної системи.

Висновок: комплексний підхід обов’язковий

AudioContext та Font fingerprinting — не другорядні вектори. Вони входять до топ-5 найнадійніших методів ідентифікації браузера за даними дослідників AmIUnique та FPmon. При цьому більшість антидетект-рішень або ігнорують їх, або реалізують захист неправильно (рандомний шум замість детерміністичного спотворення, неправильний список шрифтів).

Правильна реалізація вимагає:

Детермінованого, seed-based AudioContext виходу (унікального, але стабільного на профіль)
Шрифтового списку, узгодженого з декларованою ОС
SpeechSynthesis голосів, що відповідають ОС
Узгодженості всіх цих векторів між собою та з іншими параметрами профілю

Пропустити один із цих векторів — означає залишити дірку, якою скористаються детектори.