Сетевая идентичность и конфиденциальность WebRTC

BotBrowser поддерживает контролируемые настройки сетевой идентичности WebRTC; он не делает соединения анонимными и не гарантирует приватность вне контекста.

Кратко

WebRTC собирает адреса, которых прокси для страниц не видит. Выберите один режим на контекст (profile, real или disabled) и запишите его. Изучайте ICE-кандидаты и записи getStats() для соединения WebRTC, а публичный адрес отдельно проверяйте через разрешённый внешний сервис. Это разные наблюдения.

Содержание

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

Почему WebRTC относится к политике конфиденциальности

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

Вопрос не в том, нужно ли удалять WebRTC. Для многих пользователей он необходим для общения. Важно понимать, какие адресные сведения API WebRTC раскрывают при выбранной политике контекста. Политика должна явно выбрать режим, объяснить компромисс и пересматривать наблюдения после смены маршрута.

BotBrowser предлагает три режима: profile, real и disabled. Они соответствуют политике настроенного профиля, сети хоста и недоступности WebRTC. В режиме profile настроенные средства управления SDP и ICE предназначены для согласования сетевых сведений WebRTC с объявленной идентичностью профиля; проверьте применимые условия прокси и UDP, не считая это намерение измерением публичного выхода. Выбор зависит от назначения контекста и от границы конфиденциальности, которую организация считает приемлемой.

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

Что может раскрыть браузер

При подготовке сеанса WebRTC браузер собирает возможные пути для передачи медиа. Кандидат несёт тип candidate: host для локального интерфейса, srflx для отражения на сервере, relay для адреса TURN, а также сам адрес (RFC 8445). Во время сеанса RTCPeerConnection.getStats() возвращает записи local-candidate, remote-candidate и candidate-pair; выбранная пара указывает путь, который в данный момент передаёт медиа (статистика WebRTC). Эти записи помогают сравнить наблюдаемый маршрут WebRTC с политикой контекста, но не измеряют отдельно публичный выход запросов страницы.

Адрес способен связать сеанс с сетью, регионом, организацией или домом. Частный адрес показывает форму локальной сети. Публичный адрес может обозначать выход хоста. Адрес ретранслятора может указывать на сервис или регион. Совокупность таких сведений способна создать устойчивую связь между сеансами. О том, как mDNS-кандидаты хоста меняют то, что страница может узнать о локальной сети, читайте в статье Кандидаты mDNS WebRTC и конфиденциальность локальной сети: в ней рассматриваются mDNS-кандидаты и цели приватности RFC 8828.

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

Нужно учитывать и доступность. Запрет всей связи уменьшает поверхность раскрытия, но может сломать встречи, поддержку и совместную работу. Сначала определите назначение контекста, затем выберите режим и объясните оставшуюся область видимости.

Три режима

profile: проверить политику идентичности

profile задаёт политику сети контекста, с которой можно сопоставить записи кандидатов и статистики. Если SOCKS5-прокси поддерживает UDP ASSOCIATE и BotBrowser устанавливает ассоциацию, STUN может идти через этот прокси, а ICE-кандидаты могут отражать его адрес. Выбранная пара кандидатов описывает медиамаршрут WebRTC, а не отдельное измерение публичного выхода запросов страницы. Организации следует документировать маршрут каждого контекста и сверять с ним оба наблюдения.

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

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

real: использовать сеть хоста

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

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

real также может применяться в разрешённом сеансе поиска причины соединительной проблемы. Такой сеанс должен иметь ответственного, ограниченный срок и запись о намеренном использовании идентичности хоста.

disabled: убрать ненужную возможность

disabled подходит рабочему процессу без связи в реальном времени. Он уменьшает сведения, доступные странице, но убирает звонки, передачу медиа и другие функции, зависящие от WebRTC.

Это должно быть явным продуктовым решением, а не случайным результатом неисправной среды. Пользователь должен понимать, почему встреча не запускается. Если связь снова потребуется, следует перейти в документированный контекст с profile или real.

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

Как интерпретировать записи кандидатов и статистики

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

Сравнение помогает проверить политику, но не обещает совпадения двух представлений API. В режиме profile изучите кандидатов и выбранную пару, затем сопоставьте их с маршрутом контекста. В режиме real трактуйте раскрытые адреса как сведения сети хоста. В режиме disabled проверьте недоступность WebRTC. Результат помогает провести проверку, но не гарантирует конкретный адрес или маршрут.

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

Режим	Типы ICE-кандидатов	Представление getStats()	Когда выбирать
profile	Следуют загруженному профилю	Проверяйте выбранные записи кандидатов и пар	Звонки должны работать под заявленной идентичностью
real	Адреса интерфейсов хоста (host, srflx)	Проверяйте записи кандидатов и пар хоста	Маршрут хоста и есть нужная идентичность
disabled	Кандидатов WebRTC нет	Транспорт WebRTC недоступен	Рабочему процессу не нужны медиа в реальном времени

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

Назначьте каждому рабочему процессу цель: связь, локальная разработка, внутренняя проверка или чувствительный к приватности просмотр. Запишите, нужен ли WebRTC. Выберите profile, real или disabled и укажите владельца маршрута.

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

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

Частые вопросы

Прокси автоматически защищает WebRTC?

Нет. Он может контролировать обычные запросы, тогда как WebRTC использует отдельный путь связи. Изучите отдельно ICE-кандидаты и статистику выбранной пары, затем сопоставьте их с политикой контекста; ни одно из этих представлений само по себе не измеряет публичный выход.

Каждый контекст должен использовать profile?

Нет. profile подходит, когда WebRTC нужен и сетевая идентичность определена. real может соответствовать рабочему процессу хоста, а disabled подходит процессу без связи. Режим должен следовать назначению.

disabled всегда даёт лучшую конфиденциальность?

Он уменьшает одну поверхность, но убирает и законную возможность браузера. Если звонок необходим, документированный контекст profile может быть разумнее неуправляемой альтернативы.

Зачем сравнивать кандидатов и статистику?

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

Что делать при смене сети?

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

Что хранить для проверки конфиденциальности?

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

Источники

• RFC 8445: Interactive Connectivity Establishment
• RFC 8828: требования к обработке IP-адресов в WebRTC
• Статистика WebRTC W3C
• W3C WebRTC 1.0

Практический итог

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

Запишите по одному режиму на контекст. Изучайте ICE-кандидаты и записи getStats() на разрешённой тестовой странице, а публичный адрес проверяйте через отдельный разрешённый внешний сервис. Считайте контекст real осознанным решением про сеть хоста, а контекст disabled - процессом, в котором API WebRTC недоступны. Повторяйте обе проверки после смены сети, ротации прокси или мажорного обновления браузера.