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

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.

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!

@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:

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?

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.

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

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

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

Sure, you can assign it to me

A little late to this, but I have a couple of thoughts:

First, the following may not be possible:

The installation.id MUST remain the same between launches of the same installation of an application.

On Android, install-identifying IDs are typically stored in a place that that can be cleared by users without uninstalling (e.g. app data, shared preferences, etc.), so any app-data purge is effectively a factor reset without actually uninstalling. We should probably put in a caveat to allow for any install-resetting actions to recreate this.

Second, another use case that requires a install-dependent ID is to differentiate between the different accounts that are using the same install. This isn't the same as an account/user ID, because you don't want the same account on two installs to have the same ID. Think of it as a device-account tuple.

In that case, should installation.id be appropriate still? My gut is to say yes - the whole point of not having device.id is to not allow the unique identification of a device for privacy reasons, so if we need to differentiate between accounts on the same device, I don't think we should introduce another concept, but instead account for it in the description.

@bidetofevil good points, thanks for the feedback, I have made the following adjustments in fd2e226:

First, the following may not be possible:

The installation.id MUST remain the same between launches of the same installation of an application.

I have relaxed the wording to 'SHOULD'. (Its value SHOULD remain the same between launches of the same installation of an application.)

On Android, install-identifying IDs are typically stored in a place that that can be cleared by users without uninstalling (e.g. app data, shared preferences, etc.), so any app-data purge is effectively a factor reset without actually uninstalling. We should probably put in a caveat to allow for any install-resetting actions to recreate this.

Added the following sentence: Additionally, users might be able to reset this value (e.g. by clearing application data).

Second, another use case that requires a install-dependent ID is to differentiate between the different accounts that are using the same install. This isn't the same as an account/user ID, because you don't want the same account on two installs to have the same ID. Think of it as a device-account tuple.

In that case, should installation.id be appropriate still? My gut is to say yes - the whole point of not having device.id is to not allow the unique identification of a device for privacy reasons, so if we need to differentiate between accounts on the same device, I don't think we should introduce another concept, but instead account for it in the description.

Added the following sentence: If an app is installed multiple times on the same device (e.g. in different accounts on Android), each installation SHOULD have a different value.

Let me know, if you would like to see further adjustments!