что значит политика конфиденциальности для приложения

Политика конфиденциальности и условия использования как обязательный атрибут IT продукта

Меня зовут Александр Явтушенко и уже 4 года я работаю в сфере IT права. Последнее время все чаще сайты и приложения, которые я сопровождаю по части правового обеспечения их деятельности, начинают задумываться или непосредственно внедрять различные правила и политики связанные, в первую очередь, с процедурами сбора, обработки и хранения персональных данных. В большинстве случаев это вызвано страшным словом GDPR (англ. General Data Protection Regulation) — нормативным актом Европейского Союза, который регламентирует любые действия, связанные со сбором, обработкой, хранением и последующим использованием полученных от граждан ЕС персональных данных.

Основной проблемой IT разработчиков, которые не хотят привлекать профильных юридических специалистов в сфере защиты Personal Data (далее — PD) и обеспечения правильного режима конфиденциальности является смешивание в одном документе (зачастую его «обзывают» условиями использования сайта или пользовательским соглашением) как норм регламентирующих поведение пользователя (различных групп пользователей) на сайте или в приложении, так и положений об обработке персональных данных.

Второй глобальной проблемой является тот факт, что у неспециалиста, как правило, отсутствует понимание того, что мало написать какие-то правила, важно идеально знать правовые нормы и правоприменительную практику (как со стороны контролирующих органов, так и судебную) страны регистрации сайта/приложения, а также нормы других стран, которые в определенных случаях могут также распространяться на вас (яркий пример — тот же GDPR в случае работы с данными граждан ЕС).

Это связано с тем, что в регулировании использования PD существует две зоны:

1. Императивная

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

2. Диспозитивная

Хотя в последнее время ЕС, США и Канада все больше внимания уделяют ужесточению работы с персональными данными, до сих пор остается множество норм, которые не имеют строгого характера и предлагают или выбор нескольких вариантов поведения, или и вовсе предоставляют нам возможность прописать самостоятельные регламенты и алгоритмы сбора, обработки и хранения некоторых видов данных. Понимая четкие границы в которых можно «делать что угодно и ничего за это не будет, если мы описали это в пользовательском соглашении», разработчик открывает перед собой возможности не только для тонкой настройки функционала своего приложения/сайта, но и избавляет себя от десятков или даже сотен исков во всех юрисдикциях мира, которые могут посыпаться от чересчур внимательных пользователей.

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

Политика конфиденциальности

Политика конфиденциальности объясняет, как ваша компания использует, обрабатывает, хранит и делится данными, предоставленными пользователями ее услуг и/или веб-сайта. Этот документ должен быть составлен квалифицированным юристом, потому что контролирующие органы (например. Федеральная торговая комиссия США) или суд (если против вас подан иск) могут принять меры против вас за «обман», если в документе есть неточные утверждения. Сегодня законодательство Украины, России, стран Европейского Союза и большинства штатов США требуют политики конфиденциальности, если вы собираете какие-либо персональные данные.

Условия обслуживания (также известные как «Условия использования»)

Если ваш бизнес управляет веб-сайтом, мобильным приложением или требует загрузки программного обеспечения, вам следует применять подготовленные юристом Условия использования. Условия использования — это договор (публичная оферта) между вами и пользователями вашего продукта. Важно учитывать также и то, где разместить Условия на вашем веб-сайте, чтобы убедиться, что он имеет обязательную юридическую силу. Довольно часто для этого посетителю нужно предпринять действие, выражающее его согласие с таким документом (например, нажать на кнопку «Я принимаю Условия»).

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

Кодекс поведения пользователя

Это положение используется для определения ожиданий того, как клиенты могут использовать ваш продукт, а также вашего права на отзыв об их использовании вашего веб-сайта или приложения в ответ на указанные нарушения. На просторах стран СНГ применение такого кодекса не является общепринятым в IT проектах. В то же время, в странах с общей системой права (в основном США и большая часть Великобритании) детальная проработка этого раздела Условий является хорошим превентивным механизмом от большинства судебных исков.

Ограничение ответственности

Это положение освобождает компанию от ответственности за любой ущерб, возникший в результате использования их веб-сайта или продукта. Четкое установление исключений может иметь неоценимое значение в случае возникновения спора с клиентом. Существует, однако, ряд правовых норм, которые не позволяют отказаться от ответственности в определенных случаях, что требует создания «обходных путей» для защиты вашего проекта.

Порядок оплаты

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

Политика отмены (отказа или возврата)

