Аудио-отпечатки: как AudioContext отслеживает вас

BotBrowser может сделать считывание AudioContext воспроизводимым в авторизованном тесте с объявленными профилем, уровнем, режимом развёртывания и фиксированным --bot-noise-seed. Он не гарантирует анонимность, принятие сайтом или идентичный аудиорендеринг на каждом хосте, профиле или аудиостеке.

Смотреть видео

Это англоязычное видео объясняет, как беззвучная страница может прочитать число из аудиодвижка браузера через офлайн-рендеринг, и запускает в локальной проверке одну фиксированную процедуру Web Audio дважды на одной частоте дискретизации и один раз на более высокой. Проверка не использует прокси или профиль и не доказывает идентичность, анонимность, доступ или решение удалённого сайта. Звук на английском языке.

Почему аудио становится отпечатком

В каждом веб-браузере есть встроенная система обработки звука. Web Audio API, а именно AudioContext и OfflineAudioContext, позволяет странице создавать, соединять и анализировать аудиосигналы полностью программно. Доступ к микрофону не нужен, звук не воспроизводится, запрос разрешения не появляется. API создан для законных задач: игр, музыкальных приложений и звуковых эффектов в реальном времени. Та же цепочка обработки может давать разные измерения при разных условиях рендеринга, а системы отслеживания могут сочетать это отличие с другими сигналами. Такой идентификатор называют аудио-отпечатком; воспроизводимость зависит от измерения и не гарантируется после очистки cookie, обновления или смены контекста. О том, как страницы получают доступ к этому API и как звук используется в обычных процессах, рассказано в материале Доступ к Web Audio API и практические аудиопроцессы.

Это отличие не является недостатком какого-то одного браузера. Спецификация Web Audio описывает, что должен делать каждый узел, но результаты вычислений с плавающей точкой на реальной машине зависят от реализации, аудиостека операционной системы и используемой частоты дискретизации. Два устройства могут выполнить один и тот же JavaScript и всё же получить буферы, которые различаются в младших разрядах. Эти разряды малы, но на одном устройстве они повторяются, и именно сочетание малости и повторяемости делает их полезным сигналом.

Дальнейшие разделы проводят это отличие от источника до практической проверки: откуда оно берётся, почему привычные меры приватности оставляют заметные несоответствия, что BotBrowser документирует для аудиовыхода и как подтвердить согласованность в вашей собственной конфигурации.

TL;DR

• Web Audio и OfflineAudioContext могут раскрывать повторяемые различия рендеринга без микрофона и слышимого звука.
• Аудиозначение описывает заявленные версию, профиль, частоту, каналы и контекст, но не доказывает физическое устройство.
• VPN и очистка cookie не меняют локальный рендеринг, а частичная рандомизация создаёт несогласованность.
• Корректный профиль и фиксированный --bot-noise-seed позволяют воспроизводить сопоставимые авторизованные сессии при условиях ENT Tier2.
• Проверяйте аудио вместе с canvas, WebGL, шрифтами и navigator; BotBrowser не гарантирует анонимность или принятие сайта.

Содержание

• Смотреть видео
• Почему аудио становится отпечатком
• Почему VPN, расширения с шумом и рандомизация оставляют несоответствия
• Поведение аудио в BotBrowser и флаги запуска
• Проверка согласованности аудио в вашей конфигурации
• FAQ: Вопросы об аудио-отпечатках
• Итоги

Схема показывает идею на одном рисунке. Процедура остаётся постоянной, но объявленные условия рендеринга могут менять числа; профиль с фиксированным seed может сделать сопоставимые сессии воспроизводимыми, если build, профиль, развёртывание и контекст не меняются.

Влияние бесшумного аудиорендеринга на приватность

Аудио-отпечаток привлекателен для систем отслеживания тем, что он незаметен. Пользователь не получает ни уведомления, ни диалога разрешения, ни визуального признака того, что идёт обработка звука. Страница может создать офлайн-контекст рендеринга, обработать короткий буфер и прочитать результат за доли секунды, ни разу не обратившись к динамикам.

