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

Когда операторы антидетект-браузеров говорят о фингерпринтах, разговор обычно вращается вокруг canvas, WebGL и User-Agent. Это понятно — именно эти векторы наиболее известны и имеют наибольшее количество публичных исследований. Но в 2025-2026 годах продвинутые системы детекции активно эксплуатируют два вектора, которым уделяется значительно меньше внимания: AudioContext fingerprinting и перечисление шрифтов. Если ваши профили проходят canvas-тесты, но аккаунты продолжают банить — скорее всего, проблема именно здесь.

AudioContext Fingerprinting: звуковая сигнатура машины

AudioContext API был создан для обработки аудио в браузере, но обнаружил неожиданное применение в фингерпринтинге. Механизм использует тот же принцип, что и canvas: идентичные вычисления производят незначительно отличающиеся результаты на разном оборудовании.

Конкретная техника: JavaScript создаёт OfflineAudioContext, генерирует аудио-сигнал (обычно осциллятор), применяет к нему трансформации через DynamicsCompressorNode, рендерит буфер и считывает значения семплов. Эти значения — числа с плавающей точкой — детерминированы для конкретного оборудования и версии аудио-стека, но отличаются между разными конфигурациями.

Почему они отличаются? Аудиорендеринг зависит от аудиочипа и его драйверов, реализации AudioContext в операционной системе, версии Core Audio (macOS) или DirectSound/WASAPI (Windows), и точного поведения математики с плавающей точкой на конкретном CPU. Сумма этих факторов производит уникальный «аудио-хеш».

Почему AudioContext особенно опасен для детекции

AudioContext fingerprint имеет несколько свойств, делающих его особенно ценным для систем детекции.

Высокая стабильность. Canvas fingerprint может незначительно варьироваться при обновлении GPU-драйвера или изменении настроек DirectX. AudioContext fingerprint исключительно стабилен — аудиостек операционной системы меняется крайне редко. На практике одна и та же машина сохраняет идентичный аудио-хеш годами.

Независимость от визуальных параметров. Злоумышленник, манипулирующий canvas и WebGL, часто не трогает AudioContext — он не на виду, его не проверяют популярные инструменты вроде pixelscan.net в таком же явном виде. Это делает его надёжным вторичным сигналом: даже если canvas успешно подделан, AudioContext выдаёт реальное оборудование.

Корреляция с аппаратным обеспечением. Специфические значения AudioContext напрямую коррелируют с типом аудиочипа. Realtek ALC-серия (типичная для десктопных материнских плат) производит один кластер хешей, Intel HDA — другой, Apple Silicon Audio Engine — третий. Если вы заявляете в профиле MacBook Pro с M2, но AudioContext hash характерен для Intel NUC с дешёвой Realtek — противоречие очевидно.

Техническая реализация атаки

Современные скрипты сбора AudioContext fingerprint используют несколько методов параллельно:

Первый метод — анализ DynamicsCompressor. Создаётся осциллятор с частотой 10000 Гц, подключается к компрессору с параметрами threshold: -50, knee: 40, ratio: 12, attack: 0, release: 0.25, рендерится в офлайн-контекст. Значения семплов в позициях 4500, 5000, 5500 хешируются.

Второй метод — измерение ChannelMergerNode поведения. Два канала объединяются с определёнными фазовыми соотношениями; поведение при объединении зависит от реализации аудиомикширования в ОС.

Третий метод — OscillatorNode precision. Разные реализации генераторов волн производят незначительно отличающиеся результаты при вычислении форм сигналов.

Совокупность этих трёх методов производит практически уникальный идентификатор для каждой комбинации оборудования и ОС.

Шрифтовой фингерпринт: что ваши шрифты говорят о вас

Перечисление шрифтов — одна из старейших техник фингерпринтинга, известная с 2010 года, но она продолжает оставаться высокоэффективной именно потому, что её часто недооценивают.

