РКН не спит - Методичка по оформлению ПД 3.0

[Tommi]

Если этот 13 летний (будучи зареганым на форуме как 14 летний) потом жалобу накатает в РКН (просто, потому что он так захотел).
Отвечать то мы будем, мне кажется, не помогут правила, где указано, что регистрация с 14 лет)

 

[Matew]

Ничего, скоро еще детям и подросткам соцсети заблокируем, и заживем!

 

[Sadorimatsu]

Если этот 13 летний (будучи зареганым на форуме как 14 летний) потом жалобу накатает в РКН (просто, потому что он так захотел).
Отвечать то мы будем, мне кажется, не помогут правила, где указано, что регистрация с 14 лет)

Оператор не обязан угадывать возраст, он обязан принять разумные меры. 152-ФЗ и разъяснения РКН не требуют от оператора верифицировать паспорт каждого пользователя. Достаточно того, что называется соблюсти базовые требования, например поле, что у вас регистрация строго с 14 лет или чекбокс подтверждающий это, оговорка в Политике и Правилах, что сервис для лиц 14+, данные несовершеннолетних до 14 только с согласия законного представителя. Если эти меры приняты, а пользователь указал неверный возраст, то это его недобросовестность, и она существенно смягчает позицию оператора. Доказать вину за обработку, которую невозможно было выявить техническими средствами, регулятору сложно.

Что делать в данной ситуации?

1. Как только факт возраста стал известен (хоть из жалобы, хоть из переписки, неважно), основание обработки отпадает (ч. 1 ст. 6). Дальнейшее хранение уже будет нарушением.
2. Предварительно зафиксировать действия в журнале регистрации пользователя, когда и какие данные он указывал и подтверждал, формулировку Политики, запись о блокировке и удалении с датами. Если РКН придёт с проверкой по жалобе, вся защита оператора - это подтверждение по логам, что меры приняты, а после получения информации данные удалены немедленно.
3. И конечно сразу же удалить учётку полностью (ст. 21), независимо от причины, даже если он оказался в бане, а он подал из-за этого жалобу.

Ответственность ребёнка - нулевая. Административная ответственность наступает с 16 лет (ст. 2.3 КоАП), а указание неверного возраста при регистрации вообще не состав и за это уже будет отвечать его родитель/опекун. Ответственность за обработку ПД без согласия несёт только оператор. Так что, единственный для вас вариант, своевременно зафиксировать, принять меры и документально и по форме регистрации себя защитить, чтобы журнал всё фиксировал. Даже если к вам обратится РКН, он как минимум потребует у вас логи с этим пользователей и если всё будет в порядке, то к вам претензий не будет. Правда вот не докапаются ли к другим вещам, тут никто гарантий не даст.

 

[NIKO911]

Вот дополнение к модификации шаблонов - карусель ресурсов. Скрываются аватары, ники, ID (все это скрыто и в коде - при инспектировании).

Вот еще одна модификация шаблона на цитирование сообщений. Скрываются аватары, ники, ID (все это скрыто и в коде - при инспектировании).

Запрос в базу данных MariaDB для очистки сообщений от ников, созданных ранее, до внесения изменений в файл перевода xfrm_resource_thread_create

Для Russian (RU):

UPDATE xf_post
SET message = REGEXP_REPLACE(message, '^([^\\n]+) добавил\\(а\\) новый ресурс:', 'добавил(а) новый ресурс:')
WHERE message REGEXP 'добавил\\(а\\) новый ресурс:';

Для English (US):

UPDATE xf_post
SET message = REGEXP_REPLACE(message, '^([^\\n]+) Submitted a new resource:', 'Submitted a new resource:')
WHERE message REGEXP 'Submitted a new resource:';

Запрос в базу данных MySQL для очистки сообщений от ников, созданных ранее, до внесения изменений в файл перевода xfrm_resource_thread_create

Для Russian (RU):

