It makes no sense whatsoever.

(1) Nearly every app in the App Store uses UserDefaults. It's such a basic, fundamental API.

(2) App Store apps are sandboxed, so they cannot access the UserDefaults of another app.

(3) UserDefaults is more or less glorified key-value storage. It's true that you could store a UUID in there, but you could just as easily store a UUID in a text file in your app's container, an API usage that is not covered by this.

(4) According to the docs, there's only one allowed "reason":

> CA92.1

> Declare this reason to access user defaults to read and write information that is only accessible to the app itself.

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

But again, as I said in (2), "reading information that was written by other apps or the system, or writing information that can be accessed by other apps" is not even possible for sandboxed apps.

In other words, almost every app in the App Store will have to declare "CA92.1" in a privacy manifest, and if every app has the same response, then nothing is accomplished except privacy theater and some unjustified good PR for Apple.

> In other words, almost every app in the App Store will have to declare "CA92.1" in a privacy manifest, and if every app has the same response, then nothing is accomplished except privacy theater and some unjustified good PR for Apple.

I disagree. It gives Apple a tool to refer to when an app says A but does B. If you are a malicious app and you lie about any of these things then kicking you off the App Store is a simple decision.

In the past you could get away with just doing it in code. Now you have to declare that your usage is non malicious. That is a huge difference.

> Now you have to declare that your usage is non malicious.

That's not even what you're declaring! I already quoted Apple's docs: "Declare this reason to access user defaults to read and write information that is only accessible to the app itself."

But sandboxing already makes this impossible, so the only thing you're declaring is that your app only does what the operating system allows it to do. Nothing about maliciousness or fingerprinting.

Moreover, the only way that Apple can actually detect fingerprinting is to reverse engineer the app, which Apple could do anyway regardless of whether developers self-report. Self-reporting is basically useless, because violators will simply lie.

Apple can already kick you out of the App Store for any reason, or no reason. And they could make a public rule against fingerprinting without requiring developer self-reporting, which is mostly a sham.

Why does the tool even matter? They already have no-fingerprinting rules. They can point at that, no need to have every dev on earth explain why they want users to stay logged it and not get the onboarding screen every time the app is opened.

+ why not the keychain APIs?

The Keychain persists between installs, so you can just add the fingerprinting data there instead.

Is it possible there’s some way of abusing UserDefaults that Apple knows about but we don’t?

Also, I guess you could write some values into UserDefaults to uniquely identify users.

> Also, I guess you could write some values into UserDefaults to uniquely identify users.

I already said this: "UserDefaults is more or less glorified key-value storage. It's true that you could store a UUID in there, but you could just as easily store a UUID in a text file in your app's container, an API usage that is not covered by this."

Thanks. Didn’t notice that part.

If you look at the docs for nsubiquitouskeyvaluestore [1] the fingerprint warning doesn't exist there. So it seems to reason that this is about "source device" identification.

[1] https://developer.apple.com/documentation/foundation/nsubiqu...

Ahh interesting. I could see from the other listed features that this was about guarding against telemetry being used for user tracking. This was not a use case that sprang to mind.