Requiring this for UserDefaults is pretty wild as it will be so far reaching.
UserDefaults is also app-scoped so I'm not sure I understand the reason for this as a privacy concern.
UserDefaults is also app-scoped so I'm not sure I understand the reason for this as a privacy concern.
"This API has the potential of being misused to access device signals to try to identify the device or user, also known as fingerprinting."
The reason is because UserDefaults is device scoped. Even within the context of a single application, the developer could use the API to build a list of user devices and identify the particular device the user is accessing the application from. Absurd? Perhaps. But it falls within the definition of what they are aiming to eliminate.
[1] https://developer.apple.com/documentation/foundation/userdef...
[1] https://developer.apple.com/documentation/foundation/nsubiqu...
(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.
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."
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.
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.
The Keychain persists between installs, so you can just add the fingerprinting data there instead.
There is no magic here. I see a lot of complaining here but for 99.9% of devs it is a one time two minute check mark exercise.
For devs, is Apple going to now audit your `UserDefaults` usage and deny an app update because you forgot to enumerate that you _also_ store preferred start page in your new release? Why even add this mental energy to the process unnecessarily?
1. https://developer.apple.com/documentation/xcode/configuring-...
> This API has the potential of being misused to access device signals to try to identify the device or user, also known as fingerprinting. Regardless of whether a user gives your app permission to track, fingerprinting is not allowed.
I think this is mostly aimed at MacOS apps, where the scopes are much more relaxed for backwards compatibility reasons? My guess is that iOS apps will be automatically approved.
If you want to write data without providing a reason, then go do that. Until Apple requires reasons for file writes.
It’s literally a 2 second process, and it’s meant to provide transparency into what the developer is doing. That seems entirely beneficial to users. Sorry that being honest and taking a few seconds of your time is such a heavy burden.
What transparency? Almost every app in the App Store uses UserDefaults, and the only allowed reason to use it is, literally, "CA92.1". How is that transparency?
> That seems entirely beneficial to users.
How, exactly?
> Sorry that being honest and taking a few seconds of your time is such a heavy burden.
The dishonest developers will give the exact same "reason" as the honest developers. It's security theater.
Onboarding screen? Persist. Saved Token after login? Persist. Save Last selected X? Persist.