Эта страница переведена с помощью Cloud Translation API.

Рекомендации по использованию уникальных идентификаторов

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

Общий обзор разрешений Android см. в разделе «Обзор разрешений» . Рекомендации по работе с разрешениями Android см. в разделе «Рекомендации по работе с разрешениями приложений» .

Работа с рекламными идентификаторами

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

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

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

Всегда учитывайте флаг персонализированной рекламы. Идентификаторы рекламы настраиваются, и пользователи могут ограничить объем отслеживания, связанного с этим идентификатором. Всегда используйте метод AdvertisingIdClient.Info.isLimitAdTrackingEnabled() , чтобы убедиться, что вы не обходите желания ваших пользователей. В политике Google Play для разработчиков указано следующее:

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

Ознакомьтесь с политиками конфиденциальности и безопасности, связанными с используемыми вами SDK, которые касаются использования рекламных идентификаторов. Например, если вы передаете true в метод enableAdvertisingIdCollection() из SDK Google Analytics, обязательно ознакомьтесь со всеми применимыми политиками SDK Analytics и соблюдайте их.

Также имейте в виду, что политика Google Play для разработчиков требует, чтобы рекламный идентификатор «не был связан с персональными данными или с каким-либо постоянным идентификатором устройства (например, SSAID, MAC-адрес, IMEI и т. д.)».

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

ТАБЛИЦА-01
`timestamp`	`ad_id`	`account_id`	`clickid`
ТАБЛИЦА-02
`account_id`	`name`	`dob`	`country`

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

Следует помнить, что связи между идентификатором рекламодателя и персональными данными не всегда настолько очевидны. Возможно наличие «квази-идентификаторов», которые присутствуют как в таблицах с персональными данными, так и в таблицах с идентификаторами рекламодателей, что также может вызывать проблемы. Например, предположим, что мы изменим таблицы TABLE-01 и TABLE-02 следующим образом:

ТАБЛИЦА-01
`timestamp`	`ad_id`	`clickid`	`dev_model`
ТАБЛИЦА-02
`timestamp`	`demo`	`account_id`	`dev_model`	`name`

В этом случае, при достаточно редких событиях клика, все еще возможно установить связь между идентификатором рекламодателя TABLE-01 и персональными данными, содержащимися в TABLE-02, используя метку времени события и модель устройства.

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

К другим решениям относятся следующие:

Неправильное проектирование таблиц, которые явно связывают персональные данные с рекламными идентификаторами . В первом примере выше это означало бы не включение столбца account_id в таблицу TABLE-01.
Разделение и мониторинг списков контроля доступа для пользователей или ролей, имеющих доступ как к данным, закодированным в рекламном идентификаторе, так и к персональным данным . Строгий контроль и аудит возможности одновременного доступа к обоим источникам (например, путем объединения таблиц) снижают риск сопоставления рекламного идентификатора и персональных данных. В общем, контроль доступа подразумевает выполнение следующих действий:
1. Чтобы минимизировать количество лиц или ролей, одновременно включенных в оба списка ACL, следует разделять списки контроля доступа (ACL) для данных, вводимых по идентификатору рекламодателя, и персональных данных.
2. Внедрите системы ведения журналов доступа и аудита для выявления и управления любыми исключениями из этого правила.

Для получения дополнительной информации об ответственном использовании рекламных идентификаторов см. справочник по API AdvertisingIdClient .

Работа с FID и GUID.

Наиболее простой способ идентификации работающего на устройстве экземпляра приложения — использование идентификатора установки Firebase (FID), и это рекомендуемое решение в большинстве случаев, не связанных с рекламой. Доступ к этому идентификатору имеет только тот экземпляр приложения, для которого он был создан, и его (относительно) легко сбросить, поскольку он сохраняется только до тех пор, пока приложение установлено.

В результате, FID обеспечивают лучшие показатели конфиденциальности по сравнению с неперезапускаемыми аппаратными идентификаторами, привязанными к конкретному устройству. Для получения дополнительной информации см. справочник API firebase.installations .

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

Котлин

var uniqueID = UUID.randomUUID().toString()

Java

String uniqueID = UUID.randomUUID().toString();

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

Не работать с MAC-адресами.

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

Изменения в доступности MAC-адресов в Android 11.

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

Полное доменное имя (FQDN)
Область
Учетные данные, основанные на учетных данных, используемых в профиле Passpoint:
- Учетные данные пользователя: имя пользователя
- Учетные данные сертификата: сертификат и тип сертификата.
- Учетные данные SIM-карты: тип EAP и IMSI.

Кроме того, приложения без привилегий не могут получить доступ к MAC-адресу устройства; видны только сетевые интерфейсы с IP-адресом. Это влияет на методы getifaddrs() и NetworkInterface.getHardwareAddress() , а также на отправку сообщений Netlink RTM_GETLINK .

Ниже приведён список того, как это изменение повлияет на приложения:

