Alternative device identifiers

[eric-murray]

• Can an alternative device identifier be returned that identifies the device to the API consumer, but cannot be used by any third-party to identify the device?
• Does the API consumer need to be able to derive the IMEI from this identifier, or just know that all devices with the same identifier are the same device?
• Do any existing device identifiers satisfy this requirement? Would hashing the IMEI with an API consumer salt be sufficient?
• How is any alternative identifier derived, and how is it used by the API consumer?

[Kevsy]

Can an alternative device identifier be returned that identifies the device to the API consumer, but cannot be used by any third-party to identify the device?

It could - i.e. an opaque reference that can only be resolved by the issuing operator.

Does the API consumer need to be able to derive the IMEI from this identifier, or just know that all devices with the same identifier are the same device?

I suspect to be useful we would want the latter - otherwise we would just use the IMEI.

Do any existing device identifiers satisfy this requirement? Would hashing the MSISDN with an API consumer salt be sufficient?

Not sure. What happens if the MSISDN is ported to another operator?

How is any alternative identifier derived, and how is it used by the API consumer?

For further discussion :) - by 'used' do you mean use case scenarios?

[eric-murray]

Not sure. What happens if the MSISDN is ported to another operator?

Sorry, that was a typo. Should have been "Would hashing the IMEI with an API consumer salt be sufficient?". I'll edit.

For further discussion :) - by 'used' do you mean use case scenarios?

Yes, I mean what is the use case for the device identifier information. For example, for insurance purposes, the insurance company may well require to know the IMEI. But for fraud detection, they may just need to know that the device currently being used by their customer is different to the one that they were using previously and had insured.

[HuubAppelboom]

In general , there are 2 kinds of applications for device identifiers. One is a blacklist (or a grey list) of devices that have been used by fraudsters, or devices that have been stolen. For these list to be effective, it is indeed required that multiple independent parties can work with such a list. For this, IMEI as a device identifier is more suitable, although you run the risk that these IMEI's can be abused to track and trace people. Probably the only way to solve this is by having stringent rules on who can use this kind of information, which cases are approved, and to have transparency on both the legal basis for the use cases and who is using the data and for what purpose. For case of fraud consent will not work as a legal basis (because fraudsters will not give consent, and then you can not block access to a service), but only legitimate interest can be used. For ownership of devices and blokcing stolen devices, consent can be used as a legal basis.

The other main application is that of a whitelist of devices, ranging from a short list of devices that can be used by a specific user (as a possesion factor in authentication), to a list of devices which belong to trusted users. For whitelists of devices, an alternate device identifier can be much more privacy friendly, in case the identifiers are only relevant for a specific application (or service provider), and can not be used to track users across different applications. This alternate device identifier can for example be generated by hashing the IMEI in combination with a sufficient long Salt (which needs to be application specific), or the MNO can generate random identifiers and store there with the IMEI in a table for future lookup.

In this case of alternate identifiers, you probably also don't need to acquire users consent, because it is similar to the use of a functional cookie, which can be used without acquiring consent. The main advantage of such a white list based alternate device identifiers is that it can be made resilient towards factory resets of the device.

[nickvenezia]

So how can we help protect the personal data from bad actors? How would you combat marketplaces that sell identity resolution?

[nickvenezia]

@HuubAppelboom not just "resale" but "processes" the data of any EU citizen.

GDPR also has protection as the data flows "downstream".
Carrier >> Aggregator >> Developer >> Application.

What happens if the Developer has a third-party API integrated into the APP? Worst case that person is a bad actor?

[HuubAppelboom]

@nickvenezia Thats why there is a proposal for alternate identifiers. In this case, if there are two applications, the end user device has a different identifier for each application. Only the MNO knows the correlation between these two, nobody else.

[nickvenezia]

That sounds like a MAID.

Your suggestion of IMEI would allow all known device MAIDs, IP Addresses, AAID, emails, IDFA and more to be linked to that mobile number and IMEI.

IMEI is a persistent device identifier and would be the top level device identifier.

How would a user be able to delete the IMEI for opt-out requests.

Please, correct me where wrong.

[AxelNennker]

