«Сторонние куки больше не нужны», — заявили разработчики Chrome и в январе 2024 года начали отключать их у каждого сотого пользователя браузера. Однако уже в июле последовало осторожное: «Ну, с другой стороны...» — и отмена кук была отменена.

Многие даже не заметили, что произошло. Но на самом деле речь шла о том, как должен работать интернет в целом: отказ затронул бы почти каждый сайт из тех, что ты посещаешь,%USERNAME%.

На связи Артём из команды Яндекс Браузера. В этой статье расскажу о том, как технологии, изначально созданные для упрощения жизни, со временем стали инструментом манипуляций, и о контрасте разных подходов к борьбе с этим. Поговорим о масштабных системных решениях и простых прикладных методах, сравним их эффективность, сложности внедрения и неожиданные подводные камни. И заодно разберёмся, почему проблема трекинга — это не только про сторонние куки.

Что такое сторонние куки и что с ними не так

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

Если куки установлены основным сайтом, это first‑party cookies. Если сторонним ресурсом — third‑party cookies.

На практике сторонние куки — это удобно. Например, вы заходите в блог, а там встроен виджет комментариев от соцсети, в которой вы уже авторизованы. Соцсеть узнаёт вас по сохранённым куки — и вы можете сразу писать комментарии без регистрации и СМС. Или если на сайте встроено видео с внешнего хостинга, то по куки показываются персональные кнопки, вроде «Смотреть позже».

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

Жалобы на такое поведение регулярно поступают: пользователи недоумевают, как их действия отслеживают с такой точностью. Бывает, что человек просто открыл сайт — без логина, без ввода данных, — а потом получает звонок: «Вам что‑то не понравилось при визите?» Посещение отследили, каким‑то образом сопоставили телефон — с этим точно надо что‑то делать.

Почему не так просто отказаться от сторонних куки

Все third‑party cookies взять и отменить — крайне амбициозное решение. Однако ящик Пандоры, который открывает это решение, полон нетривиальных вопросов и архитектурных компромиссов.

Допустим, сторонние куки запрещены. Но что делать, если куки технически сторонние — домен‑то другой, но фактически принадлежит той же организации. Например, github.com и githubassets.com. Или, скажем, yandex.ru и yandex.by. Просто заблокировать?

Google Chrome предлагает создать глобальный список родственных доменов. Его хостят на GitHub, а браузеры получают и используют. Теоретически это позволяет решать такие кейсы, но на практике масштабирование этого подхода вызывает вопросы. Сейчас в списке около тысячи записей, и он пока не разросся до неуправляемых размеров, но насколько он устойчив при широком применении — большой вопрос.

Другой пример: сайт A загружает сторонний ресурс B, который, в свою очередь, включает на своей странице обратно A. Выглядит как рекурсия, но с точки зрения правил блокировки возникает вопрос: теперь даже на сайте A куки для него самого запрещать? Подобные взаимозависимости учтены, куки в таких случаях разрешаются.

А что делать с «сайтами в сайтах»? Комментарии, видео, платёжные системы — все эти iframe‑виджеты жили за счёт сторонних кук. На этот случай существует явная модель разрешений: при взаимодействии пользователь даёт согласие, и только тогда iframe получает доступ к куки. Встраивайте специальное API, спрашивайте разрешение и получайте доступ — всё прозрачно.

И, конечно, главный вопрос — реклама. Интернет построен на рекламных деньгах, а без отслеживания рекламные системы теряют релевантность. Нерелевантная реклама не нужна ни пользователю, ни бизнесу. Решение Google Chrome — брать интересы пользователя прямо из браузера, не раскрывая, какие сайты он посещал. Это реализовано через Topics API: пользователь получает рекламные интересы на основе посещённых доменов, но они подаются с примесью случайного шума, и разные сайты могут видеть разные «топ-5» интересов — приватность прежде всего.

Дополняет эту модель Protected Audience API. Сайты могут добавлять пользователя в группы интересов при посещении, чтобы потом, при показе рекламы, браузер знал, что, скажем, реклама спорттоваров всё ещё релевантна. И всё это без раскрытия конкретных переходов и истории.

Неужели и конверсию можно посмотреть без отслеживания? Да! Больше API богу API: Attribution Reporting и Private Aggregation дают агрегированные данные, чтобы маркетологи могли считать эффективность, не получая идентифицирующую информацию.

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

Всё вышеперечисленное — лишь вершина айсберга. Переделка всей архитектуры интернета — колоссальная задача, и в этот раз она не взлетела. Что стало решающим — техническая трудоёмкость, падение точности таргетинга, неподготовленность рекламной индустрии или что‑то ещё, — остаётся загадкой. В итоге принудительное отключение сторонних кук было отложено, а новые API приватности остались опциональными, по выбору пользователя.

Как со сторонними куки работают в Яндекс Браузере

В Яндекс Браузере проблему сторонних куки начали решать ещё в 2021 году, но с компромисса. Вместо того чтобы одномоментно отменить всё и всем, команда искала золотую середину: починить побольше, сломать поменьше и обойтись без кардинальной перестройки всей веб‑архитектуры. Нашлось простое и действенное решение: блокировать сторонние куки только для тех ресурсов, на которые пользователь не заходил, и не блокировать, если заходил. Это значит, что виджеты авторизации, встроенные видео и прочие полезные встраиваемые вещи продолжают работать, а вот откровенно трекинговые скрипты чаще всего остаются без доступа к куки. Но, как водится, дьявол кроется в деталях.

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

