Cookie-баннер

Происхождение и история термина

В феврале 1997 года RFC 2109 описал обмен данными между сервером и браузером через заголовки Cookie и Set-Cookie. Это позволяло сайту связывать последовательные обращения в одну сессию — например, помнить состояние работы между открытием двух страниц. Документ теперь имеет исторический статус; он показывает техническую предпосылку баннера, а не дату его изобретения. ^[6]

Следующий важный шаг связан с выбором пользователя. Как объясняет французская Национальная комиссия по информатике и свободам (CNIL), изменение директивы ePrivacy о конфиденциальности электронных коммуникаций в 2009 году закрепило предварительное согласие на запись и чтение информации на устройстве с оговорёнными исключениями; во Франции эти положения реализует статья 82 национального закона. В центре такого подхода находится назначение операции, а не само слово cookie. ^[4]

К 2020 году французские рекомендации уже разбирали практическое устройство выбора: краткое объяснение можно дополнять подробной панелью, а отказ и отзыв должны быть доступны человеку. В отчёте группы Европейского совета по защите данных (EDPB) по cookie-баннерам 2023 года рассматриваются более конкретные проблемы: заранее включённые флажки, незаметные варианты отказа и доступ к отзыву. Так история предмета ведёт от сохранения состояния к управлению им через понятный интерфейс. Эти документы не устанавливают первого автора названия cookie banner. ^{[2, 4]}

Суть и механизм

Cookie — небольшая запись, которую браузер может хранить и передавать серверу при последующих обращениях. Сервер — программа, которая отвечает на запросы браузера; запрос возникает, например, при открытии страницы. Благодаря записи сайт может помнить вход пользователя, настройки или сведения для отслеживания. Баннер — видимая часть управления такими операциями, а не сама запись. ^[1]

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

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

По руководству британского регулятора — Управления комиссара по информации (ICO) — там, где нужно согласие, пользователь должен выразить его действием, а сайт должен выполнить сделанный выбор. Простого продолжения просмотра недостаточно. Руководство различает цели операций и условия исключений: одну лишь подпись «аналитика» нельзя считать основанием для запуска счётчика. ^[3]

В учебной архитектуре редакции интерфейс передаёт состояние выбора управляющему компоненту, а тот определяет разрешённые действия. При изменении выбора состояние пересматривается. CMP (Consent Management Platform) — система управления согласием: она показывает информацию, даёт элементы выбора и может сохранять его запись. ^[3] В описанной учебной схеме ещё предстоит настроить передачу выбора каждому компоненту; одна панель этого не обеспечивает.

Трекером здесь называется технология, которая помогает отслеживать действия пользователя; такое назначение нужно выяснять по работе конкретного компонента. ^{[1, 4]}

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

Виды и классификации

Следующая таблица — рабочая функциональная классификация редакции, а не классификация cookies по закону.

Техническое назначение тоже следует описывать отдельно. В MDN сессия, персонализация и отслеживание различаются по функции; это не готовый перечень юридических исключений. Для определения основания нужны реальные цели и обстоятельства. ^[1]

CNIL приводит примеры технологий, освобождаемых от согласия при соответствующих условиях, включая сохранение выраженного выбора и некоторые операции измерения аудитории. Само название категории «аналитика» не устанавливает применимость такого исключения к любому инструменту. ^[4]

Как применяется на практике

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

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

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

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

Для российского сайта копирование европейского текста не заменяет анализа по 152-ФЗ. Если обработка опирается на согласие, его характеристики и доказательство оцениваются по российской норме. Фраза о продолжении просмотра не должна восприниматься как универсальный способ решить все вопросы обработки. ^[5]

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

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

Проверка обновления без потери контекста

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

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

При обнаружении расхождения полезно сохранить точное описание наблюдения: действие, страницу, последовательность и время. Формулировка «баннер не работает» слишком широка для воспроизведения. Запись «после отказа при переходе на вторую страницу возник запрос к указанному компоненту» задаёт предмет дальнейшего разбора, но ещё не заменяет юридический вывод о нём.

Как измерить или проверить

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

Технический осмотр должен охватывать не только доступное JavaScript хранилище. MDN указывает, что cookies с HttpOnly недоступны через JavaScript. Поэтому отсутствие записей в document.cookie не доказывает отсутствие cookies вообще; нужны соответствующие средства разработчика и анализ запросов. ^[1]

Для каждого сценария редакция предлагает карточку:

