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

Поэтому приватность и безопасность данных сейчас сложно переоценить. В большинстве IT-компаний это понимают и работают над собственными инструментами защиты (Apple, например, на каждой презентации делает особый акцент). Страны, в свою очередь, регулируют всё это специальными законами.

Основными из них являются Европейский General Data Protection Regulation (GDPR) и, принятый в Калифорнии, California Consumer Privacy Act (CCPA). Сегодня подробно разберёмся, что это за законы, чего требуют и как внедрить их поддержку в свой сервис, сайт или мобильное приложение.

Это первая статья из цикла про приватность на iOS, где поговорим не только про законы, но и про изменения в политике App Store, AppTracking Transparency и IDFA.

Дисклеймер. Статья затрагивает только техническую реализацию, как один из вариантов и не является руководством (в вашем случае реализации скорее всего будет отличаться). Перед реализацией советуем проконсультироваться с юристом по данным вопросам.

Что такое персональные данные

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

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

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

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

Оба этих закона для мобильного разработчика — основные регулирующие документы для работы с персональными данными на территории ЕС и США. Поговорим про каждый отдельно и на примере iFunny расскажем, как именно их внедрить в своё мобильное приложение.

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

GDPR

General Data Protection Regulation (GDPR) регулирует защиту данных и приватности на территории Европейского Союза, а также их передачу во вне. Цель — дать человеку контроль над обработкой и передачей своих персональных данных.

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

Небольшая справка по терминам GDPR:

• Контроллер данных — тот, кто собирают данные о пользователях, находящихся или проживающих на территории ЕС;

• Обработчик данных — тот, кто обрабатывает данные от имени контроллера (например, поставщик облачных услуг);

• Субъект данных — физическое лицо, чью данные обрабатываются;

Контроллеры и обработчики должны принимать меры по защите данных, а бизнес-процессы — учитывать это и разрабатываться с учётом конфиденциальности (например, использовать псевдонимизацию или полную анонимность).

Контроллеры должны раскрывать информацию о любом сборе данных, рассказывать законную основу и цель обработки данных, а также указывать, как долго хранятся данные и передаются ли они каким-либо третьим лицам или за пределы ЕС. Субъект данных имеет право запросить копию или удаление данных.

Теперь о том, как и когда данные пользователей могут быть обработаны.

Для обработки пользовательских данных нужно учитывать хотя бы одно юридическое основание (в разработке мобильных приложений в основном применяются 1 и 6 пункты):

1. Личное согласие пользователя на обработку своих персональных данных.

2. Выполнение договора с пользователем или для выполнения задач по его просьбе, находящегося в процессе заключения договора.

3. Соблюдение юридических обязательств контроллера данных.

4. Защита жизненно важных интересов пользователя.

5. Выполнение задачи в общественных интересах или в рамках официальных полномочий.

6. Представление интересов контроллера или третьей стороны, если эти интересы не перекрываются интересами пользователя или его правами в соответствии с Хартией основных прав.

Что важно учитывать при запросе согласия на обработку данных: 

1. Запрос должен быть явным для каждой цели использования данных.

2. Описания целей должны быть лаконичными, прозрачными и простым языком. Форма с описаниями должна быть легкодоступной.  

3. Несколько целей обработки нельзя объединить в один запрос подтверждения.

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

Контроллеры должны проинформировать пользователей о сборе данных, правовых основах обработки, сроках хранения, передаче третьей стороне и/или за пределы ЕС. А также о правах на неприкосновенность частной жизни, включая право в любое время отозвать согласие на обработку данных и право просматривать свои персональные данные. Также контроллер данных обязан выполнять некоторые требования по запросу пользователя:

• предоставлять список категорий обрабатываемых данных и целей обработки;

• предоставлять копию собранных данных;

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

• прекращать обработку данных;

• удалить все собранные данные.

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

Также GDPR требует, чтобы в организации был назначен ответственный за защиту данных Data Protection Officer (DPO). DPO — эксперт по законодательству и защите данных, который мониторит выполнение GDPR, проверяет процессы обработки, получения и хранения данных с точки зрения их защиты.

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