Публичные исследования измерений веба, например работа Englehardt и Narayanan 2016 года по миллиону сайтов, описывают скрипты, которые используют аудиорендеринг как один из нескольких сигналов для распознавания вернувшихся браузеров. Этот сигнал редко применяют отдельно. Его сочетают с canvas, WebGL, шрифтами, свойствами экрана и значениями navigator, и каждый дополнительный сигнал сужает круг устройств, которые могли дать такой совокупный результат. Частота обновления экрана и ритм видео образуют отдельный сигнал, связанный со временем, он разобран в материале Фингерпринтинг частоты кадров: экран и видео.

Аудиорезультат может оставаться похожим при повторных измерениях, если версия браузера, профиль, параметры аудио и условия сессии объявлены и не меняются. Это не гарантия постоянства: обновление, параметры рендеринга и контекст могут изменить измерение. Поэтому приватное окно, очистка cookie или VPN сами по себе не доказывают, изменился сигнал или нет.

Поэтому вопрос приватности не в том, может ли сайт использовать AudioContext. Аудио является обычной частью веб-платформы, и многие сайты используют его для воспроизведения звука. Вопрос в том, отражают ли числа, которые возвращает аудиопроцедура, ваше реальное оборудование и остаются ли они согласованными со всем остальным, что браузер сообщает о себе.

Чем различается рендеринг OfflineAudioContext на разных устройствах

В Web Audio API есть два основных интерфейса, важных для этой темы.

AudioContext управляет обработкой звука в реальном времени. Он создаёт аудиограф, в котором узлы представляют такие операции, как генерация колебаний, регулировка усиления, компрессия и анализ. Каждый узел обрабатывает аудиоотсчёты, и результат зависит от нижележащей аудиоподсистемы.

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

Почему результат различается между устройствами? Есть несколько причин.

• Рендеринг и реализация браузера. Версия, внутренняя точность, оптимизации и параметры рендеринга могут менять полученные сэмплы. Офлайн-рендеринг напрямую не проходит через динамики или аудиооборудование.
• Согласованная конфигурация. Частота дискретизации, раскладка каналов и контекст могут зависеть от хоста и режима развёртывания. Измеренная разница сама по себе не доказывает конкретную причину в железе или драйвере.
• Реализация браузера. Chromium, Firefox и WebKit реализуют спецификацию Web Audio независимо. Внутренняя точность, оптимизации быстрых путей и параметры сборки у них различаются.
• Согласование частоты дискретизации. Частота по умолчанию зависит от операционной системы и оборудования. Система с частотой 44100 Гц по умолчанию даёт иной результат компрессора, чем система с 48000 Гц, даже при одинаковых узлах и параметрах.
• Раскладка каналов. Число выходных каналов и способ их микширования могут изменить буфер, который процедура считывает обратно.

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

Полезная модель: аудиорезультат есть измерение всего стека воспроизведения, выполненное незаметно для пользователя. Чтение AudioContext.sampleRate сообщает странице, какую частоту согласовал стек. Рендеринг буфера показывает, как этот стек выполняет арифметику. Чтение выхода анализатора показывает, как ведут себя узлы анализа на том же входе. Каждое из этих действий дёшево, ни одному не нужно разрешение, а вместе они описывают хост гораздо точнее, чем любое отдельное значение.

Почему VPN, расширения с шумом и рандомизация оставляют несоответствия

Некоторые распространённые меры иногда подают как ответ на аудио-отпечатки. У каждой есть предел, который стоит понимать, прежде чем на неё полагаться.

VPN меняют IP-адрес, но не влияют на аудиорендеринг. Web Audio API работает целиком внутри браузера и не имеет сетевой составляющей. Аудиорезультат одинаков при подключении через VPN, прокси или напрямую.

Расширения браузера, предлагающие защиту звука, обычно перехватывают вызовы JavaScript и добавляют случайный шум к возвращаемым значениям. У такого подхода три ограничения, которые можно проверить в собственных тестах. Во-первых, настоящее устройство повторяет собственный результат, поэтому процедура, которая в вашем тесте возвращает разное значение при каждом запуске, показывает, что выход нестабилен. Во-вторых, расширение может охватывать только часть методов, например чтение буфера, а родственные методы вроде AnalyserNode.getFloatFrequencyData оставлять без изменений, поэтому сравнивайте связанные значения друг с другом, чтобы убедиться, что они согласуются. В-третьих, расширение работает на уровне страницы и не меняет то, как звук был отрендерен изначально.

