[Браузеры] Как работает приватная сеть доставки контента Brave (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В Brave приватность — не фича, а требование, вокруг которого построен проект. Наш браузер это демонстрирует в полной мере: мы блокируем трекеры, не даем отслеживать цифровые отпечатки и предлагаем пользователям наш собственный, privacy-first рекламный сервиc. В сегодняшнем выпуске рассмотрим метод сокрытия IP-адресов пользователей от нас и партнёрской CDN, а также прочие вопросы приватности браузерной рекомендательной ленты Brave Today.Известно, что в процессе работы Brave передаёт минимум информации на наши сервера, и только когда это нужно. Но этого мало - чтобы делать воистину правильные вещи, следует задаться целью сделать принципиально невозможным причинение вреда пользовательской приватности. Как не раскрыть IP-адреса пользователей браузера? В общем случае, мы отфильтровываем их из запросов к нашим бэкендам на уровне сети доставки контента (также известной как CDN), чтобы адрес даже случайно не мог попасть в логи. Но для одного из наших новых сервисов мы хотим шагнуть дальше - убедиться, что никакое изменение конфигурации CDN не могло бы засветить IP-адреса клиентов, даже если бы нам этого захотелось.Опишем по пунктам, что и зачем мы делаем.НачалоНовые фичи браузера требуют, чтобы IP-адреса клиентов охранялись лучше, чем мы это делали раньше. Одна из таких фич — наша новостная рекомендательная лента Brave Today на браузерном новом табе.Просто доставлять новости можно и через обычную сеть доставки контента: сами новости для всех пользователей одинаковые, а конкретная выборка и машинное обучение происходит локально в самом браузере. Нюансы есть в иллюстрациях к новостям. Если cкачивать картинки в процессе просмотра ленты, любой, кто может наблюдать эти сетевые запросы (например, CDN), может узнать, какие статьи демонстрировались в ленте. Из этих фактов можно извлечь информацию о том, какую модель использует машинное обучение на клиенте, и косвенно о том, какие страницы ранее посещались для тренировки этой модели.КонструкцияТрадиционно, контент сервисов, чувствительных к задержкам, доставляется и кэшируется при помощи CDN. Очевидно, что оператор CDN видит и содержимое пользовательских запросов, и его IP-адрес. В нашем случае (см. Приватность) эти потоки данных следует разделить. Мы решили добавить балансировщик нагрузки перед CDN. В результате получилось следующее:
В такой модели, вендор балансировщика не видит содержимого запросов или ответов. Все, что ему доступно — зашифрованный трафик на 443 порту, расшифровать который может только сеть доставки контента. При этом вендору CDN доступно все, что внутри запросов и ответов, но вместо IP-адреса пользователя они получают один из адресов балансировщика нагрузки. А чтобы никакие посторонние IP-адреса не подключились сбоку к CDN, она устанавливает соединения только с IP-адресами балансировщика. Подобно этому, контейнер S3, из которого сеть берет данные, отдаёт данные только по ключу, который есть у CDN.Важно также использовать разных вендоров балансировщика и для CDN, что мы и делаем. Это нужно, чтобы минимизировать теоретический риск их сговора для деанонимизации клиентов.We need to go deeperОчевидно, что балансировщик нагрузки TCP не может расшифровать идущий через него трафик. Но он может отслеживать размеры HTTP запросов и ответов, что является вектором атаки на эти данные. У нас нет причин подозревать, что наши партнёры-вендоры будут пытаться следить за пользователями, но подобные верования неуместны, когда существуют технические решения: мы добавляем паддинг к запросам, чтобы сделать их размеры максимально похожими.Например, сервис запрашивает изображения:/article/12/image/3927.png/article/8/image/148.jpgЭти запросы можно изменить так:/article/0012/image/03927.png/article/0008/image/00148.jpgЧто касается HTTP-ответов, приводить все файлы к единому объему может быть затратно, но можно задать несколько типоразмеров и подбирать нужный. Этим должно заниматься каждое приложение, использующее CDN для своих конкретных запросов. Ясно дело, что для правильной работы этого алгоритма нужно отключить сжатие на стороне CDN.Даже при том, что IP-адрес пользователя не попадает в CDN ни в каком виде, некоторые HTTP-заголовки могут использоваться для фингерпринтинга — в зависимости от степени уникальности их значений. Поэтому каждое приложение, которое использует нашу приватную сеть доставки контента, должно вычищать такие заголовки из запросов. Это:
- Accept-Language
- Cookie
- DNT
- Referer
- User-Agent
А что там в браузере?Всё, о чем говорилось до сего момента, больше относится к вендорам нашей инфраструктуры. Однако что насчет собственно компании Brave, ведь у нас-то есть доступ к дашбордам партнёров?Для того, чтобы идентифицировать пользователя по набору запросов, нам потребовалось бы:
- Иметь доступ к логам обеих систем,
- Добавлять к запросам дополнительную информацию, когда они направляются от балансировщика нагрузки TCP.
С логами все просто — по договору с вендором балансировщика у нашей учётки отключен доступ к механизмам логгирования. Добавлять информацию в заголовки мы тоже не можем, поскольку балансировщик нагрузки не может расшифровать TLS-поток. Теоретически, мы могли бы настроить его так, чтобы прокси-протокол дописывал IP-адрес клиента во все исходящие запросы, но, по счастью, наш CDN-провайдер этого в принципе не умеет делать. На случай, если такая возможность появится в будущем, в нашем контракте есть специальный пункт, который оговаривает это ограничение.Доверяй, но проверяйВажность тщательного проектирования такой системы неоспорима, но слова и схемы ничего не значат без возможности проверить наши утверждения. Чтобы оправдать доверие наших пользователей мы стараемся максимально прозрачно показывать нашу работу.Во-первых, каждый может посмотреть как данные обрабатываются на стороне клиента, так как Brave — браузер с открытым кодом. Во-вторых, легко проверить, к какому именно IP-адресу обращается браузер, проанализировав трафик, например, с помощью mitmproxy или просто посмотрев, во что резолвится хост pcdn.brave.com. Наконец, для проверки переадресации запросов от первого вендора и точки, где расшифровывается TLS, можно сравнить заголовки ответов отhttps://pcdn.brave.com/ и сайтов, которые обслуживаются непосредственно первым вендором — например,https://haveibeenpwned.com/.В маловероятном случае обнаружения любых багов или нарушений модели приватности немедленно сообщайте в нашу программу поиска багов
===========
Источник:
habr.com
===========
===========
Автор оригинала: François Marier и Ben Kero
===========Похожие новости:
- [Google Chrome, Расширения для браузеров, Браузеры, Разработка под Linux, Разработка под Windows] Google выпустила исправления для Chrome после сбоев на Windows 10 и Linux
- [Информационная безопасность, JavaScript, Браузеры] Кросс-браузерный трекинг на основе перебора обработчика внешних протоколов
- [Системное администрирование, Браузеры, Софт, IT-компании] Microsoft прекратит поддержку приложения Internet Explorer 11 в Windows 10 с июня 2022 года
- [Информационная безопасность, Браузеры, Софт, IT-компании] Firefox представил новую архитектуру безопасности браузера с изоляцией сайтов
- [Браузеры, Софт, IT-компании] Microsoft исправила баг в Edge, который приводил к падению браузера при просмотре YouTube
- [Разработка под iOS, Разработка мобильных приложений, API, Браузеры, IT-компании] Инженер Google раскритиковал Apple за торможение развития веб-технологий
- [Opera, *nix, Сетевые технологии, Браузеры, Софт] Открытые клиенты Hola VPN и Opera VPN
- [Браузеры] FLoC off: позиция Brave (перевод)
- [Google Chrome, Облачные вычисления, Браузеры, Облачные сервисы] Браузер Mighty рендерит веб-контент на стороне сервера, чтобы ускорить Chrome
- [Usability, Браузеры] Yandex Browser, стань портабельным! На линукс, плиз
Теги для поиска: #_brauzery (Браузеры), #_cdn, #_cdncervis (cdn-ceрвис), #_brave_brauzer (brave браузер), #_brauzery (браузеры), #_blog_kompanii_brave (
Блог компании Brave
), #_brauzery (
Браузеры
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:50
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В Brave приватность — не фича, а требование, вокруг которого построен проект. Наш браузер это демонстрирует в полной мере: мы блокируем трекеры, не даем отслеживать цифровые отпечатки и предлагаем пользователям наш собственный, privacy-first рекламный сервиc. В сегодняшнем выпуске рассмотрим метод сокрытия IP-адресов пользователей от нас и партнёрской CDN, а также прочие вопросы приватности браузерной рекомендательной ленты Brave Today.Известно, что в процессе работы Brave передаёт минимум информации на наши сервера, и только когда это нужно. Но этого мало - чтобы делать воистину правильные вещи, следует задаться целью сделать принципиально невозможным причинение вреда пользовательской приватности. Как не раскрыть IP-адреса пользователей браузера? В общем случае, мы отфильтровываем их из запросов к нашим бэкендам на уровне сети доставки контента (также известной как CDN), чтобы адрес даже случайно не мог попасть в логи. Но для одного из наших новых сервисов мы хотим шагнуть дальше - убедиться, что никакое изменение конфигурации CDN не могло бы засветить IP-адреса клиентов, даже если бы нам этого захотелось.Опишем по пунктам, что и зачем мы делаем.НачалоНовые фичи браузера требуют, чтобы IP-адреса клиентов охранялись лучше, чем мы это делали раньше. Одна из таких фич — наша новостная рекомендательная лента Brave Today на браузерном новом табе.Просто доставлять новости можно и через обычную сеть доставки контента: сами новости для всех пользователей одинаковые, а конкретная выборка и машинное обучение происходит локально в самом браузере. Нюансы есть в иллюстрациях к новостям. Если cкачивать картинки в процессе просмотра ленты, любой, кто может наблюдать эти сетевые запросы (например, CDN), может узнать, какие статьи демонстрировались в ленте. Из этих фактов можно извлечь информацию о том, какую модель использует машинное обучение на клиенте, и косвенно о том, какие страницы ранее посещались для тренировки этой модели.КонструкцияТрадиционно, контент сервисов, чувствительных к задержкам, доставляется и кэшируется при помощи CDN. Очевидно, что оператор CDN видит и содержимое пользовательских запросов, и его IP-адрес. В нашем случае (см. Приватность) эти потоки данных следует разделить. Мы решили добавить балансировщик нагрузки перед CDN. В результате получилось следующее:  В такой модели, вендор балансировщика не видит содержимого запросов или ответов. Все, что ему доступно — зашифрованный трафик на 443 порту, расшифровать который может только сеть доставки контента. При этом вендору CDN доступно все, что внутри запросов и ответов, но вместо IP-адреса пользователя они получают один из адресов балансировщика нагрузки. А чтобы никакие посторонние IP-адреса не подключились сбоку к CDN, она устанавливает соединения только с IP-адресами балансировщика. Подобно этому, контейнер S3, из которого сеть берет данные, отдаёт данные только по ключу, который есть у CDN.Важно также использовать разных вендоров балансировщика и для CDN, что мы и делаем. Это нужно, чтобы минимизировать теоретический риск их сговора для деанонимизации клиентов.We need to go deeperОчевидно, что балансировщик нагрузки TCP не может расшифровать идущий через него трафик. Но он может отслеживать размеры HTTP запросов и ответов, что является вектором атаки на эти данные. У нас нет причин подозревать, что наши партнёры-вендоры будут пытаться следить за пользователями, но подобные верования неуместны, когда существуют технические решения: мы добавляем паддинг к запросам, чтобы сделать их размеры максимально похожими.Например, сервис запрашивает изображения:/article/12/image/3927.png/article/8/image/148.jpgЭти запросы можно изменить так:/article/0012/image/03927.png/article/0008/image/00148.jpgЧто касается HTTP-ответов, приводить все файлы к единому объему может быть затратно, но можно задать несколько типоразмеров и подбирать нужный. Этим должно заниматься каждое приложение, использующее CDN для своих конкретных запросов. Ясно дело, что для правильной работы этого алгоритма нужно отключить сжатие на стороне CDN.Даже при том, что IP-адрес пользователя не попадает в CDN ни в каком виде, некоторые HTTP-заголовки могут использоваться для фингерпринтинга — в зависимости от степени уникальности их значений. Поэтому каждое приложение, которое использует нашу приватную сеть доставки контента, должно вычищать такие заголовки из запросов. Это:
=========== Источник: habr.com =========== =========== Автор оригинала: François Marier и Ben Kero ===========Похожие новости:
Блог компании Brave ), #_brauzery ( Браузеры ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:50
Часовой пояс: UTC + 5