`device.id` vs `installation.id` on Android and iOS

[bencehornak]

Area(s)

area:device

What's missing?

Take a look at the current definition of device.id:

semantic-conventions/model/device/registry.yaml

Lines 14 to 21 in b855a36

	The device identifier MUST only be defined using the values outlined below. This value is not an advertising
	identifier and MUST NOT be used as such.
	On iOS (Swift or Objective-C), this value MUST be equal to the [vendor identifier](https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor).
	On Android (Java or Kotlin), this value MUST be equal to the Firebase Installation ID or a globally unique
	UUID which is persisted across sessions in your application. More information can be found [here](https://developer.android.com/training/articles/user-data-ids)
	on best practices and exact implementation details.
	Caution should be taken when storing personal data or anything which can identify a user. GDPR and
	data protection laws may apply, ensure you do your own due diligence.

The obligatory recommendation for Android (Firebase Installation ID or a globally unique UUID which is persisted across sessions in your application) mostly mirrors the recommendation for Google

Use a Firebase installation ID (FID) or a privately stored GUID whenever possible for all other use cases, except for payment fraud prevention and telephony. For the vast majority of non-ads use cases, an FID or GUID should be sufficient.

The one for iOS suggests using identifierForVendor.

The value of this property is the same for apps that come from the same vendor running on the same device. A different value is returned for apps on the same device that come from different vendors, and for apps on different devices regardless of vendor.

Now I have multiple remarks to these recommendations:

1. None of the two Android recommendations and the one iOS recommendation are really device ids, they are more like installation ids. For consumer apps the difference is probably insignificant, however, for enterprise apps on managed Android/iOS devices it is important. One could have many managed applications on the same device, so the expectation for device.ids would be that they are identical across all apps, which neither the Firebase Installation ID, nor the random generated UUID or the iOS identifierForVendor fulfill.

2. There is another ID, which fits my use case better on Android, called Settings.Secure.ANDROID_ID, because I don't want to use Firebase, but I want an ID which survives uninstalls, and which is consistent across all my in-house apps.

   ANDROID_ID:
   On Android 8.0 (API level 26) and higher versions of the platform, a 64-bit number (expressed as a hexadecimal string), unique to each combination of app-signing key, user, and device. [...]

3. Although not recommended by Google for Android, one could still use actual device IDs, such as the IMEI or proprietary APIs provided by the vendor (e.g. Zebra's API), which are bound to the device for its whole lifetime. For enterprise-managed hardware there might be a legitimate use for such actual device ids, so these IDs would rather deserve to be the definition of device.id.

Describe the solution you'd like

I would recommend these 3 changes:

1. Introduce a new attribute, called installation.id, and recommend it for most use-cases on Android and iOS.
2. Use a similar description for installation.id, that device.id currently has, but extend it with the possibility to use Settings.Secure.ANDROID_ID
3. Discourage the usage of device.id due to privacy reasons, but leave it open to custom implementations, such as IMEI or proprietary APIs.

[bencehornak]

Note: #1474 is somewhat related, but has a different focus.

[jzwc]

On Apple platforms, it is not possible - by design - to get an id identifying a particular device across applications. The nearest thing, technically, is advertisingIdentifier, which, however, cannot be legally used for telemetry and requires user consent.

In my view, the concept of an installation.id as an identifier for individual application installations is the most practical and sensible solution. This identifier would remain consistent across app sessions ("runs") but may not persist through application re-installation (i.e., deletion followed by a new installation). The SDK itself can generate and store such an identifier if there is no corresponding system API available.

[breedx-splk]

Thanks for the discussion @bencehornak . I think that I understand most of the points here, and in general this seems reasonable to me, but wanted to make a few points:

• I think IMEI is a non-starter for privacy/security reasons, and we could take steps (as Google has done) to discourage use of it as an identifier.
• Migrating away from device.id to an installation.id seems reasonable. We can deprecate device.id in favor of an installation.id if you think that's helpful.
• I think the description around installation.id should then include specific language similar to this, to clarify:
  • The installation.id SHOULD change between uninstall/reinstall of the same application.
  • The installation.id SHOULD NOT be the same between different applications (I think MUST could work here too)
  • The installation.id MUST remain the same between launches of the same installation of an application.

If I've gotten any of those wrong, please point it out. Thanks again!

[bencehornak]

@breedx-splk thanks for your points, I think they'll serve as a good start for the requirements of the proposed installation.id. I have collected some IDs, that might be of interest, and whether they fulfill your criteria:

OS	ID	Changes between uninstall/reinstall of the same application	Same between different applications	Remains the same between launches
Android	Firebase Installation ID	Yes	No	Yes
Android	Self-managed GUID	Yes	No	Yes
Android	App set ID	Only if you uninstall all apps from a vendor	For apps from the same vendor yes	Yes
Android	Settings.Secure.ANDROID_ID	No	For apps from the same vendor yes	Yes
Android/iOS	Hardware ID	No	Yes	Yes
iOS	identifierForVendor	Only if you uninstall all apps from a vendor	For apps from the same vendor yes	Yes

The Android ones I mostly took from the article Decoding Unique Identifiers in Android: Risks, Impacts, and Solutions.

So based on the table I would refine your points as following:

• The installation.id SHOULD change if the app is uninstalled or if all apps of a vendor are uninstalled.
• The installation.id MIGHT be the same between different applications of the same vendor
• The installation.id MUST be different between applications of different vendors
• The installation.id MUST remain the same between launches of the same installation of an application.

I wouldn't go as far as to deprecate device.id, because for some enterprise apps I can think of legitimate and IMO compliant use cases (although I'm not a lawyer 😄). It should be forbidden for non-enterprise apps though, especially in the EU:

• The device.id MUST NOT be used for non-enterprise apps due to privacy reasons
• The device.id MIGHT be used for enterprise apps, if its use is compliant
• The device.id SHOULD be identical for all apps on a device
• The device.id SHOULD NOT change if an app is uninstalled and re-installed
• The device.id MIGHT be resettable by the user for all apps on a device

One use-case for device.id I could think of:

A museum has an own app, which is installed on devices mounted to the wall. I would argue that it is in the operators' legitimate interest to be able to trace back signals to a specific device with a hardware ID to support their maintenance efforts.

What do you think about these modified points?

[joaopgrassi]

The device.id MUST NOT be used for non-enterprise apps due to privacy reasons
The device.id MIGHT be used for enterprise apps, if its use is compliant

The enterprise here seems a bit iffy to me. I guess what we are really after is making it very clear that this attribute can pose privacy issues and must be used with care. At first I was more inclined to just deprecate it, as it doesn't sound like a good idea for semconv to have such thing that can be misused like this. But your use case about the museum seems legit.

So maybe we drop these two:

The device.id SHOULD NOT be used for non-enterprise apps due to privacy reasons
The device.id MIGHT be used for enterprise apps, if its use is compliant

And rather keep the existing disclaimer/warning as part of the brief

Caution should be taken when using device.id as its content can carry PII data thus pose a security/privacy risk.

Also, it should definitely be Opt-In and not recommended by default.

[joaopgrassi]

CC @marandaneto maybe you also can chime in here :)

[bencehornak]

@joaopgrassi sounds good, I'm totally fine with your suggestions!

[joaopgrassi]

@bencehornak cool! Will you be working on it? Let me know so then I can assign this issue to you.

[bencehornak]

Sure, you can assign it to me