Decoding Unique Identifiers in Android: Risks, Impacts, and Solutions
A Deep Dive into GAID, FID, GUID, APP SET ID & Hardware ID
Today’s digital marketing landscape and the vast amount of user data available require developers to find a balance between leveraging this data for business purposes and respecting user privacy. One major concern is the use of Identifiers in Android applications.
In this article, we delve into the implications of choosing different IDs, the challenges they present, and the potential solutions to address these concerns.
A quick dive into Google, and you’ll find several StackOverflow threads that can illuminate your quest. However, as a diligent developer, you should thoroughly evaluate all available options rather than merely replicating the top approved answer. This article aims to assist you in that endeavor.
A Guide to Different Identifiers
Here’s a Quick overview of different identifiers in Android:
1. Advertising ID / Google Advertising ID
User-resettable, device-level, unique identifier ad tracking.
ADID, or GAID, is a unique identifier for advertising on Android devices. It provides the capability to users to reset their identifier or opt out of personalized ads. This opt-out and reset feature gives users better control over their data, making GAID compliant with user privacy requirements.
ADID serves as a device identifier, allowing the tracking of user interaction with ads across various apps installed on a device. However, once a user opts to reset the GAID, the new advertising identifier should not be linked to the previous one or data derived from it without explicit user consent, as per Google’s guidelines.
2. Firebase Installation ID (FID)
An app-level identifier that resets upon uninstallation and reinstallation.
Firebase Installation ID, more commonly known as FID, is a straightforward solution when you need to identify a specific instance of an app running on a device. It’s unique to the app instance it’s provisioned for and is only accessible by that app.
Interestingly, an FID is relatively easy to reset as it only persists as long as the app is installed on the device. The moment the app is uninstalled, the FID goes with it. This feature gives FID better privacy properties compared to non-resettable, device-scoped hardware IDs. You can check out the Firebase Installations API reference for more detailed information here.
3. Globally Unique ID (GUID)
A unique App-level identifier, ideal for identifying a specific app instance.
There might be scenarios where an FID doesn’t fit your needs. In such situations, you could resort to a custom Globally Unique ID (GUID). As the name implies, a GUID is globally unique, which means you can use it to identify a specific instance of an app.
Creating a GUID is relatively simple — you need to generate one on your own. To prevent potential privacy concerns associated with linking identifiers across apps, storing GUIDs in the app’s internal storage is recommended, not external (shared) storage.
4. App Set ID
To correlate actions across a set of apps owned by the same organization.
App Set ID is a handy tool for correlating usage or actions across multiple apps owned by your organization for purposes such as analytics or fraud prevention. For instance, if you publish two apps under the same Google Play developer account (let’s say “Gmail” and “Youtube”), they would share the same App Set ID on a device where both apps are installed via Google Play. This holds even if the apps are signed with different keys.
However, keep in mind that the App Set ID is subject to reset under three circumstances:
a. A factory reset of the device.
b. All apps associated with your developer account are uninstalled from the user’s device.
c. No app accesses App Set ID in 13 months.
For more detailed insights into how App Set ID works, consider going through this link on App Set ID.
5. Hardware ID
A non-resettable device-level identifier.
These identifiers are associated with device hardware like IMEI, Serial No. Etc. They persist even when the user factory-resets the device.
Choosing between these identifiers depends on their specific use cases, as they vary in terms of reset-ability, scope, uniqueness, and compliance with ad tracking guidelines which we will talk about in our next section.
Choosing a New Identifier For your Use-Case
Selecting identifiers is not a decision to be taken lightly. I will guide you through some essential considerations when selecting new identifiers for your Android applications.
1. Scope of the Identifier
The scope of an identifier refers to its range of accessibility. Depending on the need, you can opt for one of the following:
- Single app: The identifier is confined to the app and is inaccessible to other apps. It serves as a local ID unique to each user within that specific app.
- Group of apps: This identifier is shared among a predefined group of related apps. This allows for cross-app user recognition within the group.
- Device: This identifier spans across all apps installed on a device. It’s a global ID that every app on the device can access.
Remember, an identifier with a broader scope carries a higher data privacy and security risk. Hence, choose wisely based on your requirements.
2. Resettability and Persistence of the Identifier
Another key aspect to consider is the lifecycle of the identifier — how and when it resets and how long it persists. Here are your options:
- Session-only: The identifier is renewed every time the user restarts the app. This ensures a fresh ID for each app session.
- Install-reset: This ID resets whenever the user uninstalls and reinstalls the app. This provides a new identifier for each installation of the app.
- FDR-reset (Factory Data Reset-reset): A new identifier is created every time the user factory-resets their device. This links the ID’s lifecycle to the device’s lifecycle.
- FDR-persistent: The identifier persists even when the user factory-resets the device. This creates a permanent identifier that stays constant throughout.
Resettability empowers users to disconnect from existing profile information by generating a new ID. Please note that if the identifier resets upon the app’s reinstall, it reduces persistence while providing a means for the ID to be reset. This is true even if there’s no explicit control for the user to reset it within the app or system settings.
The longer and more reliably an identifier persists — such as one that survives a factory reset — the greater the associated risk.
Understanding different IDs
The above-mentioned identifiers, be it for a single app, a group of apps, or the entire device, serve as unique keys that distinguish each user, enabling targeted functionalities and customizations.
Restriction on Hardware and non-resettable device identifiers
In Android 10, apps must have READ_PRIVILEGED_PHONE_STATE privileged permission to access the device's non-resettable identifiers, including IMEI and serial numbers.
On devices that run Android 10 or higher, the system transmits randomized MAC addresses by default.
Build.SERIAL you need some privileged permissions at the system level, or it returns Build#UNKNOWN
Settings.Secure.ANDROID_ID There has been at least one widely-observed bug in a popular handset from a major manufacturer where every instance has the same ANDROID_ID.
Here is a Good Read for the same
Recommendations for some Use-Cases
- Ads, Measurement, Conversions, Remarketing: If your app builds user profiles, tracks conversions, or performs remarketing, the Advertising ID is the most suitable due to its resettable nature and cross-app availability.
- App Analytics: App Set ID or Firebase ID (FID) are suitable for app analytics across your organization’s apps or within a single app, respectively.
- Crash and Performance Reporting: Use FID or App Set ID for crash reporting and Firebase Performance Monitoring for performance metrics.
- App Testing: Use FID or App Set ID to evaluate user experiences for testing or debugging.
- Cross-device Installation: For identifying the correct instance of the app on multiple devices, use FID or a Globally Unique ID (GUID).
- Security (Abuse Detection and Ad Fraud): The SafetyNet API is suitable for detecting fake devices attacking backend services, while the Advertising ID is suitable for verifying genuine impressions and actions in your app.
- Digital Rights Management (DRM): Use an FID or GUID to protect against fraudulent access to content or consider Android’s DRM API.
- User Preferences: To save per-device user state, use an FID or GUID.
Best Practices
- Use user-resettable identifiers where possible.
- Avoid hardware identifiers like IMEI etc.
- Android 10 has restrictions for accessing non-resettable identifiers.
- Use Advertising ID only for user profiling or ads use cases.
- Respect users’ ad tracking choices.
- Don’t bridge resets of Advertising IDs.
- For most non-advertising cases, use a Firebase Installation ID (FID) or a privately stored GUID.
- Use APIs that suit your use case to minimize privacy risks.
- Use the DRM API for high-value content protection and SafetyNet APIs for abuse protection. SafetyNet APIs are privacy-friendly for verifying device authenticity.
In Conclusion
The challenges around the use of identifiers in Android and their impact on ad targeting, analytics, and user privacy are complex. Developers need to strike a balance between maintaining an app’s functionality and respecting users’ privacy. Solutions like App Set ID can mitigate some of these concerns, but the choice of the identifier should always be dictated by the needs of the use case and compliance with privacy norms.
Remember, putting the user’s privacy first is ethical and good for business in the long run. By doing so, developers can build trust with users, which can lead to higher engagement and retention rates.
The key to maintaining privacy while working with Android identifiers is to use user-resettable identifiers as much as possible and avoid hardware identifiers. Don’t forget scope and persistence should be key in your decision-making.