Technical solutions only get us so far. OpenId proposes pairwise-identifiers
https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
Which make it harder for 3rd-parties to collude and match identifiers for e.g. profile building - while opening up through the sector_identifier mechanisms that e.g. different 3rd-party apps from the same vendor get the same PPID.

So, technical proposals exist but in the end the law (e.g. GDPR) is what counts.

[eric-murray]

Hi @HuubAppelboom

So you discuss two (physical) device identifiers:

• IMEI, as already proposed / in-use
• Salted and hashed IMEI

My comments on the salted and hashed IMEI are:

• From a privacy / GDPR perspective, my understanding is that, if there is a one-to-one mapping between some identifier which is considered to be personal information and another identifier, then that alternative identifier is still considered to be personal information, no matter how useless it might be to anyone who knows it without context. It might simplify data security rules (for example, it is simpler to get approval to send a hashed MSISDN than a plaintext MSISDN), but it does not change the need to get end user consent.
• As an output from the device identifier API, it is only useful to tell the API consumer that the end user (identified by MSISDN) that the same or different device is in use compared to a previous request. What would be the use case here?
• As an input to the IMEI fraud API, then this would be useful to match the subscriber identifier (e.g. MSISDN) with the device fraud status without knowing the details of the actual device. Again, what would be the use case here, especially as it is unlikely that a specific MSISDN would be associated with a blacklisted device, as that device would not be allowed to connect to the network?

So currently I do not see value in using salted & hashed IMEI as an alternative device identifier, but am open to persuasion!

[HuubAppelboom]

Hi Eric,
From a GDPR perspective, there is also a legal basis that can be used for the processing of personal information which is called legitimate interest. Legitimate can and is often used in fraud prevention cases, and does not require explicit user consent.
In case of legitimate interest, you do need to make a documented balancing test, in which you can show that the interest of for example a company to prevent fraud outweighs the privacy impact of processing the personal data.
Now, if the device identifier is user-company specific, the device identifier can not be used for tracking users between different relying patties, which makes a large difference in the balancing test. You will still need to treat these device identifiers as personal information, with the same care and precautions, but in many anti-fraud cases you will be able these indentifiers without explicit user consent. This is very much the same as is with for example KYC Match and ATP is the case today, which are often processed on basis of legitimate interest. Hence, that is why a device identifier which is only relevant for the combination of user - relying party.

[HuubAppelboom]

The use cases you can think of for a "personal" device identfier can be to create a list of trusted devices, and use these as an authentication factor. For a blacklist this device identifier would be useless (because here you must be able to share the same device identifier with multiple parties), but for authentication purposes it would be much more privacy friendly.

[HuubAppelboom]

However, there may be alternative privacy friendly device identifiers already available in both IOS and Android that do the exact same thing, to be checked, In that case you may not be adding much value (except offering less dependency on the OS).

[eric-murray]

Hi @HuubAppelboom

So the legitimate interest test could be successfully applied to both IMEI and the salted / hashed version, though I take the point that it may be easier to get agreement for the salted / hashed version.

But what would be the ant-fraud use case here? If the API consumer wanted to check whether a particular mobile subscriber was using a device with a fraud marker, then the initial input to that check would be the subscriber identifier (e.g. MSISDN) rather than IMEI or salted / hashed IMEI. So the legitimate interest test would be applied to MSISDN in that case. Potentially the IMEI Fraud API could accept MSISDN as the input for that use case, thus avoiding the need to for the API to divulge any physical device identifier.

I can see that maybe the API consumer wants to track the "fraud history" of a physical device without knowing its true identity. In that case, the salted / hashed IMEI could be used, output once from Device Identifier and then used as an input to IMEI Fraud (maybe setting up notifications for any status change). But that appears an unlikely use case to me.

For authentication, I can see that knowing a mobile subscriber is using the same device as previously (or one of a set) without knowing the true identity of the device reduces the "personal information" content of the transaction. But, again, the input will be MSISDN (or some other subscription identifier), which is a way more sensitive personal identifier than IMEI will ever be. Also, there is a separate "Device Swap" API in progress, which will state whether the SIM has been recently moved to a new physical device without revealing the identity of the new device, and we should not try to duplicate that use case here.