Механизм доработали и на случай, если на сайт вы заходили давным‑давно в далёкой галактике: автоматическая разблокировка действует 45 дней, затем ресурс снова попадает под блокировку. При этом пользовательские настройки остаются бессрочными. Звучит просто, но на практике пришлось аккуратно переработать внутреннюю логику, добавить хранение даты посещения, предусмотреть миграцию данных при обновлении, и, конечно, всё это отразить в интерфейсе понятно и прозрачно.

Для формально разных, но фактически связанных доменов вроде github.com и githubassets.com изначально мы изобретали свой вариант списка наборов доменов, которые браузер будет считать связанными и разблокирует одновременно. Добавляли в него записи вручную, опираясь на жалобы пользователей по сломанным сайтам, и тоже переживали, не потребуется ли как‑то автоматизировать или масштабировать этот процесс. Неожиданно оказалось, что 640 КБ пяти пар доменов хватит всем. В итоге список оказался небольшим, но эффективным — массовой автоматизации не потребовалось.

Кстати, первым проблемным сайтом тогда оказался сам google.com (и связанный с ним googleusercontent.com): пользователи не могли скачивать файлы с Google Диска из‑за того, что браузер блокировал куки как сторонние.

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

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

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

Были и баги: нельзя просто так взять и сделать фичу без состояния гонки при редиректах, ошибки идентификации сторонности запросов, интерфейсных огрехов (например, протекающий в UI Punycode), ложных жалоб на «сломанный» сайт, который не имеет отношения к блокировкам, и прочих радостей жизни разработчика.

Особенно весело стало, когда Google Chrome начал штурм отмены сторонних кук: перетряхнулся весь код, связанный с куки, и фичу пришлось не только адаптировать, но и держать в актуальном состоянии по ходу стремительных изменений.

Но, несмотря ни на что, подход остался прежним. Фича заматерела, обзавелась именем (YTP, или Your Tracker Protection), символикой, очаровательным командным маскотом и прочно закрепилась в арсенале Браузера.

Итоги: решит ли отмена куки проблему цифрового трекинга пользователей

Увы, нет. Даже если отменить сторонние куки, трекинг пользователей не прекращается — например, сразу начинается рост отслеживания через first‑party cookies.

Теперь часто используется приём с промежуточными сайтами — bounce tracking. Пользователь кликает по ссылке, попадает сначала на «прослойку» — промежуточный домен, который вполне легально ставит свои куки, ведь пользователь действительно его посетил. А затем уже происходит перенаправление на финальный сайт. В результате такой прослойке известен и отправитель, и получатель трафика. А если таких ссылок достаточно, получается довольно полная картина интересов пользователя.

Методов борьбы с таким трекингом несколько. Разные браузеры используют разные комбинации:

• Фильтрация по чёрным спискам (в духе uBlock Origin): можно предупреждать пользователя ещё до перехода.

• Извлечение финального URL из ссылки на трекер — и редирект мимо прослойки.

• Удаление лишних параметров в ссылках, если они выглядят как идентификаторы.

• Автоматическое определение трекеров и удаление оставленных ими куки.

Google Chrome, например, двигается в сторону автоматического анализа: если переход был мгновенным, пользователь не взаимодействовал с сайтом, а куки всё же сохранились — браузер делает вывод, что это трекер, и со временем удаляет эти данные.

Такие подходы подтягиваются и в Яндекс Браузер. И тут начинаются внутренние архитектурные конфликты:

• Работа с куками при определении трекера часто требует данных YTP, а они живут в сетевом процессе (там, где работают с запросами).

• Но логика bounce‑трекеров в Google Chrome реализована в браузерном процессе (поближе к UI).

• В итоге вместо простого вызова IsCookieAllowed() приходится делать асинхронный межпроцессный запрос, ждать ответ и только потом продолжать выполнение — с передачей функций, колбэков и прочего.

Такая схема значительно усложняет код и делает его хрупким — особенно на фоне постоянных изменений в Chromium. В какой‑то момент мы решили не страдать зря и сделали кеш YTP‑данных в браузерном процессе, который обновляется из сетевого. Это значительно упростило жизнь.

С другой стороны, распознавание bounce‑трекеров позволяет дополнить механизм работы YTP. По изначальной логике фичи, если пользователь зашёл на bounce‑сайт, он считается надёжным и разрешённым. Но если он же распознан как трекер, браузер может отменить его автоматическую разблокировку, несмотря на посещение. Такие интеграции требуют тонкой настройки, но позволяют обоим методам защиты эффективно взаимодействовать друг с другом.

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

Получается почти уникальный браузерный отпечаток, по которому тоже можно отслеживать пользователя. Такому способу очень непросто противостоять, и основной обсуждаемый сейчас концепт — это «бюджет приватности»:

• измерение объёма идентифицирующей информации, уходящей с каждым запросом;

• при приближении к порогу, за которым «уровень анонимности» (k‑anonymity и differential privacy) слишком низок, вместо реальных данных отсылка случайных, либо заглушки, не несущей смысловой нагрузки, либо даже запрет запросов, которые могут привести к определению пользователя;

• уменьшение «пассивного» отпечатка — информации, отправляемой безусловно без явного запроса со стороны сервера;

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

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