Поля отчёта BrowserLeaks WebRTC

Тест WebRTC на BrowserLeaks показывает несколько независимых наблюдений: наличие интерфейсов, собранные ICE-кандидаты, описание сеанса и состояние мультимедийных устройств. BotBrowser документирует управление ICE и мультимедийными устройствами, но не гарантирует, что эта страница проверяет настройки или выводы BotBrowser. Ни одна строка также не доказывает личность, анонимность или универсальную утечку. Чтобы читать результат точно, нужно связать каждую строку с породившей её операцией и не смешивать данные разных ветвей.

Кратко

Публичная страница BrowserLeaks показывает проверки интерфейсов, результат сбора ICE, журнал SDP и сведения о медиоустройствах. Скрипт страницы с указанной в URL версией создаёт RTCPeerConnection, запрашивает offer, слушает события кандидатов и отдельно запрашивает сведения об устройствах и разрешениях. Адрес кандидата, флаг поддержки, состояние разрешения или строка устройства относятся к конкретной операции в конкретном контексте; это не полное описание сетевого маршрута и не идентификатор человека.

Содержание

• В отчёте несколько ветвей, а не один балл
• Поддержка интерфейса и независимый сбор кандидатов
• Метки кандидатов являются проекцией собранных данных
• Журнал SDP не является записью пакетов
• Медиоустройства, разрешения и захват разделены
• Таблица полей и операций
• Чего отчёт не доказывает
• Практический вывод

В отчёте несколько ветвей, а не один балл

Страница WebRTC BrowserLeaks содержит отдельные разделы, а не единую числовую оценку. Среди видимых заголовков есть поддержка WebRTC, поля локального и публичного IP-адреса, описание сеанса и медиоустройства. На странице также есть отдельные кнопки для запроса разрешения на аудио- или видеозахват. Такая структура важна: каждый раздел заполняется отдельной операцией браузера, и значение в одном разделе не означает, что остальные операции тоже завершились успешно.

Страница загружает публичный клиентский скрипт, URL которого сейчас содержит токен версии 86970852. Этот скрипт позволяет описать поведение страницы, но не является стандартом WebRTC или проверенным репозиторием исходного кода. В следующей версии могут измениться поля, тайм-ауты или правила разбора. Поэтому видимый HTML и скрипт отвечают только на ограниченный вопрос: какие операции эта полученная версия страницы просит выполнить браузер и куда помещает результаты. Они не доказывают поведение всех браузеров, сетей, расширений или будущих версий BrowserLeaks.

Этот материал отличается от документации BotBrowser по предотвращению WebRTC-утечек, где описаны настройки ICE и SDP, и от документации о медиоустройствах, где объясняется перечисление устройств из профиля. Здесь рассматривается сам отчёт BrowserLeaks. Отдельный разбор полей WebRTC в CreepJS прослеживает преобразования другого сборщика; его имена полей и ветви нельзя переносить на BrowserLeaks.

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

Поддержка интерфейса и независимый сбор кандидатов

На публичной странице есть две строки поддержки: RTCPeerConnection и RTCDataChannel. В скрипте с версией страницы вспомогательная функция конструктора пробует стандартное и префиксные имена как в контексте страницы, так и в изолированном iframe. Затем проверяется, есть ли у полученного объекта метод createDataChannel. Это проверки наличия интерфейса. Они не создают сетевой маршрут, не подтверждают завершение ICE и не показывают, что удалённый пир получил данные.

Сбор кандидатов идёт по отдельной ветви. Скрипт создаёт peer connection с публичным STUN-сервером Google stun:stun.l.google.com:19302, создаёт канал данных, если метод доступен, и запрашивает offer. Offer просит принимать аудио и видео; если такой вариант не срабатывает, скрипт пробует более простой. Когда браузер принимает offer локально, скрипт задаёт его как локальное описание и обрабатывает события кандидатов. Эти вызовы объясняют, почему страница может показать данные кандидатов без запуска звонка в приложении, но они не проверяют каждое приложение, настройки TURN или соединения между пирами.

