Удалять персональные данные пользователя по его запросу, чтобы продукт соответствовал законам CCPA или GDPR, можно по-разному. Хоть вручную каждую заявку на почте разбирать. Главное — сделать процесс максимально простым и понятным для пользователя. А это уже хороший повод задуматься о некоторой автоматизации.

В статье на примере мобильного приложения iFunny расскажу про систему обработки запросов на удаление данных. Теперь заявки приходят сразу конкретизированными, а саппорт тратит в 2 раза меньше времени на их рассмотрение.

Под катом — о том, как происходит приём заявки, обработка, выставление статусов, хранение в системе учёта и так далее.

В 1890 году американские юристы Сэмюэль Уоррен и Луис Брандейс сформулировали понятие «приватность» как «право быть предоставленным самому себе». Они говорили, что приватность в опасности из-за новых изобретений и методов ведения бизнеса. Кажется, они были правы — сейчас это практически сбывшееся пророчество, а тема безопасности данных одна из самых актуальных. 

Всё это регулируют основные законы CCPA или GDPR (про них отдельно рассказывали) — они сдвинули проблему с мёртвой точки, но «подарили» компаниям много допработы по внедрению и соблюдению правил. 

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

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

Делаем систему удаления персональных данных

Изначально процесс был простой — единичные запросы принимались и исполнялись службой поддержки без какого-либо серьёзного учёта и автоматизации. Такой подход вполне оправдан для компаний с небольшой аудиторией, но у iFunny больше 70 млн установок, миллионы активных пользователей ежедневно и куча интеграций с внешними площадками. Ситуация чуть сложнее.

Решили облегчить себе жизнь — формализовать и автоматизировать процесс работы с заявками на удаление данных. 

Цели

Основной целью стало выполнение требований законодательств и правил Apple (скорее всего что-то подобное появится и у Google в будущем).

Главные требование законодательств, в частности, CCPA и GDPR:

• удаление данных не должно быть сложнее, чем процесс их предоставления;

• если для создания аккаунта достаточно нажать одну кнопку, то для удаления необходимо выполнить сопоставимые по сложности действия.

Задачи

1. Создать систему, через которую пользователь сможет запросить удаление данных в автоматическом режиме.

2. Научиться удалять все личные данные пользователя, которые он когда-либо оставлял в сервисе. То есть почту, аккаунты соцсетей, геолокацию, пол, возраст и всё остальное.

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

Требования

Требования к системе разрабатывали сами на основе законов и правил сервисов (например, Facebook и IAB). На выходе получили такой список:

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

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

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

4. Система безопасна. Злоумышленник не может неавторизованно удалить данные другого пользователя (а это удаление аккаунта).

5. Пользователь понимает, что будет происходить с его данными и аккаунтом. Нужно отправить письмо с прозрачным описанием процесса.

6. Саппорт удобно и быстро работает с запросами. Есть детальная инструкция по обработке заявок, а также отдельная страница в нашем административном портале со списком всех заявок, фильтрами по статусам и кнопками с основными действиями по заявкам (например, удалить личные данные).

Что получилось

Лонг стори шорт: требования выполнили, систему сделали. Она включает в себя: 

• Страницу формирования заявки (на сайте и в приложении). 

• Страницу проверки статуса заявки (только на сайте).

• Административный портал со списком всех заявок и фильтрацией по статусам, а также со страницей обработки.

• А также бэкенд:

  • API для формирования заявок и проверки статуса;

  • API для административного портала;

  • хранение заявок; 

  • бизнес-логика для автоматизации статусов заявок;

  • автоматическая верификация пользователя по почте;

  • отправка письма пользователю по статусам заявок;

  • удаление данных пользователя.

Подробнее расскажу, как происходит процесс удаления персональных данных — от отправки заявки пользователем до обработки и проверки статусов. А в конце поделюсь полным алгоритмом в виде блок-схемы.

Приём запроса на удаление данных

Жизненный цикл заявки можно представить в виде конечного автомата с одним из состояний, которое меняется в зависимости от этапа обработки:

• Waiting for email confirmation — заявка ждёт подтверждения от пользователя;

• Received — заведена в системе учёта и готова к работе;

• In progress — взята в работу непосредственным исполнителем;

• Waiting for user response — потребовались дополнительные сведения, запрос на которые был отправлен пользователю;

• Done — исполнена;

• Rejected — отклонена.

Работа начинается с запроса пользователя, который может поступить из разных источников. Сейчас мы поддерживаем подачу заявки через Facebook, приложение и форму на сайте.

Приём запроса через Facebook

Facebook начал внедрять свою систему для запросов на удаление данных в 2018 году, а в 2020-м она стала обязательной для всех приложений, которые используют платформу.

