Кандидаты mDNS WebRTC и конфиденциальность локальной сети

WebRTC собирает ICE-кандидаты, чтобы пиры нашли путь связи. Host-кандидат может раскрыть локальный интерфейс, поэтому браузер способен использовать имя mDNS вместо частного адреса. RFC 8828 описывает это направление, но не обещает анонимность. BotBrowser повторяет авторизованный сценарий и наблюдает кандидаты и видимый статус; он не управляет удалённым пиром и его журналами.

Кратко

Считайте mDNS-имя частичным снижением раскрытия, а не доказательством отсутствия локальных данных. Записывайте отдельно версию браузера, ICE-политику, тип кандидата, итоговый origin и результат приложения. Используйте синтетические медиа и ограниченные таймеры. Не публикуйте адреса, ICE-секреты или записи звонков.

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

Содержание

• Что меняет mDNS
• Разделяйте свидетельства
• Ограниченный тест
• Типы кандидатов в контексте
• Проектирование сравнения
• Осторожная интерпретация
• Полезное хранение свидетельств
• Классификация сбоев и очистка
• Контрольный список
• Вывод

Что меняет mDNS

Host-кандидат описывает локальный интерфейс. При mDNS он содержит локальное имя, а не адрес. Reflexive-кандидат может показать публичное отображение, а relay-кандидат показывает выбранный relay. Поэтому список кандидатов не является полным отчётом о приватности.

Разделяйте свидетельства

Наблюдение	Записать	Не доказывает
Сигнализация	итоговый origin и HTTP-статус	доверие к пиру
ICE	тип, протокол и сокращённое mDNS-имя	анонимность или отсутствие логов
Соединение	выбранную пару и переход состояния	качество или стабильность
Приложение	свой маркер и тайм-аут	запись на сервере

Не превращайте mDNS-имя в инвентаризацию. Сокращайте SDP и секреты. Версия браузера или настройка TURN может изменить типы кандидатов без изменения приложения.

Ограниченный тест

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

Подробности проверки кандидатов

Типы кандидатов в контексте

Host-, reflexive- и relay-кандидаты отвечают на разные вопросы связности. Host описывает локальный интерфейс, reflexive показывает отображение через STUN, а relay использует TURN. Это не шкала приватности: видимость зависит от сигнализации, пира, relay и браузера. mDNS заменяет локальный адрес именем в представлении кандидата, но имя не становится стабильным идентификатором или инвентарём устройства.

Проектирование сравнения

Сначала сформулируйте узкий вопрос: «Показывает ли эта версия браузера host-кандидат mDNS моей собственной странице при неизменной конфигурации?». Сравните контрольную и кандидатную страницы, меняя только один объявленный параметр. Сохраните одинаковыми origin, маршрут, браузер, ICE-серверы, синтетические медиа и разрешения; записывайте только сокращённые категории, состояние и версию.

Поле	Контроль и кандидат	Зачем
Origin и маршрут	один собственный HTTPS-маршрут	одинаковый контекст безопасности
ICE и медиа	фиксированная синтетическая настройка	исключает смену STUN/TURN и реальные устройства
Наблюдение	сокращённая категория кандидата	не собирает адреса и секреты
Результат	состояние и категория пары	отделяет сбор от соединения

Осторожная интерпретация

Если строка содержит .local, сохраните только mdns-host, не само имя. Завершённый сбор не означает выбранную пару, а успешное соединение не показывает, что сохранили сервис или пир. Не выводите разрешение камеры из ICE. Причиной сбоя могут быть DNS, firewall, relay, неверное описание или проверка приложения.

Полезное хранение свидетельств

Короткая квитанция содержит вопрос, версию фикстуры, браузер, маршрут, ICE-настройку, категории кандидатов, итоговое состояние, категорию пары (если есть) и время. Отдельно укажите неизвестное: наблюдение пира, хранение сигнализации, реальное согласие и универсальность поведения. Не помещайте адреса, SDP, секреты, cookies и записи звонков в обычные отчёты; сырые данные требуют ограниченного хранилища и даты удаления.

Классификация сбоев и очистка

Назначьте владельца каждому сбою: навигация/origin, сигнализация, ICE-сбор, достижимость пира, relay/firewall или проверка приложения. Для каждого этапа задайте ограничение времени и сохраните место остановки. На успехе и ошибке закрывайте peer connection, синтетические дорожки и контекст, чтобы следующий запуск оставался независимым.

Контрольный список

• Страница и сигнализация принадлежат владельцу или явно авторизованы?
• Вопрос разделяет представление кандидата, связность, медиа и сервис?
• Объявлены браузер, origin, ICE и синтетические входы?
• Имена, адреса, секреты, SDP и медиа исключены из обычных логов?
• Каждый тайм-аут указывает этап и границы результата?
• Соединения и дорожки закрываются при успехе и ошибке?

Итог

Проверяйте origin, разрешение, ICE-политику, редактирование кандидатов, выбранный маршрут и видимый результат как одну цепочку. BotBrowser повторяет авторизованный путь в заявленном контексте; он не предоставляет устройство и не гарантирует универсальное соответствие RFC 8828.

Далее изучите руководство по предотвращению WebRTC-утечек и руководство UDP через SOCKS5. Результат относится только к заявленной версии, маршруту и настройке.

Источники

• RFC 8828
• W3C WebRTC
• MDN RTCPeerConnection
• MDN WebRTC connectivity
• BotBrowser защита от WebRTC-утечек

BotBrowser Team