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

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

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

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

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

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

  2. Избегайте использования аппаратных идентификаторов. В большинстве случаев можно отказаться от использования аппаратных идентификаторов, таких как международный идентификатор мобильного оборудования (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 в отношении контента для разработчиков гласит следующее:

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

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

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

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

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

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

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

В этом примере столбец ad_id может быть присоединен к PII через столбец 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 и PII, содержащийся в TABLE-02, используя метку времени события и модель устройства.

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

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

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

  • Разделение и мониторинг списков контроля доступа для пользователей или ролей, имеющих доступ как к данным, связанным с рекламным идентификатором, так и к персональным данным (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 , а не низкоуровневые, такие как 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 уникален в глобальном масштабе и не подлежит сбросу, начиная с Android 10, доступ к нему ограничен приложениями с разрешением READ_PRIVILEGED_PHONE_STATE Начиная с Android 11, Android дополнительно ограничил доступ к ICCID через API getIccId() , независимо от целевого уровня API приложения. Затронутым приложениям следует перейти на использование идентификатора подписки.

Единый вход

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

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

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

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

Реклама

Таргетинг

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

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

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

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

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

Измерение

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

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

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

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

Конверсии

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

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

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

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

Ремаркетинг

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

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

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

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

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

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

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

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

  • Идентификатор набора приложений: Идентификатор набора приложений позволяет анализировать поведение пользователя в нескольких приложениях, принадлежащих вашей организации, при условии, что вы не используете данные пользователей в рекламных целях. Если вы ориентируетесь на устройства с сервисами Google Play, рекомендуем использовать идентификатор набора приложений.
  • 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 .

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

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

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

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

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

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

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

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

Пользовательские настройки

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

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

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

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