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

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

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

Для общего обзора разрешений Android см. Обзор разрешений . Для конкретных рекомендаций по работе с разрешениями Android см. Рекомендации по разрешениям приложений .

Лучшие практики работы с идентификаторами Android

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

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

2. Избегайте использования идентификаторов оборудования. В большинстве случаев использования вы можете избегать использования идентификаторов оборудования, таких как International Mobile Equipment Identity (IMEI), без ограничения требуемой функциональности.

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

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

4. Не смешивайте сбросы рекламного идентификатора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другие решения включают следующее:

• Не разрабатывать таблицы, которые явно связывают PII с рекламными идентификаторами . В первом примере выше это означало бы не включать столбец account_id в TABLE-01.

• Разделение и мониторинг списков контроля доступа для пользователей или ролей, имеющих доступ как к данным с ключом Advertising ID, так и к PII . Благодаря строгому контролю и аудиту возможности доступа к обоим источникам одновременно (например, путем выполнения объединения таблиц) вы снижаете риск ассоциации между Advertising ID и PII. В общем, контроль доступа означает выполнение следующих действий:

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

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

Работа с FID и GUID

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

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

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

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

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() , а также на отправку сообщений RTM_GETLINK Netlink.

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

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

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

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

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

Объем

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

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

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

Восстанавливаемость и настойчивость

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

• Только сеанс : новый идентификатор используется каждый раз, когда пользователь перезапускает приложение.
• Установка-сброс : новый идентификатор используется каждый раз, когда пользователь удаляет и переустанавливает приложение.
• 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-карт, используемых на устройстве.

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

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

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

Единый вход

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

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

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

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

Реклама

Нацеливание

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

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

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

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

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

Измерение

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

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

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

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

Конверсии

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

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

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

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

Ремаркетинг

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

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

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

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

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

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

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

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

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

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

Отчеты о сбоях

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

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

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

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

Отчетность по эффективности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обнаружение злоупотреблений

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

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

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

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

Рекламное мошенничество

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

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

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

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

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

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

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

Настройки пользователя

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

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

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

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