CCPA

California Consumer Privacy Act (CCPA) — закон Калифорнии по расширению прав на приватность и защиту данных. Он, как и GDPR, тоже экстратерриториальный и действует на любую организацию, которая обрабатывает данные жителя Калифорнии и удовлетворяет по крайней мере одному из пороговых значений:

• имеет годовой валовой доход свыше 25 миллионов долларов;

• покупает, получает или продает личную информацию 50 тысяч или более пользователей;

• зарабатывает более половины своего годового дохода от продажи личной информации пользователей.

Сам же закон дает жителям Калифорнии право:

• знать, какие персональные данные о них собираются;

• знать, продаются ли (или сообщаются) их персональные данные и кому;

• запрещать передачу или продажу данных третьим лицам;

• получить доступ к данным, которые были собраны;

• удалить любые персональные данные.

Для выполнения этих прав CCPA применяет следующие требования к организации:

1. На сайте организации должна быть ссылка с текстом «не продавайте мою личную информацию» (в мобильном приложении это может быть кнопка). Она даёт право отказаться от передачи персональных данных третьим лицам.

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

3. Организация должна обновить свою политику безопасности и включить в неё описание прав резидентов Калифорнии относительно защиты их данных, согласно CCPA.

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

Многие положения CCPA схожи с GDPR, но есть и некоторые различия между этими двумя законами, помимо территорий.

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

По GDPR пользователь может разрешить использование данных в конкретных целях (причем список целей он может настраивать), а по CCPA пользователь может лишь запретить передавать данные третьим лицам.

Фреймворки от IAB

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

Для этого мы сотрудничаем с организацией Interactive Advertising Bureau (IAB), которая разрабатывает стандарты, проводит исследования и оказывает юридическую поддержку индустрии онлайн-рекламы. 

Они разработали два открытых фреймворка: 

1. IAB Europe Transparency and Consent Framework (TCF) — чтобы «позволить веб-сайтам, рекламодателям и их партнёрам по рекламным технологиям получать, записывать и обновлять согласие потребителей на обработку их персональных данных в соответствии с GDPR».

2. IAB CCPA Compliance Framework — для рекламных площадок (издателей) и IT-компаний.

Именно их мы взяли за основу для работы с CCPA и GDPR.

Реализация IAB CCPA Compliance Framework

IAB CCPA Compliance Framework используется для реализации соответствия iFunny требованиям CCPA.

Что требует фреймворк от рекламных площадок, которые используют данные жителей Калифорнии для персонализированной рекламы:

• говорить о своих правах в соответствии с CCPA;

• объяснять, что произойдёт с данными пользователей; 

• уведомлять технологические компании-партнёры о раскрытие такой информации;

• включать ссылку «не продавать мою личную информацию» в приложения и сайты (когда пользователь нажимает на неё, то компаниям-партнёрам отправляется его решение).

Это налагает строгие ограничения на использование данных издателями и технологическими компаниями только в тех конкретных и ограниченных деловых целях, которые разрешены в соответствии с CCPA.

Внедрение

Гайды по фреймворку можно найти на официальном сайте: описание и технические спецификации.

Шаг 1. Подписываем соглашение по использованию фреймворка — Limited Service Provider Agreement (LSPA). 

Для этого нужно подать заявку и указать:

• цифровые активы, где будет использоваться фреймворк — веб-сайты и мобильные приложения (платформы тоже, iOS или Android);

• юридические данные подписывающей стороны;

• контактный email.

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

Для iFunny в качестве цифровых активов мы указали мобильные приложения для iOS и Android, а также веб-сайт ifunny.co.

Шаг 2. Вносим изменения в политику конфиденциальности для пользователей в соответствии с CCPA. 

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

В iFunny используется отправка запросов на специальный email, где все входящие документируются, обрабатываются и удовлетворяются в установленные CCPA сроки. Для примера можно посмотреть нашу политику конфиденциальности.

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

Шаг 3. Выполняем требования фреймворка непосредственно в приложениях.