Рандомизация аудиопараметров, таких как частота дискретизации или число каналов, часто ломает приложения, которым нужно точное воспроизведение звука. Музыкальные инструменты, видеозвонки и игры опираются на стабильное поведение звука. Кроме того, рандомизированное значение должно совпадать с тем, что реально отрендерено. Заявленная частота дискретизации, не совпадающая с отрендеренным результатом, это сочетание, которого не даёт ни одно настоящее устройство.

Полная блокировка AudioContext самый грубый вариант. Она убирает сигнал, но вместе с ним и законное аудио, а отсутствие аудиоинтерфейса само по себе необычно для современного браузера.

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

Общая нить здесь согласованность. Эффективный подход должен держать согласованными три вещи: значения, которые читает страница, отсчёты, которые реально рендерятся, и остальную идентичность, которую сообщает браузер. Изменение, применённое только к одной из них, оставляет несоответствие, которое объяснить труднее, чем исходное различие.

Поведение аудио в BotBrowser и флаги запуска

Согласно документации BotBrowser по аудио, BotBrowser может применять детерминированный шум к выходу Web Audio при корректном профиле и документированных условиях уровня и развёртывания. Каждый результат нужно проверять для точных build, профиля, флагов и контекста.

Шум по профилю, включён по умолчанию. Шум AudioContext включён по умолчанию. Флаг --bot-noise-audio-context управляет им явно: true по умолчанию и false для отключения.

Воспроизводимость с seed шума. Флаг --bot-noise-seed предназначен для воспроизводимости между сопоставимыми сессиями и требует ENT Tier2. Повторное использование seed может сделать сессии связываемыми; это не гарантирует одинаковый выход для всех build, хостов, развёртываний или контекстов. Без фиксированного seed шум меняется от сессии к сессии по замыслу.

Согласованность между контекстами выполнения. Документация описывает согласованность между основным потоком, Web Worker и сервис-воркерами в одной сессии. Считайте это возможностью, которую нужно проверить для точных build и контекста, а не универсальной гарантией.

Инструмент записи для вашей собственной проверки. В BotBrowser есть AudioLab, инструмент, который записывает вызовы Web Audio API, сделанные страницей за сессию. В документации он описан как способ изучить, как собираются аудиосигналы, и проверить собственную конфигурацию.

Есть и ограничения. Выход BotBrowser следует профилю только при загрузке корректного профиля. Воспроизводимость при фиксированном seed зависит от уровня ENT Tier2. Некоторые headless-конфигурации могут вообще не инициализировать аудио, поэтому перед тем как полагаться на результат, убедитесь, что ваш режим развёртывания поддерживает звук. Аудио остаётся одним сигналом из многих, и согласованный аудиорезультат не гарантирует, как конкретный сайт отнесётся к сессии. Эти ограничения повторяются в итогах в конце статьи.

Базовая загрузка профиля

Простейшая конфигурация загружает профиль, содержащий аудиопараметры:

chrome --bot-profile="path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Этот единственный флаг настраивает поведение звука так, чтобы оно следовало загруженному профилю.

Воспроизводимое аудио с seed шума

Для воспроизводимых аудиорезультатов между сессиями:

chrome --bot-profile="path/to/profile.enc" \
       --bot-noise-seed=42 \
       --user-data-dir="$(mktemp -d)"

Одинаковая комбинация профиля и seed даёт одинаковый аудиовыход. Измените seed, чтобы получить другой, но столь же стабильный результат. Seed принимает целые значения от 1 до наибольшего беззнакового 32-разрядного целого, а значение 0 оставляет значения профиля по умолчанию без детерминированного seed. Для этого флага нужен ENT Tier2.

Интеграция с Playwright

const { chromium } = require('playwright');

const browser = await chromium.launch({
  executablePath: 'path/to/botbrowser/chrome',
  args: ['--bot-profile=path/to/profile.enc', '--bot-noise-seed=42'],
});

