vaspvort
Ночной дозор
Команда форума
Модератор
ПРОВЕРЕННЫЙ ПРОДАВЕЦ
Private Club
Старожил
Migalki Club
Меценат💎
«Сторонние куки больше не нужны», — заявили разработчики Chrome и в январе 2024 года их у каждого сотого пользователя браузера. Однако уже в июле последовало осторожное: — и отмена кук была отменена.
Многие даже не заметили, что произошло. Но на самом деле речь шла о том, как должен работать интернет в целом: отказ затронул бы почти каждый сайт из тех, что ты посещаешь,%USERNAME%.
На связи Артём из команды Яндекс Браузера. В этой статье расскажу о том, как технологии, изначально созданные для упрощения жизни, со временем стали инструментом манипуляций, и о контрасте разных подходов к борьбе с этим. Поговорим о масштабных системных решениях и простых прикладных методах, сравним их эффективность, сложности внедрения и неожиданные подводные камни. И заодно разберёмся, почему проблема трекинга — это не только про сторонние куки.
Что такое сторонние куки и что с ними не так
Когда пользователь заходит на сайт, часть ресурсов — картинки, скрипты, видео, рекламные баннеры — часто подгружается с других доменов. Ответ от этих сторонних серверов может содержать не только нужные данные, но и куки — строку, которую браузер будет автоматически отправлять при последующих обращениях к тому же домену.Если куки установлены основным сайтом, это first‑party cookies. Если сторонним ресурсом — third‑party cookies.
На практике сторонние куки — это удобно. Например, вы заходите в блог, а там встроен виджет комментариев от соцсети, в которой вы уже авторизованы. Соцсеть узнаёт вас по сохранённым куки — и вы можете сразу писать комментарии без регистрации и СМС. Или если на сайте встроено видео с внешнего хостинга, то по куки показываются персональные кнопки, вроде «Смотреть позже».
Но у этой удобной схемы есть теневая сторона. Если сторонний сервер получает куки с нескольких сайтов, он может отслеживать вашу активность: какие страницы вы открываете, какие темы интересуют, и всё это без вашего ведома.
Жалобы на такое поведение регулярно поступают: пользователи недоумевают, как их действия отслеживают с такой точностью. Бывает, что человек просто открыл сайт — без логина, без ввода данных, — а потом получает звонок: «Вам что‑то не понравилось при визите?» Посещение отследили, каким‑то образом сопоставили телефон — с этим точно надо что‑то делать.
Почему не так просто отказаться от сторонних куки
Все third‑party cookies взять и отменить — крайне амбициозное решение. Однако ящик Пандоры, который открывает это решение, полон нетривиальных вопросов и архитектурных компромиссов.
Допустим, сторонние куки запрещены. Но что делать, если куки технически сторонние — домен‑то другой, но фактически принадлежит той же организации. Например, и . Или, скажем, и . Просто заблокировать?
Google Chrome создать глобальный список родственных доменов. Его хостят на GitHub, а браузеры получают и используют. Теоретически это позволяет решать такие кейсы, но на практике масштабирование этого подхода вызывает вопросы. Сейчас в списке около тысячи записей, и он пока не разросся до неуправляемых размеров, но насколько он устойчив при широком применении — большой вопрос.
Другой пример: сайт A загружает сторонний ресурс B, который, в свою очередь, включает на своей странице обратно A. Выглядит как рекурсия, но с точки зрения правил блокировки возникает вопрос: теперь даже на сайте A куки для него самого запрещать? Подобные взаимозависимости учтены, куки в таких случаях разрешаются.
А что делать с «сайтами в сайтах»? Комментарии, видео, платёжные системы — все эти iframe‑виджеты жили за счёт сторонних кук. На этот случай существует явная модель разрешений: при взаимодействии пользователь даёт согласие, и только тогда iframe получает доступ к куки. Встраивайте специальное , спрашивайте разрешение и получайте доступ — всё прозрачно.
И, конечно, главный вопрос — реклама. Интернет построен на рекламных деньгах, а без отслеживания рекламные системы теряют релевантность. Нерелевантная реклама не нужна ни пользователю, ни бизнесу. Решение Google Chrome — брать интересы пользователя прямо из браузера, не раскрывая, какие сайты он посещал. Это реализовано : пользователь получает рекламные интересы на основе посещённых доменов, но они подаются с примесью случайного шума, и разные сайты могут видеть разные «топ-5» интересов — приватность прежде всего.
Дополняет эту модель . Сайты могут добавлять пользователя в группы интересов при посещении, чтобы потом, при показе рекламы, браузер знал, что, скажем, реклама спорттоваров всё ещё релевантна. И всё это без раскрытия конкретных переходов и истории.
Неужели и конверсию можно посмотреть без отслеживания? Да! Больше API богу API: и дают агрегированные данные, чтобы маркетологи могли считать эффективность, не получая идентифицирующую информацию.
Да, многое при этом всё равно ломается. Потому в особо распространённых случаях браузер старается предугадывать, где без куки совсем нельзя, и делает . А для более специфичных просто заводится белый список сайтов, которым можно.
Всё вышеперечисленное — лишь вершина айсберга. Переделка всей архитектуры интернета — колоссальная задача, и в этот раз она не взлетела. Что стало решающим — техническая трудоёмкость, падение точности таргетинга, неподготовленность рекламной индустрии или что‑то ещё, — остаётся загадкой. В итоге принудительное отключение сторонних кук было отложено, а новые API приватности остались опциональными, по выбору пользователя.
Как со сторонними куки работают в Яндекс Браузере
В Яндекс Браузере проблему сторонних куки начали решать ещё в 2021 году, но с компромисса. Вместо того чтобы одномоментно отменить всё и всем, команда искала золотую середину: починить побольше, сломать поменьше и обойтись без кардинальной перестройки всей веб‑архитектуры. Нашлось простое и действенное : блокировать сторонние куки только для тех ресурсов, на которые пользователь не заходил, и не блокировать, если заходил. Это значит, что виджеты авторизации, встроенные видео и прочие полезные встраиваемые вещи продолжают работать, а вот откровенно трекинговые скрипты чаще всего остаются без доступа к куки. Но, как водится, дьявол кроется в деталях.
Если сайт сломается, в интерфейсе появится раздел, где можно посмотреть, кто заблокирован, и настроить исключения вручную — например, разрешить все сторонние куки на конкретном сайте или разблокировать определённый ресурс везде.
Механизм доработали и на случай, если на сайт вы заходили давным‑давно
Для формально разных, но фактически связанных доменов вроде и изначально мы изобретали свой вариант списка наборов доменов, которые браузер будет считать связанными и разблокирует одновременно. Добавляли в него записи вручную, опираясь на жалобы пользователей по сломанным сайтам, и тоже переживали, не потребуется ли как‑то автоматизировать или масштабировать этот процесс. Неожиданно оказалось, что
Кстати, первым проблемным сайтом тогда оказался сам (и связанный с ним ): пользователи не могли скачивать файлы с Google Диска из‑за того, что браузер блокировал куки как сторонние.
Позже, когда Google Chrome добавил свою реализацию связанных доменов, пришлось объединить подходы — подружить форматы хранения, учесть оба источника информации и пересобрать логику принятия решения о разблокировке. Это звучит проще, чем оказалось на практике.
Но на этом всё не закончилось. Если мы уже умеем тонко настраивать поведение блокировщика, почему бы не дать такую возможность и пользователям, которые включают режим полной блокировки сторонних кук? Теперь можно заблокировать всё и разрешить только нужное вручную — удобно и гибко.
Притом никто не любит медленные браузеры. У нас за скоростью его старта чутко следит отдельный набор тестов. И эти тесты недвусмысленно указывают, что блокировать запуск чтением файлов с информацией про разрешённые сторонние домены — не лучшее решение. Но и идти в сеть, не зная, кому можно, — тоже плохой вариант. Компромисс: первый запрос всегда идёт к основному ресурсу и не требует ожидания, а все последующие дожидаются загрузки базы — к тому моменту она уже доступна.
Были и баги: нельзя просто так взять и сделать фичу без состояния гонки при редиректах, ошибки идентификации сторонности запросов, интерфейсных огрехов (например, протекающий в UI Punycode), ложных жалоб на «сломанный» сайт, который не имеет отношения к блокировкам, и прочих радостей жизни разработчика.
Особенно весело стало, когда Google Chrome начал штурм отмены сторонних кук: перетряхнулся весь код, связанный с куки, и фичу пришлось не только адаптировать, но и держать в актуальном состоянии по ходу стремительных изменений.
Но, несмотря ни на что, подход остался прежним. Фича заматерела, обзавелась именем (YTP, или Your Tracker Protection), символикой, очаровательным командным маскотом и прочно закрепилась в арсенале Браузера.
Маскот YPT
Итоги: решит ли отмена куки проблему цифрового трекинга пользователей
Увы, нет. Даже если отменить сторонние куки, трекинг пользователей не прекращается — например, сразу начинается рост отслеживания через first‑party cookies.Теперь часто используется приём с промежуточными сайтами — bounce tracking. Пользователь кликает по ссылке, попадает сначала на «прослойку» — промежуточный домен, который вполне легально ставит свои куки, ведь пользователь действительно его посетил. А затем уже происходит перенаправление на финальный сайт. В результате такой прослойке известен и отправитель, и получатель трафика. А если таких ссылок достаточно, получается довольно полная картина интересов пользователя.
Методов борьбы с таким трекингом несколько. Разные браузеры используют разные комбинации:
- Фильтрация по чёрным спискам (в духе uBlock Origin): можно предупреждать пользователя ещё до перехода.
- Извлечение финального URL из ссылки на трекер — и редирект мимо прослойки.
- Удаление лишних параметров в ссылках, если они выглядят как идентификаторы.
- Автоматическое определение трекеров и удаление оставленных ими куки.
Такие подходы подтягиваются и в Яндекс Браузер. И тут начинаются внутренние архитектурные конфликты:
- Работа с куками при определении трекера часто требует данных YTP, а они живут в сетевом процессе (там, где работают с запросами).
- Но логика bounce‑трекеров в Google Chrome реализована в браузерном процессе (поближе к UI).
- В итоге вместо простого вызова IsCookieAllowed() приходится делать асинхронный межпроцессный запрос, ждать ответ и только потом продолжать выполнение — с передачей функций, колбэков и прочего.
С другой стороны, распознавание bounce‑трекеров позволяет дополнить механизм работы YTP. По изначальной логике фичи, если пользователь зашёл на bounce‑сайт, он считается надёжным и разрешённым. Но если он же распознан как трекер, браузер может отменить его автоматическую разблокировку, несмотря на посещение. Такие интеграции требуют тонкой настройки, но позволяют обоим методам защиты эффективно взаимодействовать друг с другом.
Некоторые трекеры уходят глубже и не используют куки вообще, а вместо этого собирают отпечатки устройств, опираясь на крошечные детали вроде размера окна, системных шрифтов, порядка загруженных плагинов и других HTTP‑заголовков.
Получается почти уникальный браузерный отпечаток, по которому тоже можно отслеживать пользователя. Такому способу очень непросто противостоять, и основной обсуждаемый сейчас концепт — это « »:
- измерение объёма идентифицирующей информации, уходящей с каждым запросом;
- при приближении к порогу, за которым «уровень анонимности» ( и ) слишком низок, вместо реальных данных отсылка случайных, либо заглушки, не несущей смысловой нагрузки, либо даже запрет запросов, которые могут привести к определению пользователя;
- уменьшение «пассивного» отпечатка — информации, отправляемой безусловно без явного запроса со стороны сервера;
- интерфейс для одобрения пользователем сайтов‑исключений, которые в силу своей специфики не смогут работать в рамках обычного бюджета приватности.
