Соблюдение идиотских законов не обязывает вас делать идиотский интерфейс
Современный сайт считает своим долгом сообщить:
Мы используем cookie.
Спасибо.
Ещё сайт использует HTML, HTTP, TLS, TCP/IP, DNS и JavaScript. Но именно cookie получили собственный баннер, настройки и иногда небольшой административный интерфейс.
Потом появляются согласия на персональные данные, политика, оферта и рассылка.
В какой-то момент соблюдение закона незаметно превращается в самостоятельный frontend-фреймворк.
Хотя задача разработчика гораздо проще: понять, что закон действительно требует, и реализовать ровно это.
Пять прилагательных вместо спецификации
Разработчику удобно работать с формализованными требованиями.
Например:
- до начала обработки показать цели;
- получить отдельное утвердительное действие;
- сохранить время и версию текста согласия;
- предоставить механизм отзыва.
Это спецификация. Её можно реализовать, протестировать и проверить.
Статья 9 закона № 152-ФЗ требует, чтобы согласие было конкретным, предметным, информированным, сознательным и однозначным.
Это не спецификация. Это пять прилагательных.
С 1 сентября 2025 года согласие также должно оформляться отдельно от иной информации и документов, которые подтверждает или подписывает пользователь.
Теперь пять прилагательных и наречие.
Замечательная документация.
С такими требованиями можно пойти доебаться до случайного прохожего на улице и быть по понятиям правым.
Что считать «отдельно» на уровне интерфейса, закон тоже не определяет. Поэтому в лучшем случае разработчику приходится сочинять спецификацию самому.
В худшем случае ему на плечо кладёт руку юрист.
— Давай отдельный чекбокс.
Реализация попадает в production. Следующий разработчик смотрит чужой production, видит чекбокс и повторяет.
Через несколько лет все уверены, что в приложении к 152-ФЗ написано:
<input type="checkbox" required>
Хотя там по-прежнему пять прилагательных и наречие.
Мы используем cookie. Простите
В Trusty Tools cookie используется, например, чтобы запомнить, как пользователь предпочитает смотреть каталог: списком или сеткой.
Значение нужно серверу при рендере страницы: если выбран список, сервер сразу отдаёт нужный класс в HTML. localStorage здесь не поможет — сервер до него не дотягивается.
Остальное состояние интерфейса прекрасно живёт в localStorage.
Отдельного уведомления о cookie нет.
Мы забыли спросить пользователя, где нам хранить состояние интерфейса.
Cookie вообще не единственный механизм хранения данных в браузере. Есть localStorage, sessionStorage, IndexedDB и Cache API. Исторически был Web SQL.
Но юридически важно не название хранилища, а то, что мы в нём храним и что потом с этими данными делаем.
Статья 3 закона № 152-ФЗ определяет персональные данные как информацию, относящуюся к прямо или косвенно определённому или определяемому физическому лицу.
view=list сам по себе мало кому интересен.
Совсем другое дело — устойчивый идентификатор, который на сервере связывается с пользователем, его email, историей заказов, просмотренными товарами и рекламным профилем.
Причём сам идентификатор можно хранить где угодно.
Перенесли его из cookie в IndexedDB.
Cookie исчезла.
Обработка — нет.
Поэтому сообщение «мы используем cookie» само по себе почти ничего не объясняет. Правильный вопрос:
Что вы собираете, зачем и с чем это связываете?
Если сайт начинает идентифицировать человека, строить профиль его поведения или передавать данные рекламным системам — это уже предмет разговора.
Не потому, что появилась cookie.
Потому что изменилась обработка данных.
Персональные данные не означают автоматически «нужен чекбокс»
Следующая распространённая конструкция:
Есть персональные данные → нужно согласие.
Нет.
Согласие — лишь одно из предусмотренных законом оснований обработки.
Например, п. 5 ч. 1 ст. 6 закона № 152-ФЗ допускает обработку, необходимую для исполнения договора с человеком либо заключения договора по его инициативе.
Покупатель сам сообщает магазину имя, телефон и адрес, чтобы оформить заказ. Магазин использует их, чтобы этот заказ исполнить.
Для такой необходимой обработки закон предусматривает самостоятельное договорное основание.
Но интерфейс всё равно часто спрашивает:
□ Я согласен на обработку персональных данных.
То есть человек сообщил адрес доставки, а мы уточнили, разрешает ли он использовать его для доставки.
Хорошо, что спросили. Мало ли зачем он его написал.
Поэтому первый вопрос при разработке формы не «где поставить галочку на ПД?», а зачем мы собираем эти данные и на каком основании их обрабатываем?
Один email, две разные задачи
Пока магазин использует email, чтобы прислать чек, сообщить статус заказа или решить проблему с доставкой, это часть отношений по заказу.
Когда тот же магазин пишет:
А у нас новые шуруповёрты.
это уже реклама.
Для неё ст. 18 закона «О рекламе» требует предварительного согласия адресата. Причём рекламораспространитель должен уметь доказать, что оно было.
Один email. Две цели. Разные правовые основания.
Универсальная галочка «Согласен на обработку персональных данных» эту разницу не отменяет.
Известный дефект: рассылка
У Trusty здесь есть известный дефект.
Магазин иногда отправляет покупателям персонализированные предложения. Первое письмо может прийти примерно через неделю после заказа, следующие — обычно раз в месяц или реже.
Отписаться можно навсегда в личном кабинете или непосредственно из письма.
Отдельного предварительного согласия на рассылку в checkout нет.
Юридически исправление известно:
□ Получать специальные предложения.
Дефект пока оставлен открытым как менее раздражающий пользователя, чем исправление.
Первое письмо может начинаться примерно так:
Извините, что прислали это письмо. Иногда мы можем присылать предложения, которые считаем релевантными именно вам. Если вам это не нужно — нажмите «Отписаться». Всё. Навсегда.
Это не юридический лайфхак. Отписка после первого письма не заменяет предварительного согласия.
Но здесь хорошо видно, что юридическая корректность и уважение к пользователю — разные характеристики продукта.
Можно получить совершенно законную галочку:
☑ Получать специальные предложения.
а потом писать человеку три раза в неделю.
Можно сделать «Центр управления коммуникациями», потребовать авторизацию для отписки и предложить пять видов рассылок.
Предварительное согласие есть. Закон соблюдён.
Пользователь почему-то всё равно считает вас мудаками.
В Trusty принцип другой: если уж написали — редко, по делу и с возможностью одним действием заткнуть нас навсегда.
Формально это слабее.
Как отношение к пользователю мне это нравится больше.
Политика конфиденциальности существует для юридических формальностей
Отдельная история — политика обработки персональных данных.
Статья 18.1 закона № 152-ФЗ требует, чтобы оператор определил такую политику, опубликовал её и обеспечил к ней доступ.
Окей.
С точки зрения реальной информационной безопасности этот документ довольно мало что меняет.
Мы и без политики держим базу данных за файрволом. Ограничиваем к ней доступ. Шифруем то, что нужно шифровать. Ставим обновления. Не выдаём production-доступ человеку только потому, что он однажды написал в Telegram: «Привет, я новый маркетолог».
Если ничего этого не делать, прекрасно написанная политика базу не защитит.
Более того, настоящие внутренние документы по ИБ — архитектуру сети, правила доступа, конфигурацию инфраструктуры, процедуры реагирования — как раз совершенно незачем публиковать на сайте.
Публичная политика — не документация системы безопасности. Это юридический документ, в котором оператор сообщает:
- какие данные и зачем обрабатывает;
- на каких основаниях;
- кому может передавать;
- сколько хранит;
- как человек может реализовать свои права;
- какие меры защиты применяются на необходимом уровне обобщения.
Хорошо. Напишем.
Данные храним в защищённой инфраструктуре, доступ ограничиваем, необходимые организационные и технические меры принимаем, без законного основания данные посторонним не раздаём. Остальные обязательные сведения перечислим согласно закону.
ИБ от публикации этого текста не стала лучше. Зато требование выполнено.
И вот здесь особенно странно выглядит:
□ Я согласен с политикой конфиденциальности.
С чем именно пользователь соглашается?
Политика сообщает ему, как оператор выполняет свои обязанности. Закон требует сделать её доступной, а не заключить по ней отдельный договор с каждым посетителем.
Публикуем документ, ставим ссылку и едем дальше.
С офертой всё проще
Условия оферты должны быть доступны пользователю, а её акцептом может быть совершение предусмотренного действия. Это прямо допускает ст. 438 ГК РФ.
Поэтому нормальной конструкции:
Нажимая «Подтвердить заказ», вы принимаете условия Публичной оферты.
достаточно. Оферта — ссылка, нажатие кнопки — акцепт.
Заставлять пользователя отдельно подтверждать, что он действительно прочитал документ, не требуется.
Да, скорее всего, он его не прочитает.
Но это не значит, что теперь можно незаметно дописать в пункте 14.8:
В случае оформления заказа квартира покупателя переходит в собственность продавца.
и ехать за ключами.
Оферта — договор, а не локальная копия законодательства с override: true. Она сама действует в рамках ГК и других применимых норм.
Поэтому задача интерфейса — дать возможность ознакомиться с условиями и зафиксировать их принятие, а не добиться осознанного прочтения каждой строки.
Как это сделано в Trusty Tools
В checkout Trusty нет набора обязательных чекбоксов.
Перед кнопкой одна строка:
Нажимая «Подтвердить заказ», вы принимаете условия Публичной оферты и даёте Согласие на обработку персональных данных в соответствии с Политикой конфиденциальности.
Оферта, политика и само согласие оформлены отдельными ссылками. Согласие сформулировано текстом и привязано к конкретному действию — нажатию кнопки.
Так мы интерпретировали требование «отдельно».
Без дополнительного:
<input type="checkbox" required>
существование которого закон почему-то забыл указать в спецификации.
Мы свою спецификацию написали.
Сначала основание. Потом интерфейс
Нормальный порядок здесь такой же, как в остальной разработке:
- Понять, что система делает с данными.
- Определить цель обработки.
- Определить правовое основание.
- Только после этого проектировать интерфейс.
Если требуется согласие — получить его. Если документ должен быть доступен — дать ссылку. Если данные нужны для исполнения заказа — не добавлять чекбокс автоматически только потому, что поле называется phone.
Если cookie хранит view=list — не делать из этого событие информационной безопасности.
И не reverse engineer’ить законодательство по чужому production.
Законодатель уже сделал свою часть работы плохо.
Не обязательно помогать ему на фронтенде.
Источники и оговорка
- Федеральный закон № 152-ФЗ, статья 9 — согласие субъекта персональных данных.
- Федеральный закон № 152-ФЗ, статья 3 — основные понятия.
- Федеральный закон № 152-ФЗ, статья 6 — условия обработки персональных данных.
- Федеральный закон № 38-ФЗ «О рекламе», статья 18.
- Федеральный закон № 152-ФЗ, статья 18.1 — политика оператора.
- Гражданский кодекс РФ, статья 438 — акцепт.
Материал посвящён проектированию веб-интерфейсов и не является юридическим заключением для конкретного оператора.
