SMS & Call Log Permissions – получение approve от Google Play на чувствительные разрешения

Защита персональных данных, стала red-hot темой после принятия GDPR, с каждым днем ​​становится все более актуальной. Причина этому — практика мировых топ-компаний, начавших реализовывать нормы GDPR и делать даже больше, чем требуется, чтобы защитить приватность своих клиентов. Одним из наиболее ощутимых для разработчиков изменений стало введение новой политики Google Play о наличии в приложениях функций, которые предусматривают предоставление SMS & Call Log Permissions при их установке на устройствах.

SMS & Call Log Permissions – это условное название, объединяющее группу разрешений, предоставляемых пользователями, для того, чтобы приложение имело доступ к их СМС-сообщениям и журналу вызовов. По конкретному перечню, то Google Play оставляет его открытым, и только приводит в пример наиболее популярные из них:

для SMS это такие как:

WRITE_SMS, SEND_SMS, READ_SMS, RECEIVE_SMS, RECEIVE_MMS, RECEIVE_WAP_PUSH;

а для Журнала вызовов, то это такие как:

PROCESS_OUTGOING_CALLS, READ_CALL_LOG, WRITE_CALL_LOG и др.

То есть, если ваше приложение имеет в манифесте и направляет пользователям такие или другие запросы на доступ к SMS или Call Log, то теперь на него распространяются не только требования общего характера, но и специальные требования к чувствительным разрешениям платформы Google Play.

Какие общие требования к разрешениям?

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

• понятность запроса пользователю;
• необходимость запрашиваемых разрешений для осуществления основных функций приложения (core app functionality)
• запрет разрешений для скрытых, неподдерживаемых или запрещенных функций или целей;

Под влиянием норм GDPR эти общие требования теперь также устанавливают, что:

• разрешения должны запрашиваться в контексте, то есть через поэтапную авторизацию (принцип transparency с GDPR)
• данные должны использоваться только для целей, на которые пользователь дал согласие (принцип purpose limitation с GDPR) а также
• если возникает необходимость использовать данные для других целей, то необходимо получить дополнительную согласие на это (требование, необходимое для реализации принципов lawfulness и purpose limitation с GDPR).

А что изменилось для SMS и CALL LOG разрешений?

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

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

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

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

Что потребовал Google play?

В рамках новой политики, разработчики уже существующих и новых приложений, требующих от пользователя предоставить SMS или Call Log Permissions, обязаны были подать Permissions Declaration Form (по простому — форму), чтобы платформа официально разрешила их существования на платформе с таким функционалом, то есть предоставила свой approve.

Если разработчики не отстранили от программы использование SMS & Call Log разрешений и

(і) не подали Permissions Declaration Form, или

(іі) подали ее с несоответствиями или ложными сведениями, или

(ііі)их приложения не соответствовали новым требованиям,

то платформа начала блокировать и удалять их приложения. Поскольку, как уже отмечалось, использование разрешений на доступ к SMS и журнала звонков сначала разрешили только default handler, то первые волны блокировки были действительно очень массовыми.

После первой волны банов были разработаны определенные исключения из указанного общего правила, по которым платформа начала предоставлять временные разрешения на использование SMS & Call Log Permissions. Как отмечает сам Google Play, «эти исключения делаются редко и распространяются не на всех разработчиков». И для того, чтобы получить временное разрешение нужно удовлетворять два основных требования:

(а) SMS & Call Log Permissions должны быть необходимыми для осуществления основных функций приложения (core app functionality).

(b) должен отсутствовать любой альтернативный метод для осуществления core app functionality.

В качестве примеров, в каких ситуациях предоставляются временные разрешения пока Google Play указывает следующие группы:

(і) для приложения требуется подтверждение учетной записи через телефонный звонок

(іі) SMS или Call Log нужны для резервного копирования и восстановления

(ііі) SMS или Call Log необходимы для архива компании, системы CRM (Customer Relationship Management) или для управления устройствами

(iv) SMS или Call Log необходимые для автоматического определения абонента, выявление и блокировки спама

(v) SMS та Call Log необходимы для сопутствующих приложений для подключенных устройств, которые могут передавать и получать SMS или звонки

(vі) SMS або Call Log необходимы для синхронизации между устройствами или передачи SMS или вызовов

(vіі) приложение осуществляет автоматизацию устройства

(vііі) приложение осуществляет финансовые трансакции через SMS и связанные действия, в частности направляет одноразовые пароли для подтверждения аккаунта для тразакций и выявления мошенничества;

(ix) приложение осуществляет отслеживание, бюджетирование и управление финансовыми транзакциями через SMS и связанными действиями для подтверждения аккаунта

(x) SMS або Call Log необходимы для физической безопасности или экстренных извещений по SMS

(xі) SMS чи Call Log необходимы для прокси-вызовов

(xіі) SMS або Call Log необходимы для SMS-рассылки коротких сообщений

приложение осуществляет запись и отображение истории звонков на экране набора номеров

(xііі) приложение предназначено для использования через гарнитуру и дисплей автомобиля

Все эти группы приведены как примеры не просто так — они отражают практику, которая практикуется Google Play по предоставлению временных разрешений. Кроме этих групп можно заявить о новом использовании — то есть пытаться доказать платформе, что основные функции твоего приложения не описаны в этих группах, но также полезно и необходимо пользователям, и ему также очень нужно иметь доступ к SMS или Call Log.

Большинство разработчиков начали пытаться заполнить Permission Declaration Form с указанием одной или нескольких этих групп исключений, которые хоть как-то касались их приложения, но раз за разом они получали отказ.

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

Что это значит? Если ваше приложение предназначен для отслеживания Журнала вызовов на устройстве ребенка родителями, но дополнительно при этом он может и блокировать спам на устройстве ребенка, то блокировка спама вряд ли будет признан его core function.

Так что просто найти в списке свои CORE FUNCTIONS и все?

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

Системный анализ всех требований, приведенных в различных статьях, объяснениях и публикациях от Google Play, позволяет утверждать, что при оценке и принятии решения о предоставлении Permissions Declaration Form учитываются следующие критерии:

1. Приложение не должно нарушать Permissions Policies и Developer Distribution Agreement.

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

К основным положениям, относящихся к Permissions Policies, является то, что мы привели в пункте «Какие общие требования к разрешениям?» Этой статьи. По Developer Distribution Agreement он содержит гораздо больше требований и построен по типу Правил использования. Его структуру и основные требования можно просмотреть на сайте платформы.

Если при проверке будет установлено, что какие-то положения этих документов нарушаются — approve на sensitive permissions не предоставят.

 2. Необходима открытость и прозрачность приложения.

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

3. Приложение должно быть полезным и важным

Google Play имеет иметь возможность оценить выгоды для конечных пользователей, и то, как их жизнь улучшается с этим приложением «уже сегодня».

4. Минимальное влияние на приватность и безопасность

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

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

Об этом мы уже говорили, но важно, что при проверке это должно четко прослеживаться. Если Google не увидит тех связей, которые видны вам как разработчику — не обижайтесь, если в approve будет отказано.

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

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

И еще одно — если у вашего приложения нет SMS & Call Log Permissions, но есть другие разрешения, которые теоретически соответствуют признакам чувствительных — начинайте изучать как подавать Форму уже сейчас, поскольку все свидетельствует о том, что специальные правила могут в ближайшее время быть созданы и для других групп разрешений, хоть каким-то образом могут влиять на приватность людей, которые пользуются Google Play.