Puppeteer принимает те же аргументы через параметр args. Это обычные аргументы браузера, поэтому один и тот же профиль и seed работают в любой из двух библиотек.

Просмотр базового выхода профиля

Если нужен базовый аудиовыход профиля без применённого шума:

chrome --bot-profile="path/to/profile.enc" \
       --bot-noise-audio-context=false \
       --user-data-dir="$(mktemp -d)"

Это шаг сравнения, а не рекомендуемое значение по умолчанию. Он показывает, что вносит сам профиль до добавления шума.

Проверка согласованности аудио в вашей конфигурации

Чтобы убедиться, что аудиовыход следует загруженному профилю, сравните результаты между вашими собственными сессиями. Используйте тестовую страницу, которую вы контролируете, или публичную страницу для проверки отпечатков, и записывайте аудиозначения при каждом запуске.

Проверка воспроизводимости. Запустите две отдельные сессии с одним профилем и одним --bot-noise-seed, выполните в каждой одну и ту же аудиопроцедуру и сравните выход. Результаты должны совпасть. Запустите третью сессию с другим seed и убедитесь, что её результат отличается, но стабилен при повторе. Для фиксированного seed нужен ENT Tier2.

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

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

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

Запись вызовов. Для более глубокой проверки AudioLab может записать вызовы Web Audio, которые страница делает за сессию, и вы увидите, какие аудиовозможности страница реально использует, прежде чем решать, что сравнивать.

Эти проверки выполняются на ваших собственных машинах. Они не требуют разрешения на микрофон и не зависят от сети, поэтому полезные проверки проводятся внутри браузера.

Как читать собственные аудиорезультаты

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

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

Во-вторых, согласуется ли аудиорезультат с остальным профилем? Профиль, представляющий одну операционную систему, не должен возвращать аудиоповедение другой. Одно аудио ничего не доказывает, поэтому профиль нужно рассматривать целиком, вместе с canvas, WebGL, шрифтами и свойствами navigator.

В-третьих, стабилен ли результат там, где должен быть стабильным? Настоящее устройство возвращает одно и то же значение при каждом выполнении одной процедуры. Если ваш собственный тест возвращает разное значение при каждом вызове, конфигурация невоспроизводима, и профиль с флагами нужно перепроверить. С BotBrowser самый простой способ убедиться, что ваша конфигурация воспроизводима, запустить две сессии с одним профилем и одним --bot-noise-seed и сравнить выход. Другой seed с тем же профилем должен дать другой, но по-прежнему внутренне согласованный результат.

У флага --bot-noise-audio-context=false одно конкретное назначение. Он показывает базовый выход профиля без шума, что удобно, когда нужно понять вклад самого профиля. Считайте его шагом сравнения, а не значением по умолчанию: шум включён по умолчанию, и в большинстве конфигураций его стоит оставить включённым.

Смена IP-адреса, очистка cookie или приватное окно не обязательно изменят аудиомерку. Всегда проверяйте объявленные условия рендеринга, а не делайте вывод о безусловной постоянности сигнала.

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

Привычки настройки, сохраняющие согласованность аудио

• Всегда загружайте профиль. Запуск BotBrowser без --bot-profile означает, что аудиовыход берётся с вашего собственного оборудования. Именно профиль заставляет аудиовыход следовать заявленной платформе.
• Подбирайте профиль под задачу. Профиль Windows даёт типичный для Windows аудиовыход. Выбирайте профиль, который соответствует платформе, которую вы проверяете.
• Оставляйте аудиошум включённым, если вы не сравниваете. Флаг --bot-noise-audio-context=false убирает один слой вариации. Используйте его для сравнения с базовым профилем, а затем включите шум обратно.
• Проверяйте режим развёртывания. Некоторые headless-конфигурации могут не инициализировать аудио. Убедитесь, что звук доступен в используемом режиме, прежде чем сравнивать результаты.
• Охватывайте другие поверхности. Аудио остаётся одним сигналом из многих. Используйте полный профиль, который охватывает также canvas, WebGL, шрифты и свойства navigator, и проверяйте их вместе.
• Фиксируйте версии на время сравнения. Если между двумя сессиями изменились версия браузера или профиль, разница в аудиовыходе может быть вызвана этим изменением, а не вашими флагами.