Скрипт собирает значения как из события icecandidate, так и из строк с формой кандидата в localDescription.sdp. Распознанные адресные строки удаляются из повторов; затем скрипт ждёт завершения сбора или ветви тайм-аута, помещает текст SDP в видимый журнал и закрывает peer connection. Поток событий и представление SDP являются связанными видами одной переговорной сессии, а не двумя независимыми сетевыми проверками. Повторяющееся значение нельзя считать двумя интерфейсами или двумя утечками.

API браузера определяет роль RTCPeerConnection и ICE-обмена; страница выбирает вызовы и выводимые значения. Спецификация W3C WebRTC и справка MDN по RTCPeerConnection описывают контракт интерфейса. Выборы самого теста, включая STUN-сервер, запасной offer, тайм-аут сбора и текстовые метки, задаёт скрипт BrowserLeaks. Описание события-кандидата в стандарте не подтверждает классификацию или вывод отчёта.

Метки кандидатов являются проекцией собранных данных

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

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

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

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

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

Журнал SDP не является записью пакетов

Раздел Session Description содержит журнал SDP из localDescription.sdp. SDP представляет собой текстовое описание, используемое при согласовании. В нём могут быть разделы медиа, атрибуты кодеков, параметры ICE и строки кандидатов; конкретный состав зависит от того, что создал браузер и что успело собраться к моменту чтения отчётом. Это не запись переданных по сети пакетов и не подтверждение того, что удалённая сторона получила, приняла или использовала каждую строку.

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

Журнал не показывает все свойства реального вызова приложения. Страница создаёт собственные peer connection, offer и настройки ICE. Приложение видеоконференций может использовать другой SDP offer, другие ICE-серверы, политику ретрансляции, иной жизненный цикл вызова или другой контекст источника и разрешений. Результат BrowserLeaks нельзя переносить на такие условия без свидетельств из самого пути приложения.

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

Медиоустройства, разрешения и захват разделены

Раздел Media Devices относится к другой ветви, не к сбору ICE-кандидатов. Клиентский скрипт проверяет наличие navigator.mediaDevices.enumerateDevices() и вызывает его, если метод доступен. Для каждой записи MediaDeviceInfo форматируются kind, label, deviceId и groupId. Отдельно отмечается, есть ли непустые метки у аудио- и видеовходов. Число и метки строк могут различаться в зависимости от контекста, разрешений, политик и реализации; этот список не является инвентарём оборудования.

Страница также запрашивает состояния разрешений микрофона и камеры через navigator.permissions.query(), если API и имя разрешения поддерживаются. Эти значения показываются отдельно от строк устройств. Поддержка проверки разрешения может отличаться, а отклонённый или неподдерживаемый запрос не равен отказанному разрешению. Состояние prompt не является разрешением на захват. Пустая метка не доказывает отсутствие устройства; причиной могут быть правила раскрытия данных или текущее разрешение.

Захват аудио и видео выполняется отдельными явными действиями. Кнопки страницы вызывают getUserMedia() с запросом только аудио или только видео. Скрипт обновляет соответствующую область по результату promise. Перечисление устройств само не открывает микрофон или камеру; состояние разрешения не доказывает, что получится полезный поток. И наоборот, успешный захват одного типа не означает, что другой тип разрешён или доступен.

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

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

Таблица полей и операций

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

