Apple Developers Required to Justify Use of Some APIs in Latest Move to Boost Privacy

[MisterSavage]

But again, the whole privacy issue here, isn’t about protecting specific data or policing how you use your preferences store; Apple has long stated it’s a bad idea to store sensitive information in UserDefaults anyway.

Yeah I definitely wouldn't do that. The data I store is as mundane as can be.

 

[prime17569]

Indeed.

In this case you have to go out of your way in the app to enable it, though, and the app is absolutely clear about what you're doing. It's nothing sinister, so Apple may continue to allow it.

But holy crap, a simple "keepalive" API, with some sensible restrictions (maybe no more than an hour unless you revisit the app, or something) would be phenomenal.

This post by Quinn (aka "eskimo") from Apple DTS might be relevant: https://developer.apple.com/forums/thread/685525

 

[prime17569]

And the fact that you think blocking this from use is going to make doing fingerprinting any harder is laughable.

Let me tell you a single line that is valid and covers full access to the list of API'S. "Improve system/app performance. Improve use for the user. Monitoring system performance".

The api listed are amount the most common one used ALL apps. System defaults is pretty much used on any app in some way. Screen size is again super common to use.

If apple wants to make it harder simple load basic things for like phone name appa read. Just say iOS device or iPhone there and it makes more useless for tracking purposes. In my own app development I have used the phone name to find my own test data to make sure something was working right.

The stuff they are blocking or requiring stuff just means paper work at best for the most commonly used Apis.

FYI Apple is only letting you pick from a list of reasons that they have approved. "Improving system/app performance" is not one of them. You can check the full list here:

Describing use of required reason API | Apple Developer Documentation

Ensure your use of covered API is consistent with policy.

developer.apple.com

 

[prime17569]

As others have said, I think it's unfortunate that Apple have decided to add this extra layer of app review paperwork rather than actually fixing what are surely bugs. Apps just shouldn't be able to read things from NSUserDefaults that don't belong to them! (I had no idea this was possible until I saw the list). Similarly, if apps can fingerprint the device by reading the timestamps of files outside their container, that should be fixed by giving those files 1970-01-01 timestamps.

My guess is that this is a stopgap measure to give them a reason to reject apps using these APIs while they fix the system frameworks. UserDefaults in particular is ubiquitous, so it might take them a while to make sure that the system frameworks aren't leaking any data into it.

 

[VulchR]

So you work in Academia, very different stuff

There's a world of difference between academic users, b2c, b2b, or worse, "enterprise". Work with enterprise users and then you'll understand why you don't want to over explain stuff they don't understand but they'll pretend they do, I learned it the hard way

Agreed - absolutely there is a difference between coding for academics and coding for lay people. Academics have less common sense. However, perhaps you are overgeneralising from a few bad experiences with lay people. Indeed, younger people are far more savvy about computers than most older people, so I wonder i the demographics of computer literacy will change. Certainly in my department (neuroscience and behavioural science) it is now hard to find a student that hasn't at least dabbled in Python, and frankly, if one can understand a recipe, one can understand code. Moreover, it doesn't hurt to educate people. I think that providing multiple layers of detail - from a very general message to something a technical expert could use - allows people to choose which information they process, and everybody lives.

 

[1129846]

Agreed - absolutely there is a difference between coding for academics and coding for lay people. Academics have less common sense. However, perhaps you are overgeneralising from a few bad experiences with lay people. Indeed, younger people are far more savvy about computers than most older people, so I wonder i the demographics of computer literacy will change. Certainly in my department (neuroscience and behavioural science) it is now hard to find a student that hasn't at least dabbled in Python, and frankly, if one can understand a recipe, one can understand code. Moreover, it doesn't hurt to educate people. I think that providing multiple layers of detail - from a very general message to something a technical expert could use - allows people to choose which information they process, and everybody lives.

I have learned the lesson of providing them with to much even as you say it can and does blow up in your face. They will google the more cryptic error message or more detail part of it and get hooked in on it. You get them going down red herring or they freak out about nothing.

Hence often time a fairly generic message can cover most case. It can be annoying to some people but it prevents them freaking out about some random error code or showing them that an internal object has an issue (inside joke)

It is a balance point between showing enough and showing to much. I tend to put debug levels in my code and if it is a debug build you are damn right I print out more of the error message and include some error codes but I can translate them. Also some of the code are very internal codes so only the developers working on the project have any clue what they mean.

It is a fine balance as far to many people read something and freak out not understanding its true meaning. They hear a word they understand and freak out when it is nothing or OMG you can not mess with that.

 

[albebaubles]

You…realize Facebook and Instagram are both run by Meta, right? And that users with accounts on both social networks often have those accounts linked? This seems like the worst possible example of how UserDefaults could, in theory, be misused.

You.....realize a lot of people use insta and not Facebook, right? Perhaps not.

 

[jonblatho]

You.....realize a lot of people use insta and not Facebook, right? Perhaps not.

I'm well aware, which is why I prefaced the second sentence with "users with accounts on both social networks." The point is that Meta doesn't need to use UserDefaults for sharing data between its own apps, at least not Instagram and Facebook (and Threads and Messenger and WhatsApp and...), because these apps require the user to sign up or log in to be useful at all, in which case Meta's able to collect all the data it wants by sending it directly to its own servers, associating it directly with the user's linked accounts, without having to ever touch UserDefaults. Whatever you're talking about is a distinction without a difference.

That's to say that regardless of how many/which apps of theirs you use, or even if you use none of them at all, Meta knows who you are.

 

[_Spinn_]

Good for user privacy. Hopefully this doesn’t cause developers to yell more about the App Store.

 

[VulchR]

I have learned the lesson of providing them with to much even as you say it can and does blow up in your face. They will google the more cryptic error message or more detail part of it and get hooked in on it. You get them going down red herring or they freak out about nothing.

Hence often time a fairly generic message can cover most case. It can be annoying to some people but it prevents them freaking out about some random error code or showing them that an internal object has an issue (inside joke)

It is a balance point between showing enough and showing to much. I tend to put debug levels in my code and if it is a debug build you are damn right I print out more of the error message and include some error codes but I can translate them. Also some of the code are very internal codes so only the developers working on the project have any clue what they mean.

It is a fine balance as far to many people read something and freak out not understanding its true meaning. They hear a word they understand and freak out when it is nothing or OMG you can not mess with that.

I understand what you are saying, but think of it from the users' perspectives. They have many questions. Is the error serious? Can it affect the function of the app, for instance causing miscalculations or compromising the document currently being used? Does this reflect some sort of hardware error indicating that the computer is about to fail? Is the developer aware of the issue? What should be done to recover from the error - restart the app, restart the machine, or uninstall and reinstall the app? Is the error indicative of a security risk related to malware and viruses? The list goes on.

I note that 'Oops, something went wrong.' and 'This should never happen.' generic error messages answer none of the questions above, leaving the user to guess whether the error is just one of those things or their whole system is about to go belly up. And often, even for huge companies like Microsoft, help forums are not run by professionals working for the company, but users engaging in guesswork guiding other users. Not providing users with more detailed information in error messages won't prevent them from speculating about what is wrong. Providing information to them could prevent them from wasting time troubleshooting and causing more damage by fiddling with settings.

Imagine you are driving your car along a desolate highway and get an error message 'Oops, something went wrong.'