NetworkInterface.getHardwareAddress() возвращает null для каждого интерфейса.
Приложения не могут использовать функцию bind() для сокетов NETLINK_ROUTE .
Команда ip не возвращает информацию об интерфейсах.
Приложения не могут отправлять сообщения RTM_GETLINK .

Следует отметить, что большинству разработчиков следует использовать высокоуровневые API ConnectivityManager , а не низкоуровневые API, такие как NetworkInterface , getifaddrs() или сокеты Netlink. Например, приложение, которому необходима актуальная информация о текущих маршрутах, может получить эту информацию, отслеживая изменения в сети с помощью ConnectivityManager.registerNetworkCallback() и вызывая связанный с сетью LinkProperties.getRoutes() .

Характеристики идентификатора

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

Объем

Область действия идентификатора определяет, какие системы могут получить к нему доступ. Область действия идентификатора в Android обычно бывает трех типов:

Одно приложение : идентификатор является внутренним для приложения и недоступен для других приложений.
Группа приложений : Идентификатор доступен для заранее определенной группы связанных приложений.
Устройство : Идентификатор доступен всем приложениям, установленным на устройстве.

Чем шире область действия идентификатора, тем выше риск его использования в целях отслеживания. И наоборот, если доступ к идентификатору имеет только один экземпляр приложения, его нельзя использовать для отслеживания устройства в транзакциях в разных приложениях.

Возможность сброса и сохранение состояния

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

Только для сессии : новый идентификатор используется каждый раз, когда пользователь перезапускает приложение.
Install-reset : Каждый раз, когда пользователь удаляет и переустанавливает приложение, используется новый идентификатор.
Сброс FDR : Каждый раз, когда пользователь сбрасывает устройство до заводских настроек, используется новый идентификатор.
FDR-persistent : Идентификатор сохраняется после сброса до заводских настроек.

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

Уникальность

Уникальность определяет вероятность коллизий; то есть, что в пределах соответствующей области действия существуют идентичные идентификаторы. На самом высоком уровне глобально уникальный идентификатор никогда не имеет коллизий, даже на других устройствах или в приложениях. В противном случае уровень уникальности зависит от энтропии идентификатора и источника случайности, использованного для его создания. Например, вероятность коллизии намного выше для случайных идентификаторов, инициализированных календарной датой установки (например, 2019-03-01 ), чем для идентификаторов, инициализированных меткой времени установки Unix (например, 1551414181 ).

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

Защита целостности и неопровержимость.

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

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

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

Счета

Статус перевозчика

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

Рекомендуемый идентификатор для использования: IMEI, IMSI и Line1.

Почему именно эта рекомендация?

Использование аппаратных идентификаторов допустимо, если это необходимо для работы функций, связанных с оператором связи. Например, вы можете использовать эти идентификаторы для переключения между сотовыми операторами или слотами SIM-карт, или для доставки SMS-сообщений по IP (для Line1) — с использованием учетных записей пользователей на основе SIM-карт. Однако для приложений без привилегий мы рекомендуем использовать вход через учетную запись для получения информации об устройстве пользователя на стороне сервера. Одна из причин этого заключается в том, что в Android 6.0 (уровень API 23) и выше эти идентификаторы могут использоваться только с помощью разрешения во время выполнения. Пользователи могут отключить это разрешение, поэтому ваше приложение должно корректно обрабатывать такие исключения.

статус мобильной подписки

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

Рекомендуемый идентификатор: API идентификатора подписки для идентификации SIM-карт, используемых на устройстве.

Идентификатор подписки (Subscription ID) представляет собой индексное значение (начиная с 1), используемое для уникальной идентификации установленных SIM-карт (включая физические и электронные), применяемых на устройстве. С помощью этого идентификатора ваше приложение может связывать свою функциональность с различной информацией о подписке для данной SIM-карты. Это значение остается неизменным для данной SIM-карты, если устройство не сброшено до заводских настроек. Однако могут быть случаи, когда одна и та же SIM-карта имеет разные идентификаторы подписки на разных устройствах, или разные SIM-карты имеют одинаковый идентификатор на разных устройствах.

Почему именно эта рекомендация?

В настоящее время некоторые приложения могут использовать для этой цели идентификатор ICC . Поскольку идентификатор ICC является глобально уникальным и не подлежит сбросу, доступ к нему был ограничен приложениями с разрешением READ_PRIVILEGED_PHONE_STATE , начиная с Android 10. Начиная с Android 11, Android дополнительно ограничил доступ к ICCID через API getIccId() , независимо от целевого уровня API приложения. Затронутым приложениям следует перейти на использование идентификатора подписки (Subscription ID).

Единый вход

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

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

Почему именно эта рекомендация?

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

Рекомендуемый идентификатор: если ваше приложение использует идентификатор для рекламы и загружает или публикует его в Google Play, этот идентификатор должен совпадать с рекламным идентификатором.

