Hacker News Reader

Comment by ajross | Hacker News Reader

Yeah, this is much clearer than The Register's attempt to summarize/explain/sensationalize it.

And the meat seems... pretty bland. They caught a bunch of "plausibly fingerprinty"[1] tokens (that a reasonable interpretation of Apple policy would require being stored on the device) being sent unobfuscated in later requests.

That looks a lot more like a genuine mistake by developers than a real attempt to evade tracking controls to me.

[1] But... not very? Seems like they're mostly concerned with system uptime. And, sure, boot time can be a fingerprint, but by definition an ephemeral one. In combination with other techniques, sure, maybe there's a way to construct an user profile. But alone? Meh. And it seems like that's all the investigators found.

View on HN

Uptime might be somewhat ephemeral, but it can be a pretty clear signal to indicate that two different user profiles are actually the same person. For example, it would be a plausible explanation for why even when I took several steps to hide my identity when creating a new Meta account (new Safari profile, tracking blockers, VPN, anonymous email account, etc), Facebook immediately suggested all of the contacts from my other account as friends. Or perhaps they picked up on some other signal. My point is, I absolutely don't consent to my devices sending their uptime to third parties without explicitly asking me every time.

Did you use a different device and phone number or friend a mutual friend/yourself or allow contact access? That hasn't been my experience having 2 Meta accounts

Uptime can be pretty long on iOS devices, and the developers have no legitimate use for that information.

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/nsproce...

Cupertino, if you're listening, I'm not comfortable with the offset either, that would also do fine as an identifier.

You expect apps to have no access to a simple monotonic timer?

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?

I 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.

If there's a random offset applied, how would they have access to the actual system uptime?

I don’t know, like I said, I expect Apple to figure that out. Their engineers get paid to figure out such problems, not me!

My original response in this thread was to a comment that said, "I'm not comfortable with the offset either".

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.

The first-time-the-app-called-the-api-since-device-boot is just as unique as device-boot-time.

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.

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)

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.

Surely the fix here is to lie to apps about uptime, adding the offset at the OS level.

"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.

Adding an offset would still make this "derived data" which is "not allowed" to be sent off device.

At Google/Meta's scale, there is / ought to be less room for such "genuine mistakes" as they have the resources and clout to preempt them.

> That looks a lot more like a genuine mistake by developers

Can we please stop handing "assume good faith" to megacorps? That's something you grant to individuals, not to companies whose entire existence revolves around doing nefarious things like this. There are no genuine mistakes, there are exclusively bad faith actions that should be coupled with company-funded third party investigation and public disclosure to determine impact along with varying levels of prosecution wherever possible to act as both punishment and deterrent even if it turns out to be a genuine mistake.

Reply on news.ycombinator.com