FAQ: Вопросы об аудио-отпечатках

В: Требует ли аудио-отпечаток доступа к микрофону? О: Нет. Используются возможности синтеза и обработки Web Audio API. Микрофон, разрешения и слышимый звук не задействованы, вся процедура выполняется программно.

В: Можно ли узнать, использует ли сайт обработку звука? О: В принципе, можно следить за созданием AudioContext и OfflineAudioContext в инструментах разработчика браузера, а AudioLab может записать вызовы Web Audio, которые страница делает за сессию. Скрипты часто обфусцированы, поэтому отсутствие явного вызова не доказывает, что ничего не происходит.

В: Влияет ли seed шума на качество воспроизведения звука? О: Seed шума управляет небольшой численной вариацией аудиозначений, которые используются как сигнал об устройстве. В документации BotBrowser по аудио он описан как шум, применяемый к выходу Web Audio, а конкретный аудиосценарий, от которого вы зависите, стоит проверить в собственном развёртывании.

В: Насколько стабилен аудиовыход при фиксированном seed шума? О: Согласно документации, один и тот же профиль и seed дают один и тот же аудиовыход между сессиями. Считайте это документированным поведением для корректного профиля на уровне ENT Tier2 и подтверждайте его проверкой двух сессий, описанной выше.

В: Что будет, если использовать разные seed шума с одним профилем? О: Каждый seed даёт другой, но стабильный аудиорезультат. Это полезно, когда отдельным сессиям нужны разные воспроизводимые аудиозначения.

В: Почему результат отличается между запусками headless и с окном? О: В документации отмечено, что некоторые headless-конфигурации могут не инициализировать аудио, поэтому два режима могут вести себя по-разному. Убедитесь, что звук доступен в вашем режиме развёртывания, и сравнивайте сопоставимые условия.

В: Меняет ли VPN или прокси аудиорезультат? О: Нет. Аудиорезультат получается при рендеринге внутри браузера, поэтому смена сетевого маршрута его не меняет.

В: Достаточно ли одной согласованности аудио? О: Нет. Аудио остаётся одним сигналом из многих. Согласованный аудиорезультат помогает, но canvas, WebGL, шрифты и свойства navigator должны с ним согласовываться.

Итоги

Аудио-отпечатки используют естественную вариацию в том, как разные устройства обрабатывают аудиосигналы через Web Audio API. Поскольку это не требует разрешений и не создаёт видимых эффектов, пользователю трудно заметить такое отслеживание и предотвратить его. BotBrowser предоставляет детерминированный шум на основе профиля для выхода AudioContext и Web Audio внутри собственного аудиорендеринга браузера, он включён по умолчанию, поэтому аудиорезультат следует загруженному профилю, а не оборудованию вашей машины. При фиксированном --bot-noise-seed, для которого нужен уровень ENT Tier2, выход воспроизводим между сессиями, и проверить это можно самостоятельно: запустите две сессии с одним профилем и одним seed и сравните аудиовыход. Границы понятны: BotBrowser не может гарантировать, что сайт не обнаружит и не заблокирует автоматизацию, не заменяет другие поверхности отпечатка (canvas, WebGL, шрифты, navigator), которые должен покрывать полный профиль, и не меняет поверхность Web Audio API и поведение вызовов, которые видят сайты; только выходные значения следуют профилю. Аудиорезультаты по-прежнему зависят от корректного профиля, вашего уровня и фиксированного seed. Полный набор защит смотрите на странице возможностей или проверьте согласованность аудио сами в Центре проверки.

Смежные темы: Что такое браузерные отпечатки и Защита WebGL-отпечатков. Проверки Canvas и детерминистического режима остаются отдельными поверхностями регрессии.

Источники

Публичные материалы, на которых основаны утверждения о Web Audio и BotBrowser в этой статье:

• Спецификация W3C Web Audio API
• MDN: Web Audio API
• MDN: OfflineAudioContext
• Документация BotBrowser по аудио
• Englehardt и Narayanan, Online Tracking: A 1-million-site Measurement and Analysis