Почему именно эта рекомендация?

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

Независимо от того, делитесь ли вы пользовательскими данными в своем приложении, если вы собираете и используете их в рекламных целях, вам необходимо указать эти цели в разделе «Безопасность данных» на странице содержимого приложения в Play Console.

Измерение

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

Рекомендуемый идентификатор для использования: рекламный идентификатор или API-интерфейс для перехода по ссылке при установке в Play Store.

Почему именно эта рекомендация?

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

Конверсии

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

Почему именно эта рекомендация?

Ремаркетинг

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

Рекомендуемый идентификатор: рекламный идентификатор.

Почему именно эта рекомендация?

Аналитика приложений

В этом случае ваше приложение анализирует поведение пользователя, чтобы помочь вам определить следующее:

Какие другие продукты или приложения вашей организации могут подойти пользователю?
Как поддерживать интерес пользователей к вашему приложению.
Измеряйте статистику использования и аналитику для пользователей, не вошедших в систему, или анонимных пользователей.

Возможные решения включают:

Идентификатор набора приложений: Идентификатор набора приложений позволяет анализировать поведение пользователя в нескольких приложениях, принадлежащих вашей организации, при условии, что вы не используете данные пользователя в рекламных целях. Если вы ориентируетесь на устройства, работающие на базе сервисов Google Play, мы рекомендуем использовать идентификатор набора приложений.
Идентификатор Firebase (FID): FID привязан к приложению, которое его создало, что предотвращает использование идентификатора для отслеживания пользователей в разных приложениях. Его также легко сбросить, поскольку пользователь может очистить данные приложения или переустановить приложение. Процесс создания FID прост; см. руководство по установке Firebase.

Разработка приложений

Сообщение о дорожно-транспортных происшествиях

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

Рекомендуемый идентификатор: FID или идентификатор набора приложений.

Почему именно эта рекомендация?

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

Отчетность о результатах деятельности

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

Рекомендуемый идентификатор для использования: Firebase Performance Monitoring

Почему именно эта рекомендация?

Система мониторинга производительности Firebase помогает вам сосредоточиться на наиболее важных для вас показателях и проверить влияние недавних изменений в вашем приложении.

тестирование приложений

В этом случае ваше приложение оценивает взаимодействие пользователя с приложением в целях тестирования или отладки.

Рекомендуемый идентификатор: FID или идентификатор набора приложений.

Почему именно эта рекомендация?

Установка на нескольких устройствах

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

Рекомендуемый идентификатор для использования: FID или GUID.

Почему именно эта рекомендация?

Идентификатор FID разработан специально для этой цели; его область действия ограничена приложением, поэтому его нельзя использовать для отслеживания пользователей в разных приложениях, и он сбрасывается при переустановке приложения. В редких случаях, когда FID недостаточно, можно также использовать GUID.

Безопасность

Выявление злоупотреблений

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

Рекомендуемый идентификатор для использования: токен целостности API Google Play.

Почему именно эта рекомендация?

Чтобы убедиться, что запрос поступает с подлинного устройства Android, а не от эмулятора или другого кода, имитирующего другое устройство, используйте API проверки целостности Google Play .

Мошенничество с рекламой

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

Рекомендуемый идентификатор: рекламный идентификатор.

Почему именно эта рекомендация?

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

Управление цифровыми правами (DRM)

В данном случае ваше приложение стремится предотвратить мошеннический доступ к интеллектуальной собственности или платному контенту.

Рекомендуемый идентификатор: использование FID или GUID вынуждает пользователя переустанавливать приложение, чтобы обойти ограничения на контент, что является достаточным препятствием для большинства пользователей. Если этого недостаточно для защиты, Android предоставляет API DRM , который можно использовать для ограничения доступа к контенту, включая идентификатор для каждого APK-файла — Widevine ID.

Пользовательские предпочтения

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

Рекомендуемый идентификатор для использования: FID или GUID.

Почему именно эта рекомендация?

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

Рекомендации по использованию уникальных идентификаторов

Рекомендации по работе с идентификаторами Android

Работа с рекламными идентификаторами

Работа с FID и GUID.

Котлин

Java

Не работать с MAC-адресами.

Изменения в доступности MAC-адресов в Android 11.

Характеристики идентификатора

Объем

Возможность сброса и сохранение состояния

Уникальность

Защита целостности и неопровержимость.

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

Счета

Статус перевозчика

статус мобильной подписки

Единый вход

Реклама

Целенаправленное воздействие

Измерение

Конверсии

Ремаркетинг

Аналитика приложений

Разработка приложений

Сообщение о дорожно-транспортных происшествиях

Отчетность о результатах деятельности

тестирование приложений

Установка на нескольких устройствах

Безопасность

Выявление злоупотреблений

Мошенничество с рекламой

Управление цифровыми правами (DRM)

Пользовательские предпочтения