4 ms·

I would argue that apps should almost never need access to some of those, like boot time (why?), free space (not meaningful in the era of dynamic offloading to

by 542458 3y ago

I would argue that apps should almost never need access to some of those, like boot time (why?), free space (not meaningful in the era of dynamic offloading to iCloud), and active keyboard (just accept whatever input you’re given). With the benefit of hindsight, User Defaults seems like a bit of a poorly designed API.

lordgilman 3y ago
They all seem like APIs that could be abused to fingerprint the device, e.g. no two phones are going to have the same free disk space and no two devices behind the same IP address are going to have the same uptime.
iamcalledrob 3y ago
File timestamp and free space are likely to be used by just about any app that imports a caching library, e.g. for images. I predict a flood of app rejections due to developers unknowingly using these APIs as part of a dependency. Things like stat() are so fundamental that you'll pretty much always find them somewhere in a moderately sized code base.
- 542458 3y ago
  File timestamp is a hard one, I’m not really sure what the “correct” way to implement that is while preserving privacy. Maybe hiding timestamps on files not owned by that app? But free space (if being used for caching purposes): Why not just try to save to .cachesDirectory? If there’s no space the file save will fail, which is fine, your app should handle that anyways. If there’s low but sufficient space that fine, the OS will evict the file soon enough.
  - iamcalledrob 3y ago
    Re: timestamps, the app is already sandboxed and is limited in the files it can read. It's strange that they're seemingly locking down timestamps tighter than the data itself? For free space, it's pretty common for iOS apps to restrict functionality when your device is critically low on space -- because having most disk writes fail can be very difficult to handle. You also might want to implement a cache policy that's "greedier" when there's plenty of free space. I think there are plenty of reasons to want to know how much free space is available. I feel like offering lower fidelity values may be a better of handling these privacy concerns rather than adding further complexity to the already onerous app review process. For example, for files your app doesn't own, round timestamps to the nearest second, and free space to the nearest 100mb. Most legit use-cases won't need more than this level of fidelity.
  - fbdab103 3y ago
    For disk space, you think they could just report sufficiently rounded numbers (eg increments of 256MB free).
agloe_dreams 3y ago
I have zero clue why they are gatekeeping UserDefaults. Basically every app on earth uses it for even simple details like preventing show of onboarding/tour screens and it is fully sandboxed. If they are worried about some data access or such that one can do with User Defaults, put that behind an entitlement or change default behavior. Mark my words, this goes two ways: 1. Apple rolls it back, devs feel like they have power, Apple does security/Dev theater over the whole ordeal. 2. Massive App store review issues for 99% of apps on the store.

by 542458 3y ago

lordgilman 3y ago

They all seem like APIs that could be abused to fingerprint the device, e.g. no two phones are going to have the same free disk space and no two devices behind the same IP address are going to have the same uptime.

iamcalledrob 3y ago

File timestamp and free space are likely to be used by just about any app that imports a caching library, e.g. for images. I predict a flood of app rejections due to developers unknowingly using these APIs as part of a dependency. Things like stat() are so fundamental that you'll pretty much always find them somewhere in a moderately sized code base.

542458 3y ago
File timestamp is a hard one, I’m not really sure what the “correct” way to implement that is while preserving privacy. Maybe hiding timestamps on files not owned by that app? But free space (if being used for caching purposes): Why not just try to save to .cachesDirectory? If there’s no space the file save will fail, which is fine, your app should handle that anyways. If there’s low but sufficient space that fine, the OS will evict the file soon enough.
- iamcalledrob 3y ago
  Re: timestamps, the app is already sandboxed and is limited in the files it can read. It's strange that they're seemingly locking down timestamps tighter than the data itself? For free space, it's pretty common for iOS apps to restrict functionality when your device is critically low on space -- because having most disk writes fail can be very difficult to handle. You also might want to implement a cache policy that's "greedier" when there's plenty of free space. I think there are plenty of reasons to want to know how much free space is available. I feel like offering lower fidelity values may be a better of handling these privacy concerns rather than adding further complexity to the already onerous app review process. For example, for files your app doesn't own, round timestamps to the nearest second, and free space to the nearest 100mb. Most legit use-cases won't need more than this level of fidelity.
- fbdab103 3y ago
  For disk space, you think they could just report sufficiently rounded numbers (eg increments of 256MB free).

agloe_dreams 3y ago

I have zero clue why they are gatekeeping UserDefaults. Basically every app on earth uses it for even simple details like preventing show of onboarding/tour screens and it is fully sandboxed. If they are worried about some data access or such that one can do with User Defaults, put that behind an entitlement or change default behavior. Mark my words, this goes two ways: 1. Apple rolls it back, devs feel like they have power, Apple does security/Dev theater over the whole ordeal. 2. Massive App store review issues for 99% of apps on the store.