UPDATE xf_post
SET message = REGEXP_REPLACE(message, '^([^\\n]+) добавил\\\\(а\\\\) новый ресурс:', 'добавил(а) новый ресурс:')
WHERE message REGEXP 'добавил\\\\(а\\\\) новый ресурс:';

Для English (US):

UPDATE xf_post
SET message = REGEXP_REPLACE(message, '^([^\\n]+) Submitted a new resource:', 'Submitted a new resource:')
WHERE message REGEXP 'Submitted a new resource:';

 

[NIKO911]

А как скажем быть в таком моменте:
Скажем есть пользователь, он зарегистрирован. Регистрация проходит по процедуре верификации по почте. И предположим что у пользователя что то случилось с почтой (ее заблокировали, удалили, взломали). И приходит письмо от пользователя (с другой почты) с требованием удалить его персональные данные или подкорректировать (скажем изменить его ПД в форме почты или пароля). Пользователь может не знать своего пароля скажем. Как реагировать в таких случаях? Ведь нельзя верифицировать данного пользователя и понять - что это именно этот пользователь, а не кто то другой. Или это так же произойдет у него при обращении в РКН - не свяжутся все его ПД именно с этим пользователем и ему откажут? Нужно ли тогда как дополнительная страховка - вводить правила по этому поводу - при не возможности верифицировать через почту пользователя все ПД аккаунта будут удалены или же их обезличить...?

 

[Sadorimatsu]

А как скажем быть в таком моменте:
Скажем есть пользователь, он зарегистрирован. Регистрация проходит по процедуре верификации по почте. И предположим что у пользователя что то случилось с почтой (ее заблокировали, удалили, взломали). И приходит письмо от пользователя (с другой почты) с требованием удалить его персональные данные или подкорректировать (скажем изменить его ПД в форме почты или пароля). Пользователь может не знать своего пароля скажем. Как реагировать в таких случаях? Ведь нельзя верифицировать данного пользователя и понять - что это именно этот пользователь, а не кто то другой. Или это так же произойдет у него при обращении в РКН - не свяжутся все его ПД именно с этим пользователем и ему откажут? Нужно ли тогда как дополнительная страховка - вводить правила по этому поводу - при не возможности верифицировать через почту пользователя все ПД аккаунта будут удалены или же их обезличить...?

Если нельзя верифицировать пользователя, то как реагировать на запрос об удалении/изменении? Никак. По ч. 3 ст. 14 152-ФЗ запрос должен содержать сведения, позволяющие идентифицировать субъекта (данные документа, сведения о регистрации у оператора и т. п.), обычно то, что он заполнял первоначально. Письмо с произвольной почты этому не соответствует. На это отвечаем отказом с разъяснением, как подтвердить личность: написать с зарегистрированного адреса или указать сведения, которые знает только владелец, например: дата регистрации, содержимое последних сообщений и т.п.

Если изменить пароль/почту по запросу письма? Тем более нет. Смена реквизитов доступа по непроверенному запросу - это передача контроля над аккаунтом 3-им лицам. Владелец восстанавливает доступ стандартным сбросом пароля на исходный адрес. Если почта утеряна, то через подтверждение личности по примерам выше.

А если он обратится в РКН - ему не свяжут данные с аккаунтом и откажут? Да, та же фильтрация. РКН требует подтверждения принадлежности данных обратившемуся (проще всего через Госуслуги, где личность подтверждена автоматически). Без этого жалобу на удалить его данные не рассматривают по существу. Так что реальный владелец упрётся в ту же стену - механизм одинаков на всех уровнях.

Нужно ли правило, что при не возможности верифицировать через почту - удаляем всё? Нет, опасное правило. Удаление по непроверенному требованию превращается в способ уничтожения чужих данных одним письмом, лишает данных реального владельца и само является неправомерной обработкой. Правильная формулировка для Правила должна быть примерно такой: "запросы обрабатываются после подтверждения принадлежности данных заявителю; запросы без подтверждения отклоняются с разъяснением порядка".

Проще говоря, если юзер не может подтвердить никак принадлежность к своим данным, то можем слать его лесом.