> Hold on, Apple is restricting access to UserDefaults?

That's not how I would characterize it. Per the link above, they've provided a way for developers to declare the reasons their app uses API categories that can be used for fingerprinting.

> Data saved there is already scoped to the app itself, not to other apps or system information

Per the link, it appears that bad actors are somehow using it to violate App Store anti-fingerprinting policies: "This reason does not permit reading information that was written by other apps or the system, or writing information that can be accessed by other apps."

So let's say I store a UUID in UserDefaults - I know on any app install on another device or delete and reinstall I lose track of that ID. In my mind, I'm using this just as an 'App Session' marker to keep track of how many 'events' a typical user goes through in the app.

Is that considered fingerprinting? I really don't care who it is, I'm just trying to make sure the features I'm building are actually being used.

I would think what matters is whether or not you’re attempting to form a shared identity that links activity between devices, installs, site visits etc when the user hasn’t explicitly created an account in all of those places. Basically anything that’d allow you to map out their activity regardless of if they have an account or not is what’s problematic.

With some exceptions (such as social media apps) I don’t think it’s generally first party devs who are doing this, but rather third party SDKs that are popular with devs, e.g. Google Analytics, Firebase, Facebook SDK, etc.

but if its scoped to that app, and is removed on uninstall, how?

That just means that you need to be creative with shuttling data around. Web tracking identifiers can ride in on deep links for example, which are then persisted to user defaults. After these identifiers have accumulated from a few different sources you then have a reasonably high-confidence fingerprint of the user.

To help this along the app can do things like kick the user out to their main browser to do some routine thing, where cookies can be accessed. The user doesn’t need to deep link back to the app in that case, the app can pull down whatever tracking info was harvested during the page visit and persist it.

No. In fact Apple already provides such a per-install UUID for you to use if you wish.

There is more. I am remove an app and reinstall it and my data is still there. So I can be tracked across installs.

And annoyingly there is sometimes no way to delete this data completely.

That's CloudKit's CoreData - at least that's what I've seen work.

As an app user, it is infuriating to me it is even possible to do that.

I installed Overcast on my phone and since a UUID is saved to iCloud, when I installed it on my iPad, it automatically ties it back to my Overcast account without having to explicitly create an account.

The author of Overcast, Marco Arment, did that specifically so he wouldn’t have to store usernames, passwords and emails on his server - increasing privacy.

You can add a username and password to your account if you need to log in to the website. But he really wants to get rid of that requirement too.

That’s the keychain, not user defaults. Amusingly it’s not even included in this list?

Can this scope be shared in some way if you’re the owner of multiple apps? I thought it was strange seeing Threads listed as a 12+ year old app when I know it’s brand new… it gave me the feeling someone could just fudge numbers and more if they’re clever.

I think that’s the age rating for the app.

Oh wow, I’ve misread that for as long as it’s been there. It doesn’t look like a button, but tapping it scrolls the page down to age rating.

Glad I’m not the only one. Even after I eventually realised it’s the age rating and not the age of the app itself, I still find myself constantly forgetting this because it’s so unintuitive.

There is something about the way it’s presented (or maybe a bug in my brain) that keeps reading it as the age of the app.

(And IMHO that would be a lot more useful thing to show in that prominent position too)

No, you can scope it to an App Group shared across all apps in one account (Team ID). Google uses this to aggressively fingerprint — if you’re signed in to Google Voice, your actions in Google Maps will still be associated to your account even if you’ve never signed in.

That's not really fingerprinting - it's just ensuring your login is consistent against the apps of a single vendor

I don't think Apple are aiming to change that with this

The fact that Keychain isn't in this list of APIs despite also being available to all apps by a developer (and optionally synced via iCloud) also points to them being OK with shared logins between apps (or they just forgot???)

It seems like they forgot the actual API that allows tracking users across installs, lol

I dont think the keychain can be used to track...

Just to the same or slightly higher extent as UserDefaults which is on this list

Fingerprinting is more of an intent. Google will absolutely tell you it's just to ensure consistency among their products. Their most important product being targeted advertising. Using it to enable consistent targeted advertising would be what the advertising industry calls fingerprinting.