Независимо от платформы алгоритм такой:

1. При запуске приложения вызывается метод API iFunny и определяет местоположение пользователя по его IP-адресу (помним, что CCPA применяется к находящимся на территории Калифорнии).

2. Если пользователь попадает под действие CCPA, приложение вызывает другой метод API, который подтягивает информацию о том, давал ли пользователь разрешение на передачу данных третьим сторонам для персонализации рекламы.

Дальнейшие шаги в работе приложения напрямую зависят от предыдущих действий пользователя:

• Если пользователь запретил передавать данные третьим сторонам — приложение проверяет время, которое прошло с момента решения (если более 12 месяцев, то всплывает поп-ап-диалог с запросом о передачи данных третьим сторонам).

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

3. Для принятия решения о передаче данных третьим сторонам, пользователю показывается поп-ап-диалог. Он говорит, что для продолжения работы требуется явное решение пользователя об использовании данных, и даёт ссылки на политику конфиденциальности, описание того, как именно будут использованы данные и его права согласно CCPA. Диалог нельзя пропустить или закрыть, пока не нажмешь на одну из кнопок — «Do Not Sell My Personal Information» и «I agree to». Кнопки, кстати, одинакового размера, шрифта и цвета.

Если пользователь выбрал опцию «Do Not Sell My Personal Information», то его данные не передаются третьим сторонам (в том числе рекламным партнёрам).

4. Когда пользователь сделал выбор, приложение сохраняет его решение на нашем сервере, вызывая метод API iFunny. 

Затем приложение формирует privacy string (строку согласия), формат которой был разработан IAB. В ней указано, является ли iFunny подписантом LSPA (да, является) и какое решение принял пользователь о передаче его персональных данных. 

Затем строка сохраняется в персистентном хранилище NSUserDefaults (iOS) или  SharedPreferences (Android). Её можно извлечь по ключу IABUSPrivacy_String. 

Privacy string поддерживается всеми рекламным партнёрами, которые извлекают её из хранилища для получения данных о согласии пользователя. Нельзя отправлять ни одного запроса и передать данные пользователя, пока данная строка не сформирована.

5. Если пользователь решит изменить свой ответ, то в любой момент может вызывать аналогичный диалог через настройки приложения. Новое решение будет передано на сервер, а privacy string сгенерирована заново.

Реализация IAB Transparency & Consent Framework

IAB Transparency & Consent Framework (TCF) используется для реализации соответствия iFunny требованиям GDPR.

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

TCF вводит третью сторону в отношения между издателями и поставщиками рекламы — Consent Management Provider (CMP). Это организация, которая обеспечивает прозрачность выбора для пользователя: какие данные, каким рекламным партнёром (вендором в терминологии IAB) и с какой целью он согласен передавать. А также реализует права на выражение несогласия и запрета на передачу данных. Помимо этого, CMP хранит решение пользователя и информирует о нём как вендоров, так и издателя. Посмотреть, что представляет собой TCF с точки зрения CMP можно здесь.

IAB даёт возможность использовать в приложении как сторонний CMP, так и свой собственный после регистрации компании в качестве CMP (гайд тут). 

Для получения регистрации нужно, чтобы ваше реализация прошла проверку на соответствие правилам фреймворка. В случае веб-сайтов IAB предоставляет программу-валидатор или запрашивает скриншоты и описание работы CMP. 

Внедрение

В iFunny мы выбрали вариант с регистрацией собственного CMP. Он позволяет максимально нативно и прозрачно для пользователя встроить данный функционал в приложение. Поэтому весь дальнейший процесс интеграции TCF в мобильное приложение будет показан именно для варианта с собственным CMP.

Шаг 1. Регистрируем CMP.

1. Отправляем заявку: указываем юридическую информацию, контактный email и оплачиваем сервисный взнос. 

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

3. Полное прохождение валидации при наличии прототипа и проработанного дизайна занимает день или более. Поздравляем! Вы — счастливый обладатель новенького CMP с уникальным ID.

Шаг 2. Вносим изменения в политику конфиденциальности для соответствия GDPR. 

