The only monotonically increasing clock available on iOS is based on uptime. If you need to measure accurate timings or guarantee that events are in the right order, you have to use it. As Apple points out in their guidelines, there are many legitimate uses for this information.
Developers can add an offset to the values before sending them off the device, and that might be what Apple wants them to do, but these companies have over a decade of pre-existing code that didn't do this. It's not surprising to me that there are things that haven't been updated yet given that Apple only made these requirements public fairly recently.
"boot time plus random offset" is going to be just as much of a fingerprint as "boot time" is, though (the offset can't change once picked for a boot because the whole point is to be able to calculate the time between events in the app).
Something that reduces the granularity a lot, like "time since UTC 00:00:00 on the day of the last device boot", might work.
Make the offset app-specific. Then pretend the phone ran out of memory and ask the app to terminate every now and then, switch to a new random offset for every run.
It could be useful if you want to prompt a user to reboot their phone because something isn't working and a reboot often helps. But if they just rebooted, telling them to reboot if they've just rebooted is going to annoy them for no reason.
Things like the user gave permission for camera or microphone and is trying to use them but there's no data coming through. Or really most anything with Bluetooth. Or sometimes their mobile network is being weird.
That probably doesn't justify sending it off the device as a raw value, but Meta really likes driving UI from the server instead of letting the phone be smart. And they have a habit of pushing Apple's limits.
(Disclaimer: I worked for a subsidiary until the end of 2019)
Not sure why you're being downvoted for this, iOS devices aren't servers, apps have very little control over their lifecycle, and the existing time APIs for an app's internal sense of time are plenty. There is no reason at all an app would need to know this random piece of global state. I'm not even sure why Apple offers the real uptime instead of an offset starting when the app first called the API.
Apps don't need it, and it probably shouldn't be offered. But as things stand, many of the OS's fundamental time APIs return time since boot, and for some reason, most of those aren't even listed as required-reason APIs. The APIs listed are mach_absolute_time() and ProcessInfo.systemUptime, but there is also clock_gettime() with CLOCK_MONOTONIC/CLOCK_MONOTONIC_RAW/CLOCK_UPTIME_RAW, as well more obscure ones like mach_continuous_time().
Therefore:
- I find it easy to believe that some of the apps may not realize they're using the restricted APIs in an unapproved way.
- Alternately, some of the apps may not be using restricted APIs at all, and instead getting the same information with non-restricted APIs. Not clear if that's even against the rules. It certainly would be extremely sketchy if done as an intentional workaround, but it would be even easier to do accidentally. If you grepped the codebase for uses of the restricted APIs, you wouldn't necessarily find uses of these other APIs.
I expect privacy theater; I err towards having opinions that enforce privacy - i.e. a time that's guaranteed to be x seconds since the app first started after system boot can be used to diminish privacy
Why would you expect privacy theater, though. Apple genuinely tries to frustrate this kind of snooping from (third-party) apps, so if they choose to obfuscate the timer in the first place, I don't see what the point is for them to make it a security theater. The obvious and trivial implementation for this is adding a random number, and that's what any minimally competent dev will do unless specifically told otherwise. So, why would they be told otherwise?
It isn't though, at least not in the same way. It's not as if apps can't generate unique identifiers like a UUID. What's important for fingerprinting isn't that it's unique but that it's stable across different apps which this wouldn't be. You could maybe try to eek out a bit of information with "value is greater than" but it would be hard to orchestrate because you can't guarantee that all apps will be first used around the same time.
Developers can add an offset to the values before sending them off the device, and that might be what Apple wants them to do, but these companies have over a decade of pre-existing code that didn't do this. It's not surprising to me that there are things that haven't been updated yet given that Apple only made these requirements public fairly recently.