4 ms·
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
by Spivak 3y ago
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.
It's the first thing that talk about in the docs https://developer.apple.com/documentation/foundation/nsprocessinfo/1414553-systemuptime https://developer.apple.com/documentation/foundation/nsproce...
- refulgentis 3y agoCupertino, if you're listening, I'm not comfortable with the offset either, that would also do fine as an identifier.
- int_19h 3y agoYou expect apps to have no access to a simple monotonic timer?
- refulgentis 3y agoI 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
- int_19h 3y agoWhy 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?
- nozzlegear 3y agoI expect Apple to figure out how to provide apps with such a timer in a way that also prevents them from having access to the system uptime.
- int_19h 3y agoIf there's a random offset applied, how would they have access to the actual system uptime?
- nozzlegear 3y agoI don’t know, like I said, I expect Apple to figure that out. Their engineers get paid to figure out such problems, not me!
- int_19h 3y agoMy original response in this thread was to a comment that said, "I'm not comfortable with the offset either".
- comex 3y agoApps 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.
- caf 3y agoThe first-time-the-app-called-the-api-since-device-boot is just as unique as device-boot-time.
- Spivak 3y agoIt 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.