Как работает ITP в Safari по механизмам: классификация трекеров, лимит хранилища в 7 дней, блокировка cookie, урезание referrer и то, что ITP не останавливает.
У вопроса «блокирует ли Safari трекеры?» есть короткий ответ — да — и длинный, более полезный. Intelligent Tracking Prevention (ITP) — это не один переключатель. Это набор отдельных механизмов в WebKit, каждый из которых нацелен на свой способ переносить идентификатор с одного сайта на другой: классификатор, помечающий домены, способные к трекингу; жёсткая блокировка сторонних cookie; ограничение срока, на который скрипты могут хранить данные; урезание referrer и не только. В этом руководстве мы разберём их по одному и для каждого зададим три одинаковых вопроса: что он делает, что теряет трекер и что теряет обычный сайт.
Ключевые выводы
- ITP — это набор механизмов, а не одна функция. Согласно документации WebKit Tracking Prevention, он объединяет блокировку сторонних cookie, понижение referrer, классификацию трекеров на устройстве, удаление хранилища и ограничение сроков хранения.
- «Лимит в 7 дней» относится к хранилищу, записанному скриптами. WebKit удаляет cookie, созданные в JavaScript, а также
localStorage, IndexedDB,sessionStorage, медиаключи, регистрации service worker и их кеши, если в течение 7 дней пользователь не взаимодействовал с сайтом. - Сторонние cookie блокируются полностью. WebKit заявляет, что исключений нет; доступ выдаётся только через Storage Access API (и временное исправление совместимости для всплывающих окон).
- ITP — это защита только от трекинга на основе состояния. Он удаляет сохранённые идентификаторы и общее хранилище. Он не мешает сайту собирать данные о собственных посетителях и не является системой защиты от фингерпринтинга — с фингерпринтингом WebKit борется отдельным набором изменений.
- На iOS он охватывает все браузеры. Поскольку все браузеры на iPhone используют движок WebKit, поведение ITP вы получаете не только выбрав Safari — см. почему каждый браузер на iOS внутри — Safari.
С чего начался ITP и почему важна страница документации
WebKit представил ITP в июне 2017 года. Первоначальный анонс — Intelligent Tracking Prevention авторства Джона Уилендера (John Wilander) — подавал его как способ сократить межсайтовый трекинг за счёт «дальнейшего ограничения cookie и других данных сайтов» и опирался на давнее умолчание: ещё со времён Safari 1.0 WebKit не позволял третьей стороне устанавливать новые cookie, если у неё их ещё не было.
С тех пор исходный замысел изменился. В версии 2017 года классифицированный домен, с которым пользователь взаимодействовал в последние 24 часа, ещё мог использовать свои cookie в стороннем контексте, а при взаимодействии в последние 30 дней сохранял cookie, но уже в партиционированном виде. В нынешней документации WebKit блокировка сторонних cookie описана как полная. Поэтому хронологическая история версий — плохой способ изучать ITP: она быстро устаревает. Актуальный первоисточник — страница WebKit Tracking Prevention, и остальная часть статьи следует именно ей.
Механизм 1: классификация доменов, способных к трекингу
Что он делает. ITP собирает статистику загрузок ресурсов и сопоставляет её с известными паттернами межсайтового трекинга. Если регистрируемый домен подпадает под паттерн, он классифицируется как обладающий возможностями межсайтового трекинга. Модель машинного обучения смотрит на три числа: на скольких разных сайтах домен встречался как сторонний подресурс, на скольких — как сторонний iframe и на скольких сайтах он выполнял межсайтовые редиректы. В анонсе 2017 года WebKit сообщает, что весь сбор данных и классификация происходят на устройстве.
Ещё два паттерна ведут к той же метке. Повторяющиеся редиректы верхнего фрейма (bounce tracking) учитываются, даже если редирект задерживается на пару секунд. А сговор трекеров (tracker collusion) распространяет метку дальше: как только домен классифицирован, классифицируются и все домены, которые ранее перенаправляли на него, — рекурсивно по графу редиректов.
Что теряет трекер. У классифицированного домена удаляются все данные сайта, если только в последние 30 дней использования браузера пользователь не взаимодействовал с ним как с first-party или ему не был выдан доступ к хранилищу. Домен, который всегда появляется лишь в фоне, такого взаимодействия не получает никогда — а значит, не сохраняет ничего.
Что теряет обычный сайт. Ничего, если только он не похож на трекер. Сайт, которым вы действительно пользуетесь, получает «зачёт» за взаимодействие — это и есть исключение. Цену платят законные встраиваемые сервисы, которые пользователи редко открывают напрямую: провайдера виджета, которого вы никогда не открываете в отдельной вкладке, можно ошибочно принять за трекер.
Механизм 2: полная блокировка сторонних cookie
Что он делает. Политика cookie по умолчанию в WebKit, действующая со времён Safari 1.0, запрещает третьей стороне устанавливать новые cookie, если у неё их ещё нет. ITP идёт дальше: по умолчанию он блокирует все сторонние cookie без исключений. Два сопутствующих правила закрывают боковые двери. Режим защёлки (latch mode) означает, что если запросу запретили использовать cookie, то запрещено и всем редиректам этого запроса. А сторонний HSTS блокируется: его может устанавливать только first-party сайт — для собственного хоста и регистрируемого домена.
Что теряет трекер. Классическая схема: рекламный или аналитический домен, загруженный на множестве сайтов, читает на каждом одну и ту же cookie. При ITP эта cookie не отправляется никогда, и трекер каждый раз видит незнакомца.
Что теряет обычный сайт. Любой встроенный сервис, полагавшийся на общую стороннюю cookie: фреймы единого входа (SSO), встроенные системы комментариев, которые узнают вошедшего пользователя, платёжные виджеты. Им приходится запрашивать доступ явно (см. механизм 6).
Механизм 3: ограничение хранилища, записанного скриптами
Что он делает. К хранилищу, созданному JavaScript в first-party контексте, применяются два ограничения, потому что трекеры, работающие как first-party скрипты, записывали туда идентификаторы:
- 7 дней. ITP удаляет все cookie, созданные в JavaScript, и всё остальное хранилище, доступное для записи из скриптов, если в течение 7 дней пользователь не взаимодействовал с сайтом. WebKit перечисляет затронутые хранилища: IndexedDB, LocalStorage, медиаключи, SessionStorage, а также регистрации service worker и их кеш.
- 24 часа для link decoration. Некоторые трекеры добавляют в URL «click ID» как параметры и подхватывают их скриптом на целевой странице. ITP распознаёт этот паттерн и ограничивает срок жизни cookie, созданных в JavaScript на такой целевой странице, до 24 часов.
Отсчёт ведётся по взаимодействию пользователя — клику, касанию или нажатию клавиши (по словам WebKit, прокрутка не считается), а не по календарному времени с момента создания. Сайт, которым вы пользуетесь каждые несколько дней, сохраняет свои данные.
Что теряет трекер. Долгоживущий first-party идентификатор, который сторонний скрипт записал в собственное хранилище страницы. Любой посетитель, вернувшийся после паузы дольше недели, выглядит для него новым.
Что теряет обычный сайт. Всё, что хранится на стороне клиента и должно пережить неделю без визитов: флаг «запомнить меня», выставленный из JavaScript, черновик в localStorage, cookie с настройками. Сайтам, которым нужно долговечное состояние, стоит хранить его на сервере или устанавливать из ответа сервера. Там же WebKit отмечает, что веб-приложения на домашнем экране освобождены от 7-дневного лимита и изолированы от данных самого Safari.
Механизм 4: понижение referrer
Что он делает. По умолчанию все сторонние referrer урезаются до источника (origin) — и в HTTP-заголовке Referer, и в document.referrer. Пример из WebKit: полный referrer https://www.social.example/feed?clickID=123456 превращается в https://www.social.example/.
Что теряет трекер. Путь и строку запроса. Click ID или URL статьи, переданные в referrer, до места назначения больше не доходят — только сайт, с которого пришёл посетитель.
Что теряет обычный сайт. Детальную реферальную аналитику. Сайт по-прежнему видит, какой источник направил посетителя, но не видит, какая именно страница или какие параметры кампании на этом источнике.
Механизм 5: защита от редиректов и bounce-трекинга
Что он делает. Bounce tracking ненадолго проводит вас через домен трекера, чтобы тот выполнился как first-party и смог прочитать собственные cookie. ITP считает редиректы верхнего фрейма для каждого домена и передаёт их классификатору из механизма 1. Если классифицированный домен, у которого было взаимодействие с пользователем или доступ к хранилищу, уличён в bounce-трекинге, то, по словам WebKit, его cookie могут быть переписаны в SameSite=strict — и перестанут отправляться при межсайтовой навигации. Режим защёлки для cookie (механизм 2) охватывает цепочки редиректов.
Есть и родственная защита от CNAME cloaking: когда поддомен, выглядящий как first-party, на самом деле резолвится в сторонний трекер, ITP ограничивает срок жизни cookie, установленных в HTTP-ответе, 7 днями. То же ограничение WebKit применяет к сторонней маскировке через IP-адреса (IP address cloaking). Саму технику разбирает наша статья про CNAME cloaking.
Что теряет трекер. Возможность использовать мимолётный редирект через собственный домен, чтобы стать first-party и получить свою cookie.
Что теряет обычный сайт. Законные сценарии на редиректах — например, переходы при едином входе или сервисы сокращения ссылок — могут выглядеть как bounce. Исключение для взаимодействия защищает провайдеров, с которыми пользователи действительно работают. О самой технике читайте в статье Bounce Tracking: как это работает.
Механизм 6: Storage Access API как разрешённое исключение
Что он делает. Блокировка в ITP ломала бы законные встроенные сервисы, поэтому WebKit добавил исключение: сторонний фрейм может запросить доступ к собственным first-party cookie через Storage Access API, как правило в ответ на действие пользователя. MDN описывает API как document.hasStorageAccess() и document.requestStorageAccess(), причём разрешение привязано к конкретной паре «сайт верхнего уровня — встроенный сайт». Актуальное поведение и различия в показе запроса подтверждения между браузерами смотрите в справочнике MDN по Storage Access API.
В документации WebKit отмечено, что выданный доступ к хранилищу — одно из двух условий (вместе с first-party взаимодействием пользователя), избавляющих классифицированный домен от удаления данных.
Что теряет трекер. Возможность получать доступ незаметно. Ему приходится просить его в контексте, после настоящего взаимодействия, а пользователь или браузер могут отказать.
Что теряет обычный сайт. Немного удобства: встраиваемому элементу, который раньше работал невидимо, теперь нужен один клик и один вызов API.
Слой партиционирования под всем этим
Помимо шести механизмов выше, документация WebKit описывает слой партиционирования: сторонние LocalStorage и IndexedDB партиционируются по first-party сайту и становятся эфемерными, сторонние Service Worker партиционируются вместе со своим кешем и IndexedDB, а записи HTTP-кеша для стороннего контента партиционируются по first-party сайту. Записи, созданные для доменов, классифицированных как трекеры, также помечаются для верификации: через семь дней попадание в кеш считается промахом, ресурс перезагружается и сравнивается, а запись отбрасывается, если ответы различаются, — это защита от идентификаторов на основе кеша вроде ETag. Общая идея разобрана в статье о партиционировании хранилища.
Чего ITP не делает
Об этом большинство статей умалчивает, поэтому скажем прямо.
- Он не мешает сбору данных first-party. ITP нацелен на межсайтовый трекинг. Сайт по-прежнему может узнавать собственных вернувшихся посетителей, фиксировать их действия и устанавливать cookie в собственных HTTP-ответах. Описанные выше ограничения относятся к хранилищу, записанному скриптами; обычные first-party cookie, установленные сервером, в документации WebKit среди затронутых хранилищ не перечислены (исключение — случай CNAME cloaking).
- Он не останавливает фингерпринтинг. Отпечаток вычисляется из сигналов браузера и оборудования и ничего не хранит, поэтому ITP нечего удалять, ограничивать или партиционировать. Механику разбирает наше руководство по фингерпринтингу браузера, а проверка отпечатка покажет, что раскрывает ваш собственный браузер.
- Он не делает link decoration безвредным. ITP ограничивает срок жизни cookie, записанных скриптом на целевой странице, когда замечает click ID, но сервер, получивший click ID в запросе, всё равно может его записать.
- Он не заменяет сигнал о нежелании отслеживания. Заголовок Do Not Track вежливо просил сайты, ITP — принуждает. WebKit даже удалил свой флаг DNT, потому что тот «использовался как вектор фингерпринтинга». См. почему DNT провалился.
ITP и фингерпринтинг — разные подсистемы
Легко смешать две вещи, которые WebKit держит раздельно. ITP отвечает за состояние: cookie, хранилище, referrer, кеши и редиректы. Защита от фингерпринтинга — другой набор изменений, перечисленный в отдельном разделе той же страницы документации: требование разрешения для API Device Orientation/Motion, ограничение того, что WebRTC раскрывает о подключённых камерах и микрофонах, сужение доступных шрифтов до веб-шрифтов и системных, «заморозка» строки user-agent между маркетинговыми версиями, удаление поддержки плагинов в macOS и отказ от реализации таких функций, как Web Bluetooth, Web MIDI и Battery Status API.
У них разные цели и разные слабые места. ITP обезвреживает идентификатор, который трекер хранит. Защита от фингерпринтинга сокращает число различающих сигналов, доступных для идентификатора, который трекер вычисляет. Каждая защита на основе состояния, выпущенная в Safari, делала путь без хранения состояния относительно более ценным для трекера, всё ещё желающего связывать активность между сайтами, — вот почему постоянный visitor ID, построенный на сигналах браузера, переживает все перечисленные выше механизмы.
Часто задаваемые вопросы
Блокирует ли Safari трекеры?
Да, сразу несколькими способами: блокирует сторонние cookie, урезает сторонние referrer, классифицирует домены, способные к трекингу, и удаляет их данные, а также ограничивает срок жизни хранилища, записанного скриптами. Но весь трекинг он не блокирует — сбор данных first-party и фингерпринтинг остаются.
Что такое лимит cookie в 7 дней в ITP?
Это ограничение хранилища, доступного для записи из скриптов. Если в течение 7 дней пользователь не взаимодействовал с сайтом, WebKit удаляет для него cookie, созданные в JavaScript, и другое хранилище, доступное скриптам, например localStorage и IndexedDB. Любое взаимодействие с сайтом сбрасывает отсчёт.
Действует ли ITP в Chrome или Firefox на iPhone?
Да, потому что на iOS эти приложения используют WebKit, хотя в некоторых регионах ситуация меняется — об этом рассказано в статье почему каждый браузер на iPhone — это Safari. Поведение ITP — свойство движка, а не бренда Safari.
Можно ли отключить ITP?
Документация WebKit связывает политику cookie по умолчанию с настройкой Safari «Запретить межсайтовое отслеживание» (Prevent cross-site tracking). Её отключение облегчает межсайтовый трекинг и редко бывает верным решением для сломавшегося встраиваемого элемента; штатный путь — Storage Access API.
Останавливает ли ITP фингерпринтинг браузера?
Нет. ITP касается сохранённого состояния. Фингерпринтинг ничего не хранит, а отдельные меры WebKit против фингерпринтинга сокращают, но не устраняют то, из чего можно построить отпечаток.
Заключение
ITP работает потому, что не полагается на один приём. Классификация находит трекеры по их поведению, блокировка cookie лишает трекеры общей для всех сайтов cookie, ограничения хранилища сокращают то, что могут хранить скрипты, урезание referrer убирает детали URL, а Storage Access API оставляет видимый и завязанный на действие пользователя путь назад для законных встраиваемых элементов. То, чего ITP не касается, не менее важно: собственные записи сайта о своих посетителях и любой идентификатор, который вычисляется, а не хранится. Если хотите увидеть эту вторую категорию своими глазами, запустите проверку отпечатка в Safari и сравните результат с другим браузером.
Рекомендуем прочитать:
