Контейнерные вкладки и слежка: что не скрывает изоляция cookie

Firefox встраивает контейнерные вкладки прямо в браузер — функция, которая раньше требовала расширения Multi-Account Containers, становится встроенной возможностью. Это подходящий момент, чтобы точно разобраться, что контейнер делает на самом деле, потому что мысленная модель, которой пользуется большинство людей, ошибочна — причём ошибочна там, где это важно: контейнер — это отдельная банка для cookie, а не отдельный браузер. Всё дальнейшее строится вокруг этого единственного различия — читатель, который думает иначе, будет доверять контейнерам то, для чего они никогда не предназначались.

Ключевые выводы

• Контейнер — это отдельная банка для cookie, а не отдельный экземпляр браузера. Справочник MDN по contextualIdentities говорит об этом прямо: «каждая идентичность получает собственное хранилище cookie, не разделяемое с другими вкладками». В Firefox это разделение распространяется и на остальное хранилище сайта.
• Всё, что лежит ниже уровня хранилища, — общее: ваш IP-адрес, TLS/HTTP/2-рукопожатие, вывод canvas/WebGL/аудио, установленные шрифты, параметры экрана и часовой пояс одинаковы во всех контейнерах одного и того же браузера.
• Трекер, работающий по отпечатку, видит одного посетителя, а не двух — два контейнера, которые выглядят отдельными идентичностями для сайта, читающего cookie, могут схлопнуться обратно в единый профиль в тот момент, когда сайт начинает снимать отпечаток вместо того, чтобы полагаться на хранилище.
• Контейнеры действительно останавливают межсайтовую идентификацию, завязанную на cookie: зондирование состояния входа и трекинг через редиректы, которые зависят от общей банки cookie, не переживают разделения на изолированные банки.
• Они — часть небольшого семейства моделей изоляции: приватные окна, отдельные профили браузера и VPN изолируют каждый свой слой, и путаница в том, какой именно слой покрывает конкретный инструмент, — самый частый способ переоценить собственную защиту.

Что контейнер разделяет на самом деле

Функция контекстных идентичностей в Firefox — механизм, лежащий в основе Multi-Account Containers, а теперь и встроенных контейнеров, — присваивает каждой вкладке идентичность контейнера и привязывает хранилище сайта к этой идентичности. Справочник MDN по API contextualIdentities точен насчёт хранилища: «Внутри каждая идентичность получает собственное хранилище cookie, не разделяемое с другими вкладками», и адресуется оно через cookieStoreId. В Firefox идентификатор контейнера входит в атрибуты источника (origin attributes), которые прикрепляются к запросам к хранилищу, — поэтому на практике разделяются не только cookie: localStorage, IndexedDB и остальное хранилище сайта тоже попадают в разные корзины для разных контейнеров.

Откройте один и тот же сайт в контейнере «Работа» и в контейнере «Личное» — и сайт увидит два совершенно раздельных хранилища: ни одна cookie, установленная в одном, не просочится в другое, а сессия входа, начатая в одном контейнере, не перейдёт в другой.

Это стоит чётко отделять от другого механизма: Firefox разделяет состояние ещё и по совершенно иной оси. Руководство MDN по разделению состояния (State Partitioning) описывает, как браузер «использует двойной ключ для всего состояния на стороне клиента — источник загружаемого ресурса и сайт верхнего уровня». Это охватывает и API хранилища (localStorage, sessionStorage, IndexedDB, Service Workers), и сетевое состояние (HTTP-кеш, кеш изображений, DNS, идентификаторы TLS-сессий, HSTS). То руководство — про межсайтовую изоляцию, ключом в которой служит сайт в адресной строке; о контейнерах там не сказано ничего. В Firefox оба механизма работают одновременно, и ни один не заменяет другой: один мешает трекеру ходить за вами с сайта на сайт, второй — вашим собственным идентичностям видеть друг друга.