Указываем способ, с помощью которого пользователь может направлять запросы на предоставление собранных данных, прекращение их сбора и удаление. Мы выбрали email.

Шаг 3. Приступаем к реализации в приложении.

Первые шаги в алгоритме аналогичны CCPA:

1. Проверяем, попадает ли пользователей под действие GDPR через проверку IP, а затем — принимал ли он решение о передаче данных. 

Разница появляется на стадии отображения поп-ап-диалога согласия пользователя.

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

Сведения о том, какой вендор, для каких целей и как обрабатывает данные, TCF предоставляет в виде списка Global Vendor List (GVL). Он содержит развёрнутое описание каждой цели и метода использования данных, а ещё — ссылки на политики конфиденциальности каждого вендора, которые должны быть отображены в диалоге. Поэтому перед показом диалога приложение iFunny всегда получает закешированную актуальную версию GVL с сервера (срок жизни подобного кэша на сервере составляет неделю, потом сервер получает новую версию GVL). 

Кроме того, мы получаем с сервера два актуальных списка интегрированных вендоров: первый — зарегистрированные в IAB; второй — не входящие в IAB.

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

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

— Информация про обработку данных, каких именно и каким образом (идентификаторы, история действий).

— Информация о том, что третья сторона (вендоры) хранят и/или получают доступ к личным данным, а также ссылка на список таких вендоров, входящих в IAB.

— Информация о последствиях согласия или несогласия с данными положениями.
— Информация о сфере действия данного соглашения (в нашем случае это применение для работы сервиса iFunny).

— Информация о том, что пользователь может отозвать свое согласие в любое время.

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

— Ссылка с детальной информацией о вендорах, не входящих в IAB, и ссылками на политику конфиденциальности каждого.

— Call to action кнопки для подтверждения выбора пользователя, отказа от предоставления данных пользователя и кастомизации выбора.

— Списки и информация, которые приложение формирует на основе вендоров и GVL (в нём есть названия и legal description):

• Список целей (purposes), в которых вендоры обрабатывают информацию. 

• Информация об особых целях (special purposes), которые вендоры используют для обработки данных.

• Список методов (features) обработки информации вендорами. 

• Информация об особых методах (special features), которые вендоры используют для обработки данных.

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

Важно:

• По умолчанию все кнопки выбора на втором уровне диалога находятся в состоянии «не разрешено» (требование GDPR).

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

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

4. Когда пользователь подтверждает свой выбор, приложение формирует особую строку TC String, которая содержит данные о выборе и дату формирования. 

Строка сохраняется на серверах iFunny и в персистентном хранилище NSUserDefaults (iOS) или SharedPreferences (Android), чтобы все вендоры могли получать к ней доступ. Сама строка TC String хранится по ключу IABTCF_TCString. 

Ещё при каждом запуске приложения в эти же хранилища сохраняются значения с доступом для каждого вендора:

1. IABTCF_CmpSdkID с ID нашего CMP.

2. Версию CMP IABTCF_CmpSdkVersion (внутренняя версия, используемая в приложении).

3. Флаг IABTCF_gdprApplies, сигнализирующий о том, находится ли пользователь в зоне GDPR.

Если пользователь не давал согласия на передачу данных, то к рекламным партнёрам они больше не попадут. До тех пор, пока пользователь не решит изменить ответ в любой момент (либо в настройках приложения, либо через email). Новое решение будет сохранено на серверах iFunny, а строка TC String сгенерируется заново.

Заключение

Законы CCPA и GDPR — лучшие примеры регулирования и защиты персональной информации и не следовать им попросту нельзя. Иначе можно лишится многих мобильных рынков и пользователей. При этом внедрение и их поддержка в своих сервисах это задача не только для юристов, но и для программистов, UI-дизайнеров и других команд.

Существующие фреймворки, например от IAB, делают процесс гораздо проще. Пока их довольно мало, все они одинаково сложны в реализации и поддержке, и кроме того покрывают законодательство по персональным данным только в ЕС и США. Очень ждем нового более общего фреймворка и желательно с альтернативами.