В 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/.
В маловероятном случае обнаружения любых багов или нарушений модели приватности немедленно сообщайте в нашу программу поиска багов
