Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google, Meta 'break' Apple's device fingerprinting rules

theregister.com

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Google, Meta 'break' Apple's device fingerprinting rules

#51

Post by ElFitz »

kernal wrote: post #28
poochkoishi728 wrote: post #14

Earlier quoted context omitted.

Devil's advocate: People using Android accept (for whatever reason) a less fluid, subpar UI and UX, while iPhone users are less likely to tolerate it (by nature of not using Android). Thus, using an iPhone could actually suggest a more sophisticated sense of taste i.e. being cooler.

Devil’s brother advocate: People prefer using iOS over Android because they cannot handle having complete control over their UI and UX. They prefer having strict rules on what they can and cannot do and what apps they can and cannot use.

Not entirely untrue. The last time I had an Android, I rooted it, replaced the boot animation with a Tardis, installed some anti-virus / anti-theft app that silently forwarded all received sms to my other number (and realised after selling it I hadn’t properly removed it).

By the end of that first weekend I had had to reinstall Android / AOSP a dozen times, only to realise Monday morning I had somehow screwed up the cellular stack so I couldn’t use it.

That’s when I realised I couldn’t trust myself with that kind of power.

Re: Google, Meta 'break' Apple's device fingerprinting rules

#52

Post by [deleted] »

idle_zealot wrote: post #45
jonas21 wrote: post #40

Earlier quoted context omitted.

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 comp…

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

[deleted]

Re: Google, Meta 'break' Apple's device fingerprinting rules

#53

Post by int_19h »

refulgentis wrote: post #34
Spivak wrote: post #23

Earlier quoted context omitted.

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 t…

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?

Re: Google, Meta 'break' Apple's device fingerprinting rules

#54

Post by littlestymaar »

Dudhbbh3343 wrote: post #44
calmworm wrote: post #19

Earlier quoted context omitted.

Right. This is the most basic level of marketing. Is this not as widely known as I assumed it was?

How does it work exactly? Google sells lists of search terms and associated device ids to Meta?

IIRC not to Meta themselves but to Meta's customers (I mean, the advertisers, which are the ones who pay. You the user aren't Meta's customer, you are their product) but it's been a long time since I hear Criteo's technical pitch so I don't remember how it works.

Re: Google, Meta 'break' Apple's device fingerprinting rules

#55

Post by refulgentis »

int_19h wrote: post #53
refulgentis wrote: post #34

Earlier quoted context omitted.

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

Re: Google, Meta 'break' Apple's device fingerprinting rules

#56

Post by sriku »

ajross wrote: post #15
gruez wrote: post #5

Original source, buried within the article: https://www.mysk.blog/2024/05/03/apple-required-reason-api/

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…

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.

Re: Google, Meta 'break' Apple's device fingerprinting rules

#57

Post by DEADMINCE »

poochkoishi728 wrote: post #14
SunlitCat wrote: post #4

Earlier quoted context omitted.

[flagged]

Devil's advocate: People using Android accept (for whatever reason) a less fluid, subpar UI and UX, while iPhone users are less likely to tolerate it (by nature of not using Android). Thus, using an iPhone could actually suggest a more sophisticated sense of taste i.e. being cooler.

Honestly I think the iPhone UI is vastly inferior to Androids. I mean, jesus, they didn't even have folders or widgets until a couple of years ago.

Re: Google, Meta 'break' Apple's device fingerprinting rules

#58

Post by caf »

idle_zealot wrote: post #45
jonas21 wrote: post #40

Earlier quoted context omitted.

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 comp…

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.

Re: Google, Meta 'break' Apple's device fingerprinting rules

#59

Post by DEADMINCE »

SunlitCat wrote: post #39
samplatt wrote: post #25

Earlier quoted context omitted.

Devil's advocate or just trolling? I can't bloody stand using Apple's unintuitive garbage. I have great admiration for the hardware, but trying to drive their O/S I've always found to be a horribly frustrating experience.

While their mobile OS doesn't differ much in usability from android phones, the ux / ui on their desktop operating system can be quite frustrating, confusing and especially if you come from a windows world, outright weird.

I think it's poorly made, inconsistent and unintuitive no matter what you're used to.

Re: Google, Meta 'break' Apple's device fingerprinting rules

#60

Post by caf »

Spivak wrote: post #23
KerrAvon wrote: post #18

Earlier quoted context omitted.

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 t…

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