Набор установленных шрифтов в системе уникален по нескольким причинам. Во-первых, разные операционные системы поставляются с разными системными шрифтами. Во-вторых, пользователи устанавливают приложения, которые добавляют свои шрифты. В-третьих, некоторые шрифты устанавливаются только с определёнными языковыми пакетами. Комбинация этих факторов создаёт уникальный профиль.

Методы обнаружения шрифтов

Браузеры не предоставляют прямого API для перечисления шрифтов (за исключением экспериментального Font Access API). Вместо этого существует несколько косвенных методов.

CSS-основанное измерение. Классическая техника: создаются скрытые элементы с текстом, отрендеренным в тестируемом шрифте, и измеряются их размеры. Если ширина/высота отличается от baseline (при использовании generic-шрифта), шрифт установлен. Скрипт последовательно проверяет сотни шрифтов. Метод медленный, но работает без специальных разрешений.

Canvas-основанное сравнение. Текст рендерится в canvas с запрошенным шрифтом и без него, затем сравниваются пиксельные данные. Точнее измерения CSS-методом и учитывает субпиксельные различия рендеринга.

Font Access API. В Chrome 103+ сайты могут запросить доступ к локальным шрифтам через window.queryLocalFonts(). По умолчанию требует явного разрешения пользователя, но этот запрос может появляться в легитимных UI-контекстах (например, веб-редакторы шрифтов).

Шрифты как операционная система и регион

Набор шрифтов — это фактически подпись операционной системы, версии, языка и установленного программного обеспечения.

Windows 10 vs Windows 11. Windows 11 добавила ряд новых шрифтов, включая «Segoe UI Variable» и варианты шрифтов с поддержкой переменных осей. Если профиль заявляет Windows 11 (Sec-CH-UA-Platform-Version: "15.0.0"), но шрифт «Segoe UI Variable» не детектируется — противоречие.

macOS версия. Apple регулярно добавляет новые шрифты с обновлениями системы. San Francisco (SF Pro) появился в OS X El Capitan. «New York» — в macOS Catalina. Если профиль заявляет macOS 14 (Sonoma), но «New York» не обнаруживается — несоответствие.

Языковые пакеты. Японская версия Windows включает шрифты, отсутствующие в английской версии. Арабская система имеет свой набор шрифтов для RTL-написания. Если IP-адрес указывает на японского пользователя, а японские шрифты отсутствуют — аномалия.

Профессиональное ПО. Adobe Creative Suite устанавливает несколько сотен шрифтов. Microsoft Office добавляет свой набор. Autodesk, Final Cut Pro, различные инструменты разработчика — каждый вносит вклад в шрифтовой пейзаж машины. Наличие или отсутствие этих шрифтов создаёт поведенческий профиль пользователя.

Практические провалы: как обычно всё ломается

Разберём конкретные сценарии, в которых AudioContext и шрифты выдают антидетект-профили.

Провал 1: серверная среда. Облачные серверы обычно не имеют аудиочипа — AudioContext работает через программный рендеринг. AudioContext hash для программного рендеринга (ALSA, PulseAudio в headless режиме, macOS CoreAudio без аудиоустройства) фундаментально отличается от hash с реальным аудиочипом. Если ваш профиль заявляет реальный десктопный компьютер, но AudioContext hash характерен для безголового сервера — мгновенная красная метка.

Провал 2: минимальный набор шрифтов Linux. Антидетект-браузеры, запускаемые на Linux-серверах, часто имеют минимальный набор шрифтов — только то, что требуется для базового рендеринга. Это 10-20 шрифтов. Реальный пользовательский Windows имеет 50-100 системных шрифтов плюс шрифты от установленных приложений. Разница радикальная и мгновенно детектируется.

Провал 3: рандомизированный AudioContext. Некоторые антидетект-браузеры применяют к AudioContext тот же подход, что и к canvas — рандомизацию при каждом вызове. Но AudioContext вызывается не один раз — сложные страницы могут создавать несколько контекстов. Если каждый вызов возвращает разный hash — это невозможно для реального оборудования, которое всегда детерминировано.

