Fingerprinting кодеков WebRTC: когда медиавозможности раскрывают вашу платформу

Введение

WebRTC обеспечивает видео- и аудиосвязь в реальном времени в браузере. Прежде чем медиаданные начнут передаваться между узлами, браузеры перечисляют поддерживаемые кодеки и раскрывают их через API возможностей и предложения SDP (Session Description Protocol). Эта процедура согласования необходима для работающих видеозвонков, но она также создает подробный перечень медиавозможностей вашей системы, который любой веб-сайт может запросить без специальных разрешений.

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

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

Решение BotBrowser

BotBrowser решает проблему fingerprinting кодеков WebRTC на уровне движка браузера, где возможности кодеков фактически определяются. Вместо патчинга JavaScript API или постобработки строк SDP, BotBrowser формирует списки возможностей кодеков из данных профиля fingerprint. Это гарантирует, что каждый API, раскрывающий информацию о кодеках, возвращает согласованные и точные результаты в соответствии с профилем.

Формирование кодеков на основе профиля

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

• Полный список поддерживаемых видео- и аудиокодеков
• Параметры кодеков, включая profiles, levels и специфичные для формата опции
• Правильный порядок кодеков в списках возможностей
• Назначения payload type для генерации SDP

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

Согласованность SDP

BotBrowser гарантирует, что SDP, сгенерированный createOffer(), согласован с возможностями кодеков, сообщаемыми getCapabilities(). Оба источника происходят из одних и тех же данных профиля, поэтому между тем, что сообщают API возможностей, и тем, что появляется в SDP, нет расхождений.

Строки m=video и m=audio в SDP содержат именно те payload types, которые соответствуют набору кодеков профиля. Атрибуты a=rtpmap и a=fmtp совпадают с параметрами объектов возможностей. Любой скрипт, запрашивающий оба API и сравнивающий их, обнаружит идеальную согласованность.

Функциональная совместимость

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

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

• Скрипты fingerprinting видят точный список кодеков профиля.
• Реальные вызовы WebRTC согласуют кодеки, которые могут обработать и оба узла, и локальная система.
• Нет сбоев или ошибок, когда профиль содержит кодек, который хост не может декодировать.

Это критически важное различие. Простое внедрение записей кодеков в список возможностей привело бы к сбоям при попытке браузера фактически использовать эти кодеки. Интеграция BotBrowser на уровне движка корректно обрабатывает границу между представлением fingerprint и функциональной обработкой медиа.

Согласованность между API

BotBrowser обеспечивает согласованность не только внутри API WebRTC, но и по всему набору интерфейсов медиавозможностей:

• RTCRtpSender.getCapabilities() и RTCRtpReceiver.getCapabilities() возвращают кодеки, согласованные с профилем.
• Предложения SDP от createOffer() содержат соответствующие payload types.
• Общие медиа-API, такие как canPlayType() и MediaCapabilities.decodingInfo(), возвращают результаты, согласованные с профилем кодеков WebRTC.
• Общий медиа-fingerprint рассказывает единую, связную историю о платформе.

Эта согласованность между API делает защиту BotBrowser эффективной. Все пути отчетности о кодеках управляются единым, согласованным источником данных: загруженным профилем.

Конфигурация и использование

Базовое использование CLI

Защита кодеков WebRTC автоматическая при загрузке профиля. Дополнительные флаги не нужны:

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

Конфигурация кодеков WebRTC профиля применяется при запуске. Все последующие запросы возможностей WebRTC и генерация SDP будут отражать набор кодеков профиля.

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

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

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

  const context = await browser.newContext({ viewport: null });
  const page = await context.newPage();

  await page.goto('about:blank');

  // Verify WebRTC codec capabilities from the loaded profile
  const codecInfo = await page.evaluate(() => {
    const videoCaps = RTCRtpSender.getCapabilities('video');
    const audioCaps = RTCRtpSender.getCapabilities('audio');
    return {
      videoCodecCount: videoCaps?.codecs.length || 0,
      audioCodecCount: audioCaps?.codecs.length || 0,
    };
  });

  console.log('Video codecs:', codecInfo.videoCodecCount);
  console.log('Audio codecs:', codecInfo.audioCodecCount);

  await browser.close();
})();

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

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('about:blank');

  // Verify WebRTC codec capabilities from the loaded profile
  const codecs = await page.evaluate(() => {
    const videoCaps = RTCRtpSender.getCapabilities('video');
    const audioCaps = RTCRtpSender.getCapabilities('audio');
    return {
      videoCount: videoCaps?.codecs.length || 0,
      audioCount: audioCaps?.codecs.length || 0,
    };
  });

  console.log(`Video codecs: ${codecs.videoCount}`);
  console.log(`Audio codecs: ${codecs.audioCount}`);

  await browser.close();
})();

Сочетание с прокси и настройками платформы

Для полной согласованности платформы объедините защиту кодеков с настройкой прокси и платформы:

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy.example.com:1080" \
       --bot-config-timezone="America/New_York" \
       --bot-config-locale="en-US" \
       --user-data-dir="$(mktemp -d)"

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

Проверка

После настройки BotBrowser с профилем убедитесь, что защита кодеков WebRTC работает:

1. Проверка количества кодеков: Вызовите RTCRtpSender.getCapabilities('video') и убедитесь, что количество кодеков соответствует ожиданиям для целевой платформы профиля.

