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

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

Общий обзор разрешений 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 , если вы не получите явного разрешения от своих пользователей.

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

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

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

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

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

  • Не создавать таблицы, которые явно связывают PII с рекламными идентификаторами . В первом примере выше это означало бы отсутствие включения столбца account_id в ТАБЛИЦУ-01.

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

    1. Держите списки управления доступом (ACL) для данных с ключами идентификатора рекламодателя и PII непересекающимися, чтобы свести к минимуму количество отдельных лиц или ролей, которые находятся в обоих 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() , а также на отправку сообщений Netlink RTM_GETLINK .

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

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

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

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

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

Объем

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

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

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

Сбрасываемость и постоянство

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

  • Только для сеанса : новый идентификатор используется каждый раз, когда пользователь перезапускает приложение.
  • Установка-сброс : новый идентификатор используется каждый раз, когда пользователь удаляет и переустанавливает приложение.
  • Сброс FDR : новый идентификатор используется каждый раз, когда пользователь выполняет сброс настроек устройства.
  • Постоянный FDR : идентификатор сохраняется при сбросе настроек до заводских.

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

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

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

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

Защита целостности и неотказуемость

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

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

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

Счета

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

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

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

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

Использование идентификаторов оборудования допустимо, если это необходимо для функциональности, связанной с оператором связи. Например, вы можете использовать эти идентификаторы для переключения между операторами сотовой связи или слотами для SIM-карт или для доставки SMS-сообщений по IP (для линии 1) — учетные записи пользователей на основе 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.

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

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

Объявления

Таргетинг

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

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

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

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

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

Измерение

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

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

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

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

Конверсии

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

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

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

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

Ремаркетинг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отчеты о производительности

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

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

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

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

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

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

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

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

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

Кросс-девайсная установка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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