Как грамотно спрашивать согласие и хранить персональные данные пользователя?
Приветствую!
Как максимально грамотно собирать, хранить и использовать персональные данные (ПД) пользователей, которые выразили на это явное согласие, чтобы потом не иметь возможности вкусить статью 14.3 КоАП РФ с призовым фондом до 500000 рублей, т.к. В случае спорной ситуации факт получения согласия должен предоставить рекламораспространитель (ч. 1 ст. 3 Закона № 38-ФЗ).
Предположим, имеется сайт/приложение, в котором при оформление онлайн заявки - спрашиваем номер телефона посетителя, для:
- Консультация по телефону этого посетителя.
- Дальнейшей рассылки рекламно-информационного материала (если посетитель явно выразил на это согласие).
Если с консультацией все понятно, то с согласием на рассылку возникает несколько юридически-технических вопросов:
1. Публичная оферта (ГК РФ Статья 437): разъясняем посетителю о намерение сбора, хранения и дальнейшего использования его ПД.
2. Акцепт (ГК РФ Статья 438): берем согласие на подписание публичной оферты:
2.1. А как мы его берем, галочкой? Как в случае чего доказать, что посетитель действительно ставил галочку? Ведь любой левый посетитель может указать номер телефона совершенно другого человека и нажать галочку.
2.2. Можно использовать простую подпись в виде СМС/email (если надо работать с почтой) кода (электронный документ, подписанный простой электронной подписью в виде СМС. В соответствии с Федеральным законом от 6 апреля 2011 г. N 63-ФЗ "Об электронной подписи" (далее - Закон об электронной подписи) простая электронная подпись - это электронная подпись, которая создается посредством использования кодов, паролей или иных средств и подтверждает факт формирования электронной подписи определенным лицом. Такого рода согласие может быть выражено в виде ввода СМС-кода, отправленного на телефон субъекта персональных данных при регистрации на соответствующем ресурсе. Документ, с которым было выражено согласие в подобной форме, признается судами в качестве подписанного простой электронной подписью).
2.3. Какие еще варианты?
3. Хранение согласия: если посетитель только указывает номер телефона и ставит галочку, то мы храним его номер и checked: true? - железобетонные аргументы для судьи, помимо возможности указания номера совершенного другого человека. Так проблема еще сильнее обостряется, если необходимо иметь возможность передавать ПД третьим лицам (с договором на бумаге мы можем передавать его классическую подпись, а без бумаги? checked: true?).
3.1. Если попробовать вариант делегировать отправку смс/email кодов стороннему сервису (причем сервис не должен сообщать нам код, а только возвращать true/false по результатам ввода кода посетителем), то опять, что все таки хранить в бд в этом случае?
Почему не хочется использовать смс/email ключи?
- Это дополнительный шанс потерять посетителя на о очередном этапе сбора его ПД.
- Дополнительные технические и финансовые издержки.
- Даже если их использовать, то непонятно, как хранить в бд согласие пользователя.
В качестве нулевого шага я бы сначала спросил - а нужны ли в вашем приложении лишние персональные данные?
Под персональными данными я понимаю почти исключительно номер мобилы, потому что он по факту является полным аналогом гражданского паспорта, и знание его полностью деанонимизирует пользователя.
Тенденция требовать номер мобилы при регистрации охватила сейчас всю отрасль. Его требуют все новые приложения (и не только мессенджеры для смартфонов, где это требование хоть как-то оправдано, но и десктопные). Даже старый добрый Скайп пытается со старых пользователей, зарегистрировавшихся ещё во времена, когда для этого хватало электропочты, вымогать этот номер.
К счастью, есть и обратные примеры, например, видеомессенджер Токс. Достаточно новое приложение, и тем не менее Токс никак не нарушает анонимность пользователя - ему достаточно электропочты.
Может, и вы попробуете идти в этом направлении? Тогда и согласия складировать не потребуется. Заодно будут в корне пресечены подозрения в том, что собрав большой массив ПД, вы будете ими торговать.
Нужны. Хотя бы, для связи "Оставьте номер и мы Вам перезвоним".
Нет, тут другая связь - параноики, не желающие сорить своим номером мобилы направо и налево, заодно и не желают, чтобы им перезванивали.
К сожалению, не только номер. А ФИО, данные паспорта, разные адреса (не только прописка), clientID от Метрики, куки и много остальной информации.
Понятно, что не только номер, но и много чего лишнего. Однако имея один только номер вашего мобильного телефона, наши "органы" легко восстанавливают весь этот объёмный массив. Если захотят, конечно. Отсюда вывод - достаточно не давать им для этого повода.
Судью "по факту" не будет интересовать.
Если судья решит, то будет нарушать.
Всё верно, но требуется небольшая оговорочка - речь идёт только о наших отечественных "судьях", и только в их текущей версии. Сейчас всё население РФ с нетерпением ожидает, когда придёт обновление и появится следующая, кардинально переписанная версия. Возможно, программистам, как части этого населения, тоже стоит не торопиться.
Потребуется, т.к. с человеком необходимо хотя бы связаться, чтобы начать диалог, а связаться как? Телепатией?
Я уже приводил примеры софта, умудряющегося авторизовать нового пользователя без нарушения его анонимности. Авторизация - это единственный вид диалога, которого не сможет избежать самый параноидальный параноик. А все остальные виды диалога - от лукавого. Вообще-то, когда инициативу начала диалога берёт на себя приложение (ну или его создатели), то это выглядит подозрительно. По-правильному, эта инициатива должна быть только у пользователя. Если это не так, то пользователь может заподозрить, что диалог затеян только для сбора ПД с целью дальнейшей перепродажи.
Нет, тут другая связь - параноики, не желающие сорить своим номером мобилы направо и налево, заодно и не желают, чтобы им перезванивали.
Я не про это, а про например: мы магазин электроники, человек зашел на наш сайт и хочет (реально хочет) консультацию, для чего жмет на соответствующую кнопку и просит ему перезвонить. Телефон оставлен и как только мы соберемся ему позвонить == становимся под статью о ПД, со всеми вытекающими.
Всё верно, но требуется небольшая оговорочка - речь идёт только о наших отечественных "судьях", и только в их текущей версии
Неизвестно, когда наступит "следующая" версия, а работать приходится уже сейчас.
Согласие на обработку ПД это не часть оферты какой-то, а отдельный документ. Где всё чётко и по пунктам. Не прокатит вывалить +100500 страниц текста, а потом кивать, мол там среди всего было и согласие.
Хранить в базе не только true, а факт отправки смс (номер транзакции или что там есть у вас от оператора, время отправки и номер как минимум).
Если можно просто вписать номер от балды и поставить галочку, то это ваш попадос, потому что задача идентификации участника соглашения - ваша обязанность.
Так же будет минусом отсутствие отображения данного согласия в личном кабинете.
Согласие на обработку ПД это не часть оферты какой-то
Я про "часть" не говорил.
Не прокатит вывалить +100500 страниц текста, а потом кивать, мол там среди всего было и согласие
Не прокатит и хорошо, особенно, что я об этом тоже не говорил.
а факт отправки смс (номер транзакции или что там есть у вас от оператора, время отправки и номер как минимум)
А вот это уже интереснее. Но проблема все таки остается и заключается в том, что в случае разбирательств - оператор ПД должен будет доказывать, что он не имел возможности подделать согласие пользователя.
Если можно просто вписать номер от балды и поставить галочку, то это ваш попадос
Да, номер нужно подтверждать, как бы тяжко это не выглядело.
Михаил Р., В пункте 1, вы именно это и говорите.
Подтверждается в совокупности, вы добросовестно отправили код и оператор может это подтвердить. Наличие в вашей бизнес-логике требования этого кода. Разграничение в базе данных, что крутить там кто попало данные не может.
Средний
Простой
