Закон о cookie больше не о cookie: что теперь охватывает Статья 5(3)

Фраза «закон о cookie» всегда была неправильным названием. Статья 5(3) Директивы ePrivacy никогда не использовала слово cookie — она говорит о «хранении информации или получении доступа к информации, уже хранящейся в терминальном оборудовании подписчика или пользователя». В течение двух десятилетий регуляторы применяли этот текст в основном к cookie, потому что cookie были доминирующим механизмом хранения. Этот период закончился.

В октябре 2024 года Европейский совет по защите данных окончательно утвердил Рекомендации 2/2023 о техническом охвате Статьи 5(3). Рекомендации технологически нейтральны и явно охватывают пиксели отслеживания, отслеживание на основе URL, отслеживание только по IP и уникальные идентификаторы. В апреле 2026 года французский CNIL и итальянский Garante перевели эту структуру в обязательные национальные рекомендации по отслеживанию пикселей в email. Направление однозначно: если техника позволяет серверу читать идентифицирующие сигналы с устройства посетителя, требуется согласие, независимо от того, записывается ли что-то обратно.

Что теперь означает «получение доступа»

Статья 5(3) опирается на две действующие концепции: хранение и получение доступа. Большинство существующих работ по соответствию рассматривают триггером только хранение — если вы не устанавливаете cookie, вы предполагаете, что согласие не требуется. Рекомендации отвергают такое прочтение.

Получение доступа удовлетворяется, когда сервер активно инструктирует устройство отправить значения обратно. Пиксель отслеживания запускает запрос, чья строка запроса несёт идентификаторы. Уникальный URL, встроенный в рассылку, идентифицирует получателя. IP-адрес, используемый для отслеживания одного и того же устройства между сессиями, также является доступом — значение происходит из сетевого стека устройства и отправляется в каждом запросе.

Имеет значение механизм, а не формат сохранения. Отпечаток, хранящийся в серверной базе данных, рассматривается идентично cookie, сохранённой в браузере.

Почему это переписывает карту инструментов аналитики

Многие инструменты аналитики с фокусом на конфиденциальность позиционируют себя как не использующие cookie, при этом полагаясь на шаблоны, которые теперь охватываются рекомендациями:

• Серверные cookie и идентификаторы с разделением в стиле CHIPS. Перемещение cookie в разделённый контекст или в собственное серверное хранилище не меняет вопроса доступа. Если один и тот же идентификатор достигает сервера аналитики между посещениями, это всё ещё доступ.
• Идентификаторы посетителей, производные от IP. Инструменты, которые хэшируют IP и используют хэш в качестве стабильного идентификатора в течение дней, получают доступ к информации, которая происходит с устройства. Совет EDPB ясен: это требует согласия, если только контролёр не может продемонстрировать, что IP не происходил из терминального оборудования пользователя.
• Отслеживание открытий и просмотров на основе пикселей. Решение CNIL № 2026-042 (14 апреля 2026 г.) и рекомендации Garante от 17 апреля 2026 г. требуют явного, отдельного согласия на индивидуальное отслеживание открытий в email — до отправки email.

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

Технический тест на соответствующий сбор

Рекомендации оставляют узкий коридор: агрегированные сигналы, где никакое значение, которое сохраняет сервер, не возвращается к конкретному устройству во времени. Запрос к конечной точке сбора несёт значения, которые попадают в три категории:

1. Transport-layer values (IP, User-Agent) the server cannot avoid receiving
2. Contextual values (path, referrer domain, country derived from IP)
3. Derived values the server chooses to produce and store

Категория 1 неизбежна в TCP/HTTP. Вопрос в том, как выглядит категория 3. Если производное значение является постоянным идентификатором — даже хэшированным, даже с солью — это доступ. Если производное значение сбрасывается в ограниченном окне и не может быть скоррелировано между окнами, анализ EDPB рассматривает его как агрегированное.

Ежедневный хэш посетителя Monoid спроектирован против этого теста:

visitor_hash = SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

IP и User-Agent используются только в памяти для вычисления хэша, а затем отбрасываются. Входная дата означает, что один и тот же посетитель завтра производит другой хэш — по построению нет междневного идентификатора, к которому можно получить доступ. В пределах одного дня хэш дедуплицирует посетителя для агрегированных подсчётов; между днями нет ничего, что мог бы реконструировать злоумышленник или регулятор.

Заголовки, имеющие значение в конечной точке сбора

Два HTTP-заголовка несут большую часть поверхности конфиденциальности на собственном сборщике на краю и должны быть установлены преднамеренно.

Referrer-Policy: strict-origin-when-cross-origin — это современное значение по умолчанию Chrome, которое отправляет только источник при кросс-источниковых запросах. Избегайте unsafe-url и no-referrer-when-downgrade — оба ненужно утечкают информацию пути.

Permissions-Policy должен явно запрещать функции, которые трекеру аналитики не нужны:

Permissions-Policy: geolocation=(), microphone=(), camera=(),
  payment=(), usb=(), interest-cohort=()

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

Что разработчики должны проверить в этом квартале

Три вопроса продвигают аудит вперёд:

1. Позволяет ли какое-либо значение, которое сохраняет сервер аналитики, идентифицировать одного и того же посетителя в течение 25-часового окна? Если да, развёртывание, вероятно, теперь требует согласия согласно Статье 5(3).
2. Используются ли идентификаторы пикселей и URL в транзакционном или маркетинговом email? Согласно рекомендациям CNIL и Garante, индивидуальное отслеживание открытий требует отдельного, явного согласия до отправки email.
3. Устанавливает ли конечная точка сбора строгий Referrer-Policy и Permissions-Policy с отказом по умолчанию?

Вопрос «баннера cookie» находится ниже по течению от более фундаментального: вообще ли модель данных производит идентификатор между сессиями. Когда ответ нет, весь механизм Статьи 5(3) — согласие, отзыв, записи обработки — не задействуется, потому что технический триггер регулирования никогда не был нажат.