Провал 4: инконсистентный OS и шрифтовой профиль. Профиль заявляет Windows, но заблокированы все попытки CSS-измерений шрифтов (это тоже аномалия). Или профиль заявляет macOS, но при CSS-тесте обнаруживаются типичные Windows-шрифты вроде «Calibri» или «Consolas» в неправильных размерах (рендеринг шрифтов на Windows и macOS принципиально отличается из-за разных механизмов hinting).

Правильная защита: что реально работает

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

Критически важно: шум должен применяться на уровне аудиорендеринга, а не через переопределение JavaScript-функций. OfflineAudioContext.prototype.startRendering переопределить можно, но это заметно для скриптов детекции, проверяющих нативность функций через Function.prototype.toString().

Для шрифтов: подход двухуровневый.

Первый уровень — предоставление правильного набора шрифтов для заявленной ОС. Профиль Windows 11 должен иметь доступ к шрифтам Windows 11. Это не всегда возможно в Linux-окружении, но антидетект-браузер может перехватывать CSS-запросы на измерение шрифтов и возвращать размеры, соответствующие профилю ОС.

Второй уровень — стабильность шрифтового профиля. Набор «обнаруживаемых» шрифтов должен быть стабилен для конкретного профиля. Случайный набор шрифтов при каждой сессии статистически нереалистичен.

Конкретный список для Windows 11-профиля должен включать: все шрифты Calibri, Cambria, Times New Roman, Arial, Verdana, Tahoma из Microsoft Office-пакета; Segoe UI и его варианты; Segoe UI Variable (Windows 11 специфично); шрифты Bahnschrift, Gabriola; дополнительные шрифты из языковых пакетов согласно заявленному языку системы.

Конкретный список для macOS 14-профиля: шрифты SF Pro и SF Mono (системные, не устанавливаемые отдельно, но детектируются по метрикам); Helvetica Neue, Arial, Times New Roman; New York (Catalina+); Gill Sans, Futura из стандартного набора macOS; шрифты из iWork при наличии.

Инструменты проверки

Для быстрой диагностики ваших профилей:

https://browserleaks.com/fonts — перечисление шрифтов через CSS-метод, показывает, какие шрифты «обнаружены» вашим браузером.

https://audiofingerprint.openwpm.com/ — академический инструмент для AudioContext fingerprinting.

https://webbrowsertools.com/audio-fingerprint/ — отображает вычисленный аудио-хеш.

https://www.browserscan.net/ — комплексная проверка, включающая оба вектора.

Запустите эти инструменты в реальном браузере на своей машине — получите baseline. Затем запустите в антидетект-профиле. Разница покажет, какие векторы не обрабатываются корректно.

Стратегия: приоритизация защиты

Не все платформы используют AudioContext и шрифты одинаково активно. Расставьте приоритеты исходя из операционного контекста.

Платформы с наиболее агрессивным использованием этих векторов: Facebook/Meta (исторически один из первых применителей AudioContext fingerprinting), Google (через Google Ads, рекламную сеть и Account Security), TikTok.

Платформы с умеренным использованием: Amazon, eBay (используют, но как вторичные сигналы после поведенческих маркеров), биржи криптовалют второго уровня.

Платформы с минимальным использованием: большинство мелких e-commerce сайтов, форумы, нишевые сервисы.

Для операций на Facebook и Google Ads оба вектора требуют корректной настройки. Для работы с eBay или средними e-commerce платформами вы можете сосредоточиться на canvas, WebGL и поведенческих факторах, уделяя AudioContext и шрифтам меньше приоритета.

Главный вывод: антидетект-защита не может быть избирательной. Система детекции использует все доступные сигналы и ищет любое несоответствие. Профиль, идеальный в 9 из 10 параметров, но проваливающийся на AudioContext — уязвим. Профессиональный подход требует систематической верификации всех векторов, не только наиболее очевидных.