Но по какой бы оси ни шло разделение, оба механизма заканчиваются на уровне хранилища. Это реальные, полезные границы — и это вся граница целиком. Ни одна из них не затрагивает то, что браузер раскрывает об устройстве или сети, на которых он работает.

Что остаётся одинаковым во всех контейнерах

Это та часть, на которой анонс Firefox не задерживается, — и та, которую читатель скорее всего заполнит неверным предположением. Разделение по контейнерам работает целиком на уровне хранилища. Любой сигнал, который возникает из того, как ведут себя ваш браузер и соединение, а не из того, что сохранил сайт, остаётся нетронутым:

• Ваш IP-адрес и сетевой маршрут — контейнер не маршрутизирует трафик иначе и не меняет то, откуда сервер видит ваше соединение.
• Характеристики TLS- и HTTP/2-рукопожатия — один и тот же порядок и параметры согласования уходят независимо от того, какой контейнер инициировал запрос.
• Вывод Canvas, WebGL и аудио — один и тот же GPU рендерит одни и те же пиксели, а один и тот же аудиоконтекст выдаёт одну и ту же волну в каждом контейнере, потому что под капотом — одно и то же железо и один и тот же стек драйверов.
• Установленные шрифты и геометрия экрана — читаются напрямую из ОС и с дисплея, а не из чего-либо, чью область видимости контейнер мог бы ограничить.
• Часовой пояс и локаль — сообщаются напрямую из настроек ОС, одинаковы в каждой вкладке.

Сложите эти сигналы вместе — и вы получите отпечаток браузера, а отпечатку совершенно всё равно, какой контейнер отправил запрос. Если сайт идентифицирует посетителей по отпечатку, а не по чтению cookie, два контейнера на одной машине дают один и тот же отпечаток и схлопываются в единую отслеживаемую идентичность, как бы тщательно вы ни разделяли их банки cookie. Наша статья про энтропию отпечатка и множества анонимности разбирает, как мало таких сигналов на самом деле нужно, чтобы уникально идентифицировать устройство даже без единой cookie. Хотите увидеть это своими глазами, а не поверить на слово? Откройте одну и ту же страницу в двух разных контейнерах и запустите в каждом проверку отпечатка от BrowserInsight — итоговый хеш совпадёт. Если не совпал, дело не в границе контейнера, а во включённом режиме защиты от отпечатков, который добавляет шум к сигналам вроде canvas отдельно для каждого сайта.

Контейнеры на фоне других моделей изоляции

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

Если пройтись по этой таблице, закономерность очевидна: ни один инструмент сам по себе не покрывает больше одной строки. Контейнер вместе с VPN закрывает сразу два по-настоящему разных слоя — и это гораздо ближе к тому, что люди по умолчанию воображают под одними лишь «контейнерными вкладками».

Где контейнеры реально работают

Ничего из этого не делает контейнеры бесполезными — это лишь точно очерчивает, где именно их реальная польза. Контейнеры эффективны именно против трекинга, который зависит от общей банки cookie, — и такая категория трекинга вполне реальна.

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

Bounce tracking ломается по той же структурной причине. Во время редиректа он на мгновение делает домен трекера доменом первой стороны (first-party) — именно для того, чтобы установить или прочитать идентификатор на основе cookie. Но этот идентификатор и есть то самое привязанное к контейнеру хранилище, которое контекстная идентичность держит раздельно, так что связать визит в одном контейнере с визитом в другом не выйдет. В обоих случаях разделение ваших идентичностей на отдельные банки cookie убирает тот самый механизм, от которого зависит трекинг.

Что всё же просачивается сквозь границу контейнера

Трекинг на основе cookie — не единственный вид хранилища, на который может опираться сайт, и не всё, что сохраняет состояние, ограничено той же областью, что и cookie. ETag и кеш-суперкуки прячут идентификатор в обычных заголовках ревалидации HTTP-кеша, а не в хранилище cookie.

И здесь два описанных выше механизма тянут в разные стороны. HTTP-кеш входит в тот список сетевого состояния, которое, по руководству о разделении состояния, Firefox навсегда привязывает к сайту верхнего уровня, — а значит, межсайтовая версия этого трюка закрыта независимо от контейнеров. Чего ни одна из двух страниц MDN не утверждает — так это хоть чего-нибудь про версию межконтейнерную: как конкретный браузер конкретной версии разграничивает HTTP-кеш по контекстным идентичностям, попросту не зафиксировано в документации так, как зафиксировано разделение cookie. Безопасное допущение таково: граница контейнера доказана для cookie и для того хранилища, которое описывает MDN, и не доказана для всего остального, пока вы сами не проверили это в том браузере, которым реально пользуетесь.

Контейнеры — инструмент разделения, а не анонимности

Честный вывод — тот, который анонс Firefox оставляет невысказанным: контейнеры держат ваши идентичности раздельно друг от друга на одном устройстве — рабочий вход, который никогда не видит cookie личного входа, сессия покупок, которая не переносит состояние рекламного ретаргетинга в несвязанную вкладку. Это разделение на отсеки, и оно по-настоящему полезно именно для этой цели.

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

Часто задаваемые вопросы

Скрывают ли контейнерные вкладки мой отпечаток?

Нет. Контейнерные вкладки разделяют cookie и привязанное к сайту хранилище по контекстной идентичности; они никак не влияют на ваш IP-адрес, TLS-рукопожатие, вывод canvas/WebGL, шрифты, параметры экрана или часовой пояс. Всё это одинаково во всех контейнерах одного браузера — а именно из этого и складывается отпечаток.

Может ли сайт понять, что я использую контейнеры?

Никакого доступного странице API, который бы об этом сообщал, нет: contextualIdentities — это API для расширений (WebExtensions), сайтам он недоступен. Сайт видит следствие — пустую банку cookie, — а выглядит это ровно так же, как посетитель, который почистил cookie. Загвоздка в том, что «пустое хранилище при знакомом отпечатке» — тоже своего рода закономерность. Именно поэтому контейнеры спроектированы так, чтобы контейнеры нельзя было связать друг с другом через хранилище, а вовсе не так, чтобы скрыть само существование этой функции.

Меняет ли то, что Firefox сделал контейнеры встроенной функцией, их изоляцию?

Нет. Встроенные контейнеры в Firefox 153 переносят функциональность Multi-Account Containers прямо в браузер, но лежащий в основе механизм — то же самое разделение хранилища по контекстной идентичности, которое всегда описывал contextualIdentities, — не меняется. Граница изоляции в обоих случаях та же самая, что описана в этой статье.

Контейнеры — это то же самое, что приватные окна / инкогнито?

Нет. Приватное окно использует одну временную банку хранилища, которая очищается при закрытии окна; контейнеры дают вам несколько постоянных банок хранилища, работающих параллельно и отдельно друг от друга. У приватных окон есть и собственные особенности обнаруживаемости — см. как сайты обнаруживают режим инкогнито — которые к контейнерам вообще не применимы.

Нужен ли мне VPN, если я уже использую контейнеры?

Они решают разные задачи. Контейнеры разделяют ваши идентичности друг от друга на одном устройстве за счёт изоляции хранилища; VPN меняет то, какой сетевой маршрут и IP видит сервер, — контейнеры этого вообще не затрагивают. Ни один из них не заменяет другой — сетевую половину, которую контейнеры покрыть не могут, смотрите в проверке VPN и прокси от BrowserInsight.

Рекомендуем почитать

• Согласованность отпечатка: несовпадения сигналов вас выдают
• Энтропия отпечатка браузера и множество анонимности
• Как сайты обнаруживают режим инкогнито и приватный просмотр
• Определение входа: как сайты узнают, где вы авторизованы
• Bounce Tracking: как редиректы следят за вами без cookie
• ETag и кеш-суперкуки: слежка без cookie
• Угрозы приватности от расширений браузера