Вы также можете указать положения, объясняющие, как клиент может прекратить свое взаимодействие с вашей компанией, а также любые соответствующие сборы или процедуры возврата. Сюда, как правило, включают условия отказа от рассылок, уведомлений (в том числе push-уведомлений для мобильных приложений), а также различные особенности, связанные с прекращением обслуживания клиента, который приобрел подписку на определенный срок, условия и порядок возврата средств и тому подобное. При разработке этого раздела юридически важно учитывать, потребляется ли ваш продукт/услуга непосредственно в момент ее использования или же результат использования сайта/приложения носит отложенный (пролонгированный) характер. Нередко именно здесь мы прописываем гарантированное GDPR`ом «право быть забытым». В данном случае, хотя и невозможно отказать пользователю в удалении данных о нем, которыми мы располагаем, но возможность определить механизм и форму передачи пользователем такого волеизъявления остается на нашей стороне и неправильно прописанный порядок реализации такого права может иметь серьезные юридические последствия.

К чему ваш продукт получит доступ

Если вашему веб-сайту или приложению потребуется доступ к клиенту на Facebook, в Инстаграм, его электронной почте, расположению или любой другой личной информации, в ваших Условиях должен быть явно указан список этих данных и необходимо, чтобы клиенты согласились предоставить их, прежде чем продолжить использование. Я встречал случаи, когда, вследствие юридически неправильных формулировок, пользователь предоставлял доступ приложению только к тем файлам, которые располагались (датировались) на его устройстве на момент дачи согласия на Условия, но созданные или сохраненные на устройстве файлы уже после согласия под действие Условий не попадали, что в результате вызвало довольно серьезные судебные разбирательства и большие затраты для клиента, который обратился к нам когда было уже слишком поздно.

Сcылки на другие сайты

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

Уведомление об авторских правах

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

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

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

Такое свойство «куки» вызывает необходимость сразу информировать пользователя о сборе данных путем показа соответствующего окна на сайте (в приложении), что подразумевает согласие пользователя с этим путем продолжения использования сайта или приложения (конклюдентные действия). Как правило, этот способ используется на сайтах, где согласие с Условиями использования и Политикой конфиденциальности обычно необходимо только в случае регистрации, совершения покупки или иных действий.

Второй вариант — «заставлять» сразу соглашаться с Политикой конфиденциальности, куда нередко интегрирован раздел об использовании файлов cookie. Этот способ мы обычно используем в мобильных приложениях и ПО.

Таким образом, любой современный IT проект, будь то мобильное приложение, ПО или сайт должны иметь грамотно составленные Условия использования (Пользовательское соглашение), Политику конфиденциальности и Политику использования файлов cookie (может быть отдельным документом или частью Политики конфиденциальности в зависимости от архитектуры проекта).

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

Источник

Соблюдать нельзя нарушать: всё о Политике конфиденциальности

На главные вопросы о персональных данных пользователей вашего приложения или сайта отвечает Анастасия Булатова, юрист 65apps.
Этот материал — конспект нашей статьи на Rusbase.

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

Privacy Policy или Политика конфиденциальности (ПК) — это документ, в котором декларируется IT-продукт — приложение или сайт. Его цель — информировать пользователя о том, как компания использует его данные. ПК определяет, что относится к персональным данным пользователя, как владелец приложения или сайта их собирает, обрабатывает, хранит и кому передает.

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

Например, к персональным данным не относят отдельный номер телефона как набор цифр или отдельный e-mail адрес. Но если телефон связан с конкретными ФИО человека, а e-mail состоит из имени и фамилии владельца — это уже персональные данные.

Известен случай в судебной практике, когда персональными данными были признаны обезличенный id пользователя вместе со временем просмотра веб-страницы, URL, HTTP referer, User Agent и куки.

Нет, этот документ требуется для любых информационных ресурсов и IT-продуктов, которые используют персональные данные.

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

При отсутствии у приложения ПК его невозможно будет загрузить в маркет приложений AppStore и Google Play.

В 2018 году AppStore потребовал, чтобы для всех приложений была опубликована Privacy Policy, соответствующая новым требованиям. Тогда же произошла самая массовая блокировка приложений в маркете — многие правообладатели не успели обновить ПК в согласно новым правилам.

В России «Политика обработки и защиты персональных данных» регулируется федеральным законом «О защите персональных данных». В Европе есть регламентируемые требования — «General Data Protection Regulation» (GDPR); в США нет единого документа — требования различны для каждого штата..

В международном законодательстве политика конфиденциальности (Privacy Policy) заточена на конкретный продукт. То есть, для каждого нового приложения или сайта, в рамках которого будет происходить обработка персональных данных, должна быть разработана своя собственная подробная ПК.

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

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

Это довольно сложно, но возможно. Если изначально пользователь дал согласие на использование одних данных, а приложение начинает требовать другие — это повод подозревать нарушение ПК.

Например, неправомерную передачу данных третьим лицам можно обнаружить, если приходит уведомление от стороннего сервиса с информацией, которая должна храниться только у определенного приложения. Но сейчас пользователи каждый день оставляют свои данные множеству сервисов — от интернет-магазинов до службы такси — поэтому отследить, кто конкретно нарушил ПК и «слил» информацию практически невозможно.

В российском законодательстве предусмотрена ответственность за нарушение Политики обработки и защиты персональных данных, а также за недоведение до пользователя условий использования его персональных данных. Размер штрафа — до 70-100 тысяч рублей за каждое нарушение. А за несоблюдение требований GDPR придется выплатить сумму побольше — можно лишиться до 4% оборота компании при регулярных нарушениях.

Другой вид санкций — блокировка приложения. Как правило, это происходит после проверки ПК со стороны маркетплейсов. AppStore и Google Play диктуют собственные требования к политике конфиденциальности — в соответствии с международным законодательством, а разработчики приложений из России руководствуются местными законами. Как итог — приложение блокируется за несоблюдение требований маркетплейса. Появляется конкуренция норм права — по факту приложение используется в России и соответствует всем ее законам, но площадки предъявляют повышенные требования, за несоблюдение которых и наказывают.

В России инициатором блокировки сайта или приложения за неправомерное использование данных часто выступает Роскомнадзор. Он является уполномоченным органом по защите прав субъектов персональных данных; ведет реестры операторов и нарушителей прав субъектов персональных данных.

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

Многие крупные международные компании сталкивались со сложностями именно из-за проблем с Политикой конфиденциальности:

Источник

Нужна ли политика конфиденциальности в мобильном приложении?

Опубликовано admin в 02/05/2021

Нужна ли политика конфиденциальности в мобильном приложении?

НУЖНА ЛИ ПОЛИТИКА КОНФИДЕНЦИАЛЬНОСТИ В МОБИЛЬНОМ ПРИЛОЖЕНИИ?

Ответ на этот вопрос только такой. Да, нужна. Причина в следующем.

1. Хранение личных данных пользователя.

При наличии в мобильном приложении авторизации пользователей нужно включить в описание Политики конфиденциальности или в Правила (Условия) использования упоминание, что регистрируясь в мобильном приложении пользователь даёт согласие на обработку личных данных согласно Федерального закона «О персональных данных» от 27.07.2006 N 152-ФЗ.

В идеальном варианте на экране «Регистрации» мобильного приложения должен быть активный элемент «Переключатель» с двумя состояниями ВКЛ/ВКЛ. Рядом уточняющая надпись «Согласен на обработку персональных данных в соответствии Федеральным законом «О персональных данных» от 27.07.2006 N 152-ФЗ».

2. Обработка данных пользователя.

В приложении могут не использоваться ФИО пользователя, но в мобильном приложении могут обрабатываться фотографии, вестись переписка, выполняться обработка видео или текстовых данных и т.п.

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

При оформлении аккаунта в AppStore и Google Play надо указать ссылку на страницу сайта, где должна размещаться информация о Политике конфиденциальности. Со стороны магазина приложений будет меньше вопросов и будет легче опубликовать приложение в AppStore и Google Play.

Что является персональными данными?

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

После многочисленных споров e-mail и номер телефона также отнесены ПД (Постановление Правительства РФ от 30.06.2018 N 772).

Необходимый параметр в базе данных

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

Что должно быть отражено в Политике конфиденциальности

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

Особые требования к конфиденциальности в других странах

Если разрабатывается мобильное приложение не только для использования на территории Российской Федерации, то стоит учесть требования к обработке личных данных на территории тех стран, где будет использоваться мобильное приложение. Например, для пользователей из Евросоюза необходимо, чтобы Политика соответствовала «Общему регламенту защиты персональных данных» Regulation (EU) 2016/679 или GDRP (General Data Protection Regulation), вступивший в силу 25.05.2018.

Законодательство США очень отличается в разных Штатах, в том числе и в области защиты ПД. По поводу защиты ПД нет единого кодифицированного федерального закона, данные вопросы разрозненно регулируют различные федеральные законы и законы штатов. В общей практике требования к защите ПД (например, в штате Калифорнии California Consumer Privacy Act of 2018) близки к Европейскому регламенту, но есть отличия. Например, вопрос считается ли IP-адрес персональными данными: в Российской Федерации — не считается, в Евросоюзе считается, а в США — зависит от случая, но по общей тенденции не считается.

Отсутствие необходимой юридической документации может стать и все чаще становится причиной блокировки мобильных приложений в AppStore и GooglePlay.

Задать вопрос по разработке мобильных приложений вы можете мне на WhatsApp или в Телеграм по номеру телефона +7 (921) 477-29-24.

С уважением,
Вадим Александрович Щукин
Генеральный директор
ООО «НОРД КЛОУД СОФТ»
Разработка мобильных
приложений и web-сайтов

Источник

Защита данных пользователя: как добавить поддержку правил CCPA и GDPR в мобильное приложение

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

Поэтому приватность и безопасность данных сейчас сложно переоценить. В большинстве 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 расскажем, как именно их внедрить в своё мобильное приложение.

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

История защиты персональных данных в законодательстве

Защита персональных данных — часть права на неприкосновенность частной жизни (одно из базовых прав человека), которое прописано в законодательстве многих стран Европы и частично США (в Конституции и в Билле о правах США оно до сих пор не закреплено, но следует из ряда поправок к Конституции).

Распространение оно получило в Европе в середине 17-го века, но нормативно было закреплено лишь во Франции. В США же первое упоминание появилось в 1890 году в статье учёных-юристов С.Д. Уоррена и Л.Д. Брендайса «Право на частную жизнь».

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

В 1995 году была принята Директива 95/46ЕС «О защите прав частных лиц применительно к обработке персональных данных и о свободном движении таких данных». Статья 12 из неё гарантирует частным лицам конфиденциальность личной информации и её защиту от третьих лиц в интернете.

В 2010 году Европейская комиссия опубликовала послание «Многосторонний подход к защите персональных данных в Европейском союзе», где выразила необходимость реформирования законодательства ЕС под век развития технологий. В нём также впервые дали определение права на забвение в интернете — удаление своих персональных данных из сети.

В 2012 году Еврокомиссия представила акт о защите персональных данных GDPR на замену Директивы 95/46ЕС. GDPR вступил в силу в мае 2018 и стал основным среди схожих законов в других странах мира.

В США ситуация менее однозначная:

с одной стороны — первая поправка Билля о правах Конституции США гарантирует гражданам свободу слова и печати, что стоит выше права на конфиденциальность;

с другой — есть несколько решений Верховного суда США, где признавалось верховенство права на частную жизнь.

Федеральный закон Children’s Online Privacy Protection Act (COPRA), действующий с апреля 2000, стал одним из первых по регулированию персональных данных и защиты конфиденциальности в интернете. Закон применяется к сбору персональной информации для детей младше 13 лет лицами или организациями под юрисдикцией США (для этого нужно согласие родителей) — из-за него большинство сайтов прекратили работать с пользователями младше 13 лет. Его часто критикуют как противоречащий Конституции США.

В 2015 году штат Калифорния принял собственный закон California S.B. 568 (известен как Online Eraser) для защиты данных несовершеннолетних. Согласно ему, сайт обязан удалить любую информацию, размещённую несовершеннолетним по его требованию. Также он ограничивает показ рекламы алкоголя и ещё 18 категорий несовершеннолетним. Закон тоже критикуют за расплывчатость и за то, что он во многом дублирует COPRA.

В июле 2018 был подписан акт California Consumer Privacy Act (CCPA), который действует с января 2020 года. Он направлен на улучшение защиты персональных данных и расширение прав пользователей в данной сфере. И подобные законы разрабатывают многие штаты, например, Техас.

В ноябре 2020 приняли расширение CCPA, которое вступит в силу с января 2023, — Proposition 24, известное как California Privacy Rights Act of 2020 (CPRA). Оно наделяет пользователей правом запрещать бизнесу передавать их собственные персональные данные и ещё больше ограничивает возможности использования «чувствительных» персональных данных (например, геолокации и медицинских данных).

Также появилось специальное агентство California Privacy Protection Agency, которое будет следить за выполнением законов и выдавать штрафы. Одним из главных требований является получение согласия для пользователей младше 16 лет (и от родителей пользователей младше 13 лет) перед любым сбором их данных (CCPA запрещает передавать такие данные третьим сторонам без явного разрешения, но не собирать их).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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);

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

Форма подачи заявки на подписание Limited Service Provider Agreement

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

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

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

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

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

Политика конфиденциальности iFunny

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

Страничка iFunny, посвященная CCPA

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

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

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

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

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

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

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

Диалог CCPA в iFunny

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 (гайд тут).

Форма регистрации CMP

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

Внедрение

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

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

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

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

Полное прохождение валидации при наличии прототипа и проработанного дизайна занимает день или более. Поздравляем! Вы — счастливый обладатель новенького 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 показываем пользователю диалог. Как было сказано выше — он имеет два уровня. Первый выглядит так, в нём содержится:

Диалог CMP в iFunny (первый уровень)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диалог CMP в iFunny (второй уровень)

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

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

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

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

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

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

IABTCF_CmpSdkID с ID нашего CMP.

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

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

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

Заключение

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

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

Источник