4 ms·

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

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.

piyuv 3y ago
[dead]
greggsy 3y ago
I'm all for transparency - including whether it needs persistent local data
- akmarinov 3y ago
  That's not it though - you can still write a file right next to the UserDefaults plist with anything you want without having to declare anything.
  - mynameisvlad 3y ago
    Just because you can still do potentially malicious things through other means does not change the reasoning, intent or need for the UserDefaults change. 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.
    - lapcat 3y ago
      > It’s literally a 2 second process, and it’s meant to provide transparency into what the developer is doing. 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.
- agloe_dreams 3y ago
  I would love to find a single app that doesn't. Onboarding screen? Persist. Saved Token after login? Persist. Save Last selected X? Persist.
creshal 3y ago
The documentation states that > 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.
- lapcat 3y ago
  This only applies to App Store apps. Mac App Store apps are sandboxed, just like iOS App Store apps.
enos_feedler 3y ago
From UserDefaults developer docs [1]: "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/userdefaults https://developer.apple.com/documentation/foundation/userdef...
- enos_feedler 3y ago
  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/nsubiquitouskeyvaluestore https://developer.apple.com/documentation/foundation/nsubiqu...
- KnobbleMcKnees 3y ago
  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.
- lapcat 3y ago
  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.
TimCTRL 3y ago
It could also be because we combine UserDefaults + App Groups to allow known apps to access shared data [1] 1. https://developer.apple.com/documentation/xcode/configuring-app-groups https://developer.apple.com/documentation/xcode/configuring-...
- lapcat 3y ago
  App groups already have to be declared in the app's entitlements, so this would be redundant.
  - TimCTRL 3y ago
    True
st3fan 3y ago
Why is it wild? They are not telling you to not use UserDefaults anymore. The only thing you have to do is say “I store the users preferred sort order of the thinger list in UD” or whatever your non-malicious app does. 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.
- JamesSwift 3y ago
  Its just a pointless friction point. Both for devs and users. 100% of the apps you use will have this permission. No user is going to deny the request. Its the same as the Android 'network' permission, which no one bats an eye at. 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?

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.

piyuv 3y ago

[dead]

greggsy 3y ago

I'm all for transparency - including whether it needs persistent local data

akmarinov 3y ago
That's not it though - you can still write a file right next to the UserDefaults plist with anything you want without having to declare anything.
- mynameisvlad 3y ago
  Just because you can still do potentially malicious things through other means does not change the reasoning, intent or need for the UserDefaults change. 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.
  - lapcat 3y ago
    > It’s literally a 2 second process, and it’s meant to provide transparency into what the developer is doing. 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.
agloe_dreams 3y ago
I would love to find a single app that doesn't. Onboarding screen? Persist. Saved Token after login? Persist. Save Last selected X? Persist.

creshal 3y ago

The documentation states that > 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.

lapcat 3y ago
This only applies to App Store apps. Mac App Store apps are sandboxed, just like iOS App Store apps.

enos_feedler 3y ago

From UserDefaults developer docs [1]: "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/userdefaults https://developer.apple.com/documentation/foundation/userdef...

enos_feedler 3y ago
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/nsubiquitouskeyvaluestore https://developer.apple.com/documentation/foundation/nsubiqu...
KnobbleMcKnees 3y ago
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.
lapcat 3y ago
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.

TimCTRL 3y ago

It could also be because we combine UserDefaults + App Groups to allow known apps to access shared data [1] 1. https://developer.apple.com/documentation/xcode/configuring-app-groups https://developer.apple.com/documentation/xcode/configuring-...

lapcat 3y ago
App groups already have to be declared in the app's entitlements, so this would be redundant.
- TimCTRL 3y ago
  True

st3fan 3y ago

Why is it wild? They are not telling you to not use UserDefaults anymore. The only thing you have to do is say “I store the users preferred sort order of the thinger list in UD” or whatever your non-malicious app does. 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.

JamesSwift 3y ago
Its just a pointless friction point. Both for devs and users. 100% of the apps you use will have this permission. No user is going to deny the request. Its the same as the Android 'network' permission, which no one bats an eye at. 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?