Работает это так: каждый раз, когда пользователь авторизуется или подключает свой Facebook-аккаунт к внешнему приложению или сайту, он даёт доступ к своим личным данным (по умолчанию — имя/фамилия и почта, дополнительно — пол, возраст, геолокация, место работы и другие).

На этой странице есть список сервисов, которые получили доступ к вашей информации. Там же можно отозвать права, после чего приложение обязано удалить и прекратить использовать данные. Об этом Facebook должен как-то сообщить, и для этого есть два способа:

1. Если в приложении нет автоматических запросов на удаление — Facebook даёт ссылку на страницу с инструкциями по удалению данных и почту для связи. 

2. Если в приложении есть автоматизированная система для получения заявок:

• приложение предоставляет Callback URL, поддерживающий определённый интерфейс;

• когда пользователь удаляет приложение из настроек, Facebook достаёт Callback;

• приложение формирует заявку и отправляет в ответ её номер и URL страницы для проверки статуса заявки.

В итоге для поддержки механизма от Facebook требуется: Сallback URL для интеграции, автоматический приём заявки, формирование её номера и страница для проверки статуса.

У нас второй вариант. Поэтому проверяем, существует ли в нашей системе пользователь, затем передаём Facebook либо отказ с причиной «пользователь не найден», либо технические данные с идентификатором запроса и ссылкой для отслеживания статуса заявки. 

А заявка тем временем переводится в статус Received (получена).

Приём запроса через приложение или сайт

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

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

Затем на указанную почту отправляется письмо со ссылкой для подтверждения, а заявка переводится в статус Waiting for email confirmation (ждёт подтверждения от пользователя).

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

Работа с заявкой

Когда пользователь заполнил форму на сайте или в приложении, заявка со статусом Received попадает в административный портал, а наши саппорт-специалисты получают уведомления на почту и в Slack.

Именно на этом портале происходит основная работа с заявками, а точнее на двух конкретных страницах:

• страница со списком всех заявок, где собраны основные сведения по каждой заявке (user id, email, request id, дата формирования и текущий статус с фильтрами);

• страница для работы с конкретной заявкой.

Как происходит работа с заявкой по шагам

Шаг 1. Заявке присваивается статус In progress (в работе) и проводится важная ручная проверка — соответствует ли почта, с которой была подтверждена заявка, почте найденного пользователя. Так мы убеждаемся, что не удалим чужие данные. На самом деле эта проверка автоматически происходит и на этапе создания заявки, и на этапе подтверждения почты.

Шаг 2. Затем автоматически проверяются сведения. Если чего-то не хватает, заявка переходит в статус Waiting for user response (нужна дополнительная информация), а пользователю отправляется письмо с дополнительными вопросами:

• если пользователь отвечает на письмо и даёт нужную информацию, заявка возвращается в In progress;

• если в течении 30 дней пользователь молчит, заявка закрывается со статусом Rejected.

Шаг 3. Если запрос валиден, дальнейшая обработка зависит от того, откуда он был направлен. Этот этап делаем вручную.

— Если заявка из Facebook

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

С одной стороны — мы добавляем дополнительный шаг ручной обработки и дополнительное действие, которое должен выполнить пользователь. С другой — так можно избежать неприятных последствий, о которых он может даже не догадываться (например, не сможет больше войти в аккаунт iFunny через Facebook).

— Если заявка из приложения или сайта

Удаляем данные пользователя и деактивируем аккаунт. Именно деактивируем, а не удаляем, потому что в течение 30 дней он может захотеть его восстановить. 

Это был спорный момент во время разработки системы. Мы удаляем все персональные данные пользователя, но оставляем загруженный им контент (он никому не виден). Законы этот момент не регламентируют, а мы не злоупотребляем правом на использование контента, поэтому решили оставить для пользователя возможность передумать. Но через 30 дней после деактивации аккаунта контент удаляется.

Шаг 4. Заявка автоматически переводится в статус Done, пользователю приходит письмо. Оно также отправляется и в том случае, если на каком-то этапе заявка перешла в статус Rejected. 

Человек в любой момент может узнать статус заявки на нашем сайте — ссылку мы добавляем в каждое письмо и показываем после отправки заявки через приложение или сайт.

Полный алгоритм обработки заявки

И, наконец, полный процесс работы с запросом по удалению персональных данных выглядит так:

Система запущена и работает по плану. Обошлось без неожиданных сюрпризов — продолжаем следить и думать, как её ещё можно улучшить.

Результаты внедрения системы удаления персональных данных

1. Пользователю быстрее и проще нажать кнопку в приложении, а не писать письмо.

2. Пользователь может проверить статус своей заявки в любое время.

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

4. Саппорт тратит в 2-3 раза меньше времени на весь цикл обработки заявки.

5. Выполнили требования законодательств и Apple.