1. Версия сайта и дата проверки.
2. Тестовая среда и начальное состояние.
3. Действие пользователя.
4. Ожидаемое поведение компонента.
5. Фактически наблюдавшиеся запросы и записи.
6. Расхождения и ответственный за проверку.

Отдельно полезно проверить понятность интерфейса. Может ли человек найти назначение операций, получателей и способ изменить выбор? Доступны ли кнопки с клавиатуры и на небольшом экране? Ответы получают при отдельной проверке интерфейса на сайте, а не по одному тексту баннера.

Доля нажатий «принять» не является мерой законности. Учебный расчёт: за один период записано 1000 показов баннера и 900 нажатий на принятие, по одному на каждый из соответствующих показов. Доля показов с принятием равна 900 / 1000 × 100 = 90 %. В числителе — показы с принятием, в знаменателе — все показы за тот же период. Это доля событий, а не обязательно доля отдельных людей: один человек мог увидеть баннер повторно. Результат ничего не сообщает о полноте информации, добровольности или работе отказа. Поэтому редакция не предлагает оптимизировать баннер только на увеличение принятия.

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

мини-инструмент при статье собирает ответы на девять диагностических вопросов. Для каждого пункта выбирают один из трёх ответов: «подтверждено», «не подтверждено» или «неизвестно». Затем получают список дальнейших проверок и карточку для ручного копирования. В информационном сценарии три вопроса, относящиеся только к согласию, не оцениваются; это не положительный результат по ним. Если необходимость согласия не определена, выбирают неизвестный сценарий, чтобы не скрыть пробел. Инструмент не посещает сайт, не обнаруживает cookies, не выбирает применимое право и не управляет согласием посетителей.

Например, после первой проверки команда заметила запрос к рекламному компоненту и поменяла ответ об исполнении выбора с «подтверждено» на «не подтверждено». Старая карточка сразу исчезает. Нажмите «Сформировать карточку», и в новой записи появится неподтверждённый пункт. Кнопка «Очистить» удаляет текст карточки и возвращает поля в исходное состояние; копировать текст нужно до сброса.

Даже все положительные ответы означают только отсутствие заявленных пользователем пробелов в выбранном перечне. Это не сертификат соответствия: ответы могут быть неверными, а перечень не охватывает все обстоятельства. Инструмент намеренно не выдаёт зелёный вердикт «законно».

Ошибки, ограничения и спорные вопросы

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

Третья — считать все операции одной категорией «необходимые». EDPB отмечает трудность устойчивого списка таких технологий и необходимость выяснять их назначение; название, выбранное владельцем сайта, само по себе вопрос не решает. ^[2]

ICO показывает равнозначные варианты принятия и отказа. EDPB требует индивидуальной оценки дизайна, не предписывая единственный цвет кнопок. Это не мировой универсальный макет. ^{[2, 3]}

Автоматический перечень не объясняет назначение технологий: EDPB отделяет его от выяснения их природы. ^[2]

Наконец, отказ, отзыв и удаление уже собранных сведений — разные события. Закрытие окна само по себе ничего не стирает. В британском сценарии, описанном ICO, при отзыве нужно прекратить соответствующее использование технологий, уведомить участвующих третьих лиц и удалить сведения, собранные на основании отозванного согласия. Чтобы проверить исполнение, нужно знать, какие системы получили данные. Это разъяснение ICO относится к описанному им режиму. ^[3]

Правовой аспект

В России части 1–3 статьи 9 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных» описывают требования к согласию на обработку персональных данных. Согласие должно выражать свободную волю человека, относиться к конкретной обработке и оформляться отдельно от иных сведений или документов, которые человек подтверждает либо подписывает. Получение согласия доказывает оператор. Человек может его отозвать; закон допускает продолжение обработки без согласия, если есть другое указанное в нём основание. Такое основание тоже должен доказать оператор. Статья 9 сама по себе не устанавливает обязательный вид cookie-баннера. ^[5]

EDPB различает операции на устройстве по национальной реализации ePrivacy и дальнейшую обработку по Общему регламенту защиты данных ЕС (GDPR). CNIL относится к Франции, ICO — к Великобритании; это не российские нормы. ^{[2, 3, 4]}

Статья даёт справочную карту вопросов. Применимость режимов, основания, конкретный текст и настройки требуют проверки юристом и техническим специалистом. Решение по конкретному сайту принимают после такой проверки.

Частые вопросы

Мини-инструмент

Учебный инструмент к статье: карточка дальнейшей проверки. Это авторский чек-лист, не юридическое заключение.

Связанные термины

• Согласие на обработку персональных данных