Скрытый webaudio-фингерпринтинг aliexpress и bluetooth multipoint

20.08.2026 · 6 мин

Я случайно обнаружил странный эффект: стоит открыть главную страницу AliExpress в Firefox или Chrome, и мои Bluetooth-наушники с multipoint вдруг перестают нормально отдавать звук телефону. Закрываю вкладку — всё сразу приходит в себя. Ни видео, ни музыки, ни видимого плеера на странице нет. Очень похоже на магию, пока не начинаешь копать.

Что именно я заметил

Сценарий был простой и раздражающий. Наушники подключены одновременно к ПК и телефону. Обычно это удобно: если на компьютере ничего не играет, звук спокойно уходит с телефона. Но после открытия AliExpress телефонный звук начинал пропадать, как будто компьютер внезапно «держал канал» занятым. При этом обычное отключение звука вкладки, Firefox или Windows не помогало.

Первой мыслью были скрытые медиаэлементы: <audio>, <video>, автоплей, рекламный ролик, что угодно. Но ничего из этого не нашлось. Проблема появлялась не сразу, а через несколько секунд простоя, поэтому я начал смотреть не только на медиа, но и на Web Audio API (интерфейс браузера для создания и обработки звука программно).

ПОТОК ПОИСКА ПРИЧИНЫ
───────────────────
┌───────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│ страница  │ ▶ │ тишина   │ ▶ │ поиск    │ ▶ │ WebAudio │
│ AliExpress│   │ несколько│   │ скрытого │   │ контекст │
│           │   │ секунд   │   │ источника│   │ найден   │
└───────────┘   └──────────┘   └──────────┘   └──────────┘
Проблема проявлялась не сразу, а после короткого периода бездействия

Как я нашёл скрытые аудиоконтексты

Чтобы поймать источник, я обернул конструктор AudioContext и стал логировать каждый созданный контекст вместе со стеком вызовов. Заодно я перехватил AudioNode.prototype.connect(), чтобы увидеть, куда именно строится граф обработки звука.

И это сработало: страница создала два скрытых AudioContext, оба перешли в состояние running и оба были подключены к AudioContext.destination (выходу аудиографа браузера). При этом по-прежнему не было ни одного <audio> или <video>, ни вызовов play(), ни активного media session, ни слышимого звука.

Следы в стеке вызовов вели к двум скриптам: collina.js и fireyejs.js. Оба лежат в каталоге AWSC у домена AliExpress и выглядят как часть антиабьюзной или защитной инфраструктуры Alibaba.

Как устроен этот аудиограф

По сути, скрипты строят цепочку вида: осциллятор (генерирует сигнал) → AnalyserNode (снимает характеристики сигнала) → ScriptProcessorNode (обрабатывает поток в JavaScript) → GainNode, установленный в ноль → destination.

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

И вот тут появляется подозрительный побочный эффект: даже тихий, но активно работающий аудиограф может удерживать аудиопуть системы «занятым». В моём случае этого, похоже, хватило, чтобы Firefox или Windows не отпускали Bluetooth-подключение так, как это обычно происходит, а multipoint-наушники не переключались обратно на телефон.

WEBAUDIO-ЦЕПОЧКА
─────────────────
┌───────────┐   ┌────────────┐   ┌────────────┐   ┌──────────┐   ┌──────────────┐
│ oscillator│ ▶ │ analyser   │ ▶ │ processor  │ ▶ │ gain=0   │ ▶ │ destination   │
│ (sawtooth)│   │ (measure)  │   │ (JS loop)  │   │ (mute)   │   │ (активный выход)
└───────────┘   └────────────┘   └────────────┘   └──────────┘   └──────────────┘
Громкость нулевая, но браузер всё равно вынужден обрабатывать звук

Почему это похоже на фингерпринтинг

WebAudio-тест — не единственный сигнал в этих скриптах. При разборе бандлов видно, что они измеряют и собирают много параметров: canvas-рендеринг, WebGL-рендерер и шейдерные возможности, частоты и данные осциллятора, размеры экрана и viewport, device pixel ratio, аппаратные ресурсы, плагины, поддержку аудио- и видеоформатов, поведение WebRTC, тайминги, а также мышь, касания, фокус, скролл и признаки автоматизации.

Есть и логика для сериализации, шифрования и отправки результатов на телеметрические сервисы Alibaba через fetch() или sendBeacon(). Это уже не выглядит как одна случайная проверка. Скорее, перед нами довольно широкий browser fingerprint (набор характеристик браузера и устройства, по которым можно отличать одного клиента от другого).

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

Зачем aliexpress это может быть нужно

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

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

Но с точки зрения пользователя картина не такая романтичная. Мне не очень нравится, когда обычная витрина магазина тихо запускает графику, аудио, WebRTC, аппаратные и motion API, чтобы следить за поведением. А если это ещё и ломает музыку на телефоне — желание разобраться становится особенно сильным.

Что произошло после блокировки

Я протестировал блокировку двух найденных семейств скриптов в uBlock Origin. После этого главная страница AliExpress продолжала загружаться, но AudioContext больше не создавались, а проблема с Bluetooth multipoint исчезла. Это хороший признак: источник найден, и он действительно был связан не с «обычным» медиа, а с защитным/аналитическим JavaScript.

Если упростить до одной фразы, то страница, по всей видимости, не просто что-то «играла», а активно держала браузер в состоянии аудиообработки ради измерений и, вероятно, fingerprinting-сигналов.

Как проверить и защититься

Выводы

AliExpress, судя по наблюдениям, использует скрытый WebAudio-граф не ради музыки, а ради измерений и идентификации клиента. Побочный эффект оказался неожиданно бытовым: мой Bluetooth multipoint переставал нормально переключать звук обратно на телефон.

Главный вывод простой: даже «тихая» аудиообработка в браузере — это всё ещё активная работа с системным аудиопутём. Для пользователя это может означать и лишний фингерпринтинг, и вполне ощутимые проблемы с устройствами.

Ссылки

Дмитрий Полухин — продуктовый дизайнер. Пишу про разработку, AI и дизайн интерфейсов. Обо мне, контакты и профили.

Что почитать дальше