Live Caller ID: Multiple userIdentifier values for same device - Expected behavior?

Question

Created 1w

Replies 2

Boosts 1

Participants 2

Hello! We're currently testing Live Caller ID implementation and noticed an issue with userIdentifier values in our database.

Initially, we expected to have approximately 100 records (one per user), but the database grew to about 10,000 evaluationKey entries. Upon investigation, we discovered that the userIdentifier (extracted from "User-Identifier" header) for the same device remains constant throughout a day but changes after a few days.

We store these evaluation keys using a composite key pattern "userIdentifier/configHash". All these entries have the same configHash but different userIdentifier values.

This behavior leads to unnecessary database growth as new entries are created for the same users with different userIdentifier values.

Could you please clarify:

Is this the expected behavior for userIdentifier to change over time?
If yes, is there a specific TTL (time-to-live) for userIdentifier?
If this is not intended, could this be a potential iOS bug?

This information would help us optimize our database storage and implement proper cleanup procedures. Thank you for your assistance!

Answered by DTS Engineer in 826582022

Replying to myself:

However, there probably is an upper time boundary above which you could discard the tokens knowing they will never be used again. I'm checking with the engineering team to see what guidance I can provide.

Currently, any evaluation key will not be used again after ~7 days, so my recommendation would be that you add a generous pad to that time window and then discard. In concrete terms, I would something like:

Monitor for evaluation key usage after the expected expiration (say, 8+ days) and “raise an alarm” if you ever see late usage.
Discard data 10 - 14 days after issue (or however much longer you choose).

This approach lets you avoid accumulating data while also letting you detect if/when anything has changed and giving you plenty of time to adjust before anything disruptive happens.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

6d

Is this the expected behavior for userIdentifier to change over time?

Yes. As described in "Understanding how Live Caller ID Lookup preserves privacy", one of the major architectural goals is to make it impossible for your server to reliably connect users to their "activity". A big part of that is not providing a stable identifier.

If this is not intended, could this be a potential iOS bug?

As I said, the behavior is absolutely intentional.

If yes, is there a specific TTL (time-to-live) for userIdentifier?

No and maybe. We haven't documented any specific value and I don't think we will, as there is a history of this sort of "exact" behavior being used to attack this type of protocol.

However, there probably is an upper time boundary above which you could discard the tokens knowing they will never be used again. I'm checking with the engineering team to see what guidance I can provide.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

1

Answer 2

DTS Engineer OP

Apple

5d

Recommended

Replying to myself:

However, there probably is an upper time boundary above which you could discard the tokens knowing they will never be used again. I'm checking with the engineering team to see what guidance I can provide.

Currently, any evaluation key will not be used again after ~7 days, so my recommendation would be that you add a generous pad to that time window and then discard. In concrete terms, I would something like:

Monitor for evaluation key usage after the expected expiration (say, 8+ days) and “raise an alarm” if you ever see late usage.
Discard data 10 - 14 days after issue (or however much longer you choose).

This approach lets you avoid accumulating data while also letting you detect if/when anything has changed and giving you plenty of time to adjust before anything disruptive happens.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0