Видимое поле	Операция страницы	Что подтверждает поле	Чего оно не доказывает
RTCPeerConnection	Поиск конструктора на странице и в изолированном iframe	Был ли найден поддерживаемый конструктор в этом контексте	Что сбор завершился или соединение достигло другого хоста
RTCDataChannel	Проверка createDataChannel у созданного объекта	Доступен ли метод у этого объекта	Был ли открыт канал данных с удалённым пиром
Local IP Address / Public IP Address	Разбор кандидатов и SDP, удаление повторов и группировка по локальным диапазонам	Какие разобранные строки отчёт поместил в каждую группу	Полный список интерфейсов, маршрут, физическую личность или универсальный вердикт об утечке
SDP Log	Чтение localDescription.sdp после offer	Текст локального описания этой страницы	Запись пакетов, удалённый ответ или успешный обмен медиа
API Support в Media Devices	Проверка enumerateDevices()	Есть ли метод перед перечислением	Существует ли устройство и можно ли его открыть
Строки устройств	Форматирование результата enumerateDevices()	Возвращённые kind, label, deviceId и groupId	Всё оборудование хоста или постоянную идентичность устройства
Разрешение аудио/видео	permissions.query() для соответствующего имени	Состояние, возвращённое запросом	Выданный поток, единообразную поддержку или пригодное устройство
Захват аудио/видео	Запрос getUserMedia(), начатый пользователем	Разрешился или отклонился ли этот запрос в текущем контексте	Другой тип медиа, будущие разрешения или качество удалённого вызова

При составлении резюме строки должны оставаться независимыми. Например, RTCPeerConnection: True, отсутствие видимого адреса и enumerateDevices(): True могут существовать одновременно: это наличие интерфейса, путь анализа без выведенного значения и отдельный API медиа. Запись, которая превращает всё это в одно «прошёл» или «не прошёл», скрывает, какая операция породила наблюдение.

Чего отчёт не доказывает

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

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

Отчёт также не устанавливает, что браузер «проходит» антибот-проверку. BrowserLeaks является публичной диагностической страницей, а не универсальным стандартом решений об автоматизированном трафике. Поле может собираться для диагностики или прозрачности, не будучи сигналом какого-либо конкретного сервиса. Из одного отчёта не следует решение поставщика, результат challenge или вероятность принятия.

Наконец, результат зависит от времени и контекста. Версия браузера, разрешения источника, сетевой маршрут, доступность STUN, политики, расширения и изменения скрипта могут изменить видимый результат. Токен версии в URL указывает на ресурс, полученный при проверке; он не гарантирует, что в каждой будущей загрузке будет тот же код. Публичную страницу лучше цитировать с датой получения и названием прочитанного раздела, а не считать неизменной спецификацией.

Вопросы

Тест WebRTC BrowserLeaks всегда показывает публичный адрес?

Нет. Страница выводит разобранный адрес, если операция получила распознаваемый анализатором текст кандидата или SDP и дошла до ветви отображения. У пустого результата может быть несколько причин; он не доказывает отсутствие другого адреса или маршрута.

RTCPeerConnection: True доказывает, что вызов WebRTC работает?

Нет. Это проверка поддержки. Сбор кандидатов, ICE-связность, удалённые переговоры и передача медиа являются следующими этапами. Строка поддержки не означает завершённый вызов с другим пиром.

Список устройств означает, что микрофон активен?

Нет. enumerateDevices() возвращает отфильтрованный браузером список. Кнопки захвата страницы отдельно вызывают getUserMedia(), запросы могут завершиться по-разному. Строка устройства не доказывает, что захват начался.

Является ли страница BrowserLeaks детектором с открытым исходным кодом?

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

Результат говорит, обнаружим ли браузер?

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

Источники

• BrowserLeaks WebRTC Leak Test и его клиентский скрипт версии страницы.
• W3C WebRTC 1.0 и справка MDN по RTCPeerConnection.
• MDN MediaDevices.enumerateDevices() и MediaDevices.getUserMedia().
• Предотвращение WebRTC-утечек BotBrowser и Приватность медиоустройств.

Практический вывод

Читайте страницу WebRTC BrowserLeaks как набор независимых результатов. Связывайте флаги поддержки с проверками конструкторов, группы адресов с разбором кандидатов и SDP, журнал с локальным описанием, строки устройств с перечислением, метки разрешений с запросами, а результаты захвата с явными вызовами getUserMedia(). Отчёт даёт полезный взгляд на эти операции в контексте собственной страницы. Он не превращает их в личность, гарантию анонимности, универсальный вердикт об утечке или предсказание решения антибот-сервиса.