2. Проверка стабильности: Перезагрузите страницу и повторите. Количество и типы кодеков должны быть идентичны между загрузками страницы. Перезапустите браузер с тем же профилем и проверьте снова.

3. Сайты тестирования fingerprint: Посетите сервисы тестирования fingerprint браузера и проверьте раздел WebRTC. Сообщаемые кодеки не должны показывать аномалий.

Лучшие практики

1. Всегда используйте полный профиль. Возможности кодеков WebRTC должны соответствовать операционной системе, версии браузера и конфигурации GPU профиля. Профили BotBrowser захвачены с реальных устройств, что обеспечивает внутреннюю согласованность всех этих параметров. Не смешивайте компоненты профилей.

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

3. Сочетайте с защитой IP WebRTC. Fingerprinting кодеков и утечка IP - это отдельные проблемы конфиденциальности WebRTC, но обе требуют решения. Используйте интеграцию прокси BotBrowser с --proxy-server и --bot-webrtc-ice, чтобы контролировать и ваши IP-адреса WebRTC. Подробности в руководстве по предотвращению утечек WebRTC.

4. Не изменяйте настройки кодеков вручную. Позвольте профилю полностью управлять конфигурацией кодеков. Ручное добавление или удаление кодеков через флаги Chrome или переопределения конфигурации может создать несогласованности, подрывающие целостность профиля.

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

6. Проверяйте кроссплатформенную согласованность. Если вы используете один и тот же профиль на разных хост-ОС (например, запускаете профиль Windows и на хосте macOS, и на хосте Linux), убедитесь, что возможности кодеков WebRTC идентичны на обоих хостах. Подход BotBrowser на основе профилей должен давать одинаковый результат независимо от хоста, но проверка дает уверенность.

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

Часто задаваемые вопросы

Что такое fingerprinting кодеков WebRTC?

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

Чем это отличается от общего fingerprinting медиакодеков?

Общий fingerprinting медиакодеков использует API вроде canPlayType() и MediaCapabilities. Fingerprinting кодеков WebRTC использует специфичные для WebRTC API: RTCRtpSender.getCapabilities(), RTCRtpReceiver.getCapabilities() и SDP-предложения от createOffer(). Набор кодеков WebRTC не идентичен общему набору медиакодеков, поскольку WebRTC имеет свой собственный список поддерживаемых кодеков, отражающий требования коммуникации в реальном времени. Подход BotBrowser на основе профилей согласованно покрывает обе поверхности. О защите общих медиакодеков читайте в статье о fingerprinting MIME-типов и кодеков.

Может ли сайт запросить кодеки WebRTC без совершения звонка?

Да. Реальное соединение WebRTC не требуется. RTCRtpSender.getCapabilities('video') - это статический метод, который немедленно возвращает информацию о кодеках. Аналогично, createOffer() генерирует документ SDP без подключения к удаленному узлу. Обе операции быстрые, бесшумные и не требуют взаимодействия с пользователем или разрешений.

BotBrowser отключает какие-либо кодеки?

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

Что произойдет, если профиль содержит кодек, который моя система не поддерживает?

BotBrowser корректно обрабатывает эту ситуацию. API, видимые для JavaScript, сообщают список кодеков профиля, поддерживая правильный fingerprint. Когда происходит фактическое согласование медиа WebRTC, браузер внутренне использует только те кодеки, которые может обработать хост-система. Если кодек профиля недоступен локально, он исключается из внутренней обработки без влияния на представление fingerprint. Это предотвращает сбои и гарантирует работоспособность звонков.

Защищает ли это и аудиокодеки тоже?

Да. Формирование кодеков на основе профиля BotBrowser применяется как к видео, так и к аудиовозможностям. Список аудиокодеков из getCapabilities('audio') и аудио payload types в SDP-предложениях также формируются из данных профиля.

Как BotBrowser обрабатывает порядок кодеков?

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

Работает ли это в headless-режиме?

Да. Возможности кодеков WebRTC доступны в headless-режиме, и формирование кодеков на основе профиля BotBrowser работает идентично независимо от того, запущен ли браузер в headless-режиме или с видимым окном.

Могу ли я проверить защиту без реального звонка WebRTC?

Да. Вы можете проверить, вызвав RTCRtpSender.getCapabilities('video') и createOffer() в JavaScript-консоли страницы или через автоматизацию Playwright/Puppeteer. Подключение между узлами или удаленный сервер не требуются. Примеры кода в разделе Конфигурация и использование демонстрируют это.

Итоги

Перечисление кодеков WebRTC через getCapabilities() и SDP-предложения раскрывает медиавозможности, которые различаются между операционными системами, делая список кодеков потенциальным сигналом для отслеживания. BotBrowser решает это на уровне движка, формируя возможности кодеков WebRTC полностью из загруженного профиля fingerprint. Каждый API, раскрывающий информацию о кодеках, от getCapabilities() до генерации SDP createOffer(), возвращает результаты, согласованные с профилем. Двухуровневое разделение между видимым для JavaScript списком кодеков и внутренне зарегистрированными декодерами гарантирует, что ваш fingerprint соответствует целевой платформе, в то время как реальная функциональность WebRTC продолжает работать.

В сочетании с предотвращением утечек IP WebRTC, защитой MIME-типов и кодеков, кроссплатформенными профилями браузера и комплексной проверкой fingerprint, BotBrowser обеспечивает всесторонний контроль над каждым сигналом WebRTC, который может раскрыть идентичность вашей платформы.