Hacker News Reader

Comment by CharlesW | Hacker News Reader

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

View on HN

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.

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.

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

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

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?

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.

Reply on news.ycombinator.com