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

[Shirasaki]

Surely tightening their grip on their user data Day after day, protecting Them fiercely from any parties that are not Apple. Remember, Apple is not bound to those rules they create, and because how close iOS is compared to macOS, it is incredibly difficult for outsiders to know whether they will honor their own rules or not.

What's next? Charging for certain APIs

$1m each month on using API and/or access Apple services past a threshold.

 

[Shirasaki]

I am going to speak as an app developer. This is just going to make things a huge pain in the rear in already a horrible painful process with next to any real gains in privacy if anything at all.

Cutting off easy access to things like userdefaults we all us to store basic things in is well just stupid. I store user preferences in there or have I shown some screen to explain to a new user how something work. Hey what was the last version of the app launch to know do I need to show patch notes.
What color theme does the user want to us.

For screen size stuff. I grab that often times to do minor changes to the layout. On smaller screens I have a smaller default padding to scrape up a little more space. This is also true why the device is grab device for slightly different things to show the user.

If you think it is going to slow down fingerprinting that is a joke. All this is just more paper work to make things more difficult. The biggest part of tracking everyone us is having you create an account then it does not matter at all. They have an account on you.

I am not a developer, but I totally agree with your point of view. Apple is not protecting user privacy out of their goodness of heart. They protect user privacy because their user data holds a lot more value than what Google has: a demographic with greater purchasing power and more loyal, plus many other benefits they are not telling us. I don’t know why Apple want to make third party dev life more difficult, but if that’s their effort to protect their user data, I think it is not a very good one. Regardless, Apple doesn’t have to abide their own rules, so they can link their first party apps closer than everybody else, hindering competition in the process.

Rejected in terms of REJECTED means apple rejected a build for a release of an app. It does not mean much. Almost every app out there has been rejected at least once if not more than once. Oh and here is a kicker for you. Often times no changes are made and just resubmit and it goes through. Counts as a rejection but not really.
That or it is some minor paper work thing or something stupid.

Believe me the app review process is more of an exercise in frustration than anything else. It is massively inconsistent. Things approved for years are all of a sudden rejected even though that had not been touched ever. Hell one app I worked on we got rejected multiple times for the exact same thing that we already had written on why Apple is wrong on it and they agree. New review comes in same thing and our response was copy pasted from the last time and point to Apple own response at saying they were wrong. We rinsed and repeated that about every 6 months.

I have to wonder how third party app stores will behave in terms of review and approval process. Gotta motivate Apple some way if third party app stores are enforced. However, I also have suspicion that third party app stores gonna be crippled to the level of nothing they can do compared to Apple, making their first party one more favourable than third party ones. Only difference in Google world, play store is collectively chosen by most devs while Apple forces people to stick to their first party store despite being forced to allow third party App Store on their closed source iOS.

 

[thejadedmonkey]

Without you knowing it FB could hoover up data insta is dropping into user defaults.

Right, or they could just slurp up the insta data and link it to your account that's on their server.

They could also use keychain to implement a device specific key, so even if you uninstall and re-install the app they can persist settings and track you. They can implement location APIs, to keep the app running in the background. They could do so much, that allowing instagram to slurp up data collected from the facebook app, or the threads app, is so minor it's not even worth mentioning.

 

[jonblatho]

Maybe - I bet they have some Grade A decompilation techniques. They invented the language/compiler/apis/libraries/instruction sets/chips….

Comments should be removed completely during compilation. There’d be nothing to decompile.

 

[jonblatho]

Without you knowing it FB could hoover up data insta is dropping into user defaults.

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.

 

[svish]

Very interesting change. Good for privacy

 

[Schmitti81]

Cutting off easy access to things like userdefaults we all us to store basic things in is well just stupid.

Well, you may not have known, that you can read system preferences via UserDefaults.

Storing your own app preferences is not the issue. Reading system settings is.

 

[cmcbhi]

As a consumer concerned about privacy, developers whining doesn't bother me at all. Write good code or go write for Zuck.

 

[fatTribble]

I was a software engineer for decades. Guidelines changed over time, but code reviews were common. You had to schedule a meeting with more senior people and all go sit in a room together. Any and every line of code was open for questions. If code didn’t pass the review, the developer had to go back and rewrite sections, retest everything and then come back for another review. It was not my favorite part of the job, but I did get paid for it.

 

[jlc1978]

As a consumer concerned about privacy, developers whining doesn't bother me at all. Write good code or go write for Zuck.

I would like to see Apple put iPhone users in greater control by along users to block access to information on a per app basis; and develop something similar to iCloud's Hide my Email so when apps do get identifying information it is unique to that app. That would let them have an identifier for subscriptions without giving them information that is easily cross referenced.

 

[1129846]

I would like to see Apple put iPhone users in greater control by along users to block access to information on a per app basis; and develop something similar to iCloud's Hide my Email so when apps do get identifying information it is unique to that app. That would let them have an identifier for subscriptions without giving them information that is easily cross referenced.

I am with you 100% on thus.

Stupid paper wok does not do much to prevent fingerprinting. If apple really wants to make it harder simple make as much as possible return generic information.

Like everything for a given model and os version of the iPhone is exactly the same. It makes fingerprinting harder when all the info is the same.


Instead of making the advertisement id being all 0's on ask not to track have it random guide for each app. It basically makes it harder to filter out the noise and the junk from the real advertising tracking ID and punishes companies for sending it in if not honoring the request

 

[endecotp]

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.

I'm concerned that stat() is on the list of timestamp functions that need a reason for use. stat() returns a record with a whole load of metadata about a file and has many uses unrelated to timestamps, for example simply testing if a file exists, or whether it is a file or directory, or getting its size. But "I'm not using the timestamps that are returned" is not one of the acceptable reasons for using it, so we're all potentially going to have to replace every use of stat() with some awkward alternative (such as trying to open it and checking the error code).

Oh, and I see that the C++ standard functions for reading timestamps are not on the list. So anyone who wants to continue fingerprinting their users can simply use those instead.

 

[nicolas17]

As a developer I can't tell you how much of a pain this is going to be. As a consumer, it's not going to stop me from downloading an app but I guess good to know.

As a consumer you won't see any of this. The justifications are for the App Review team, not for the users.

 

[tinsoldier]

I wish Apple would provide an official API that any app can use to continue running in the background without being suspended. Right now apps like Blink shell have to use the location API to avoid being suspended or killed in the background when doing things like SSH tunnels. This is a hack and something I could see Apple coming down on in the future.

I imagine this is the sort of thing this will stop, they won’t be able to justify using the location API just to keep the app running in the background.

 

[zorinlynx]

I imagine this is the sort of thing this will stop, they won’t be able to justify using the location API just to keep the app running in the background.

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.

 

[thejadedmonkey]

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.

+1 for this.

I am working on an app that connects to a server that runs on the LAN. The use case is about an hour of interaction with the server via my app. Accordingly, I'd expect the user to leave my app and bounce between different apps. I'd love to be able to keep the socket open, so that I can throw events into a live activity, and so that I don't have to keep re-connecting every time the app is foregrounded.

 

[friedmud]

Comments should be removed completely during compilation. There’d be nothing to decompile.

You don’t need comments to understand what a program does. If there is a key alrgorithm (or a calling sequence of external libraries)… a decompiler will give you all the info you need.

Yeah - you don’t take the output of a decompiler and instantly have a program you can build on top of… but it’s enough to get at your “secret sauce”. This is especially true with Apple who owns the whole tool chain.

There are programs out there that will purposely obfuscate all or part of a binary to make decompilation harder… but most people aren’t using them for natively written apps.

They are a bit more popular in non-compiled languages like JavaScript where the lack of compilation means that your code is fairly readable (though - even web-packed JS is pretty obfuscated already… by stripping out comments/whitespace and rewriting all variable names to be as small as possible).

 

[Appleman3546]

It sounds to me like this is a last resort rejection for Apple if they really want to reject but don’t have a good reason. They likely won’t apply this to too many apps since 90% of all apps use this, so discretionary use by Apple on an app by app basis. Add this to the random reasons for rejection list that developers already frequently see

 

[Dremmel]

This change is for Apple's benefit, not ours. They are sewing up the ad market with their Search Ads and don't want any other ad company to have a slice of the pie. As for developers, they can still use user defaults so long as they are not doing anything dubious.

 

[MisterSavage]

I can tell by reading all the comments here who is a real app developer and gets it and then the ones who don't have a clue what it is like. The ones of us who are in the development world know that this new rule change by apple is a complete joke and just is going to make it even more painful and can also tell you nothing is really gained in terms of privacy to the user.

I mean I can't think of any tutorial I read that did NOT include writing to UserDefaults to store app settings. Hell, Apple made it even MORE convenient for us to use UserDefaults when when they introduced @\AppStorage. I'm hoping this will just be a "yes I use this to save settings" entry we fill out and that's the end of it. I really wonder what rejections will be based off of this.

 

[4389842]

As a consumer, it's not going to stop me from downloading an app

That is also not the point.

It indeed makes sense for Apple to question why e.g. some run off the mill Sudoku clone app would require access to say a sensitive Health app related API.

Kudos to Apple for doing this: as a consumer, I don’t care if this makes the live of the dev harder.

 

[badepaz89]

You don't think Apple requiring us justifying use of USERDEFAULTS, the most basic of APIs, is insane?

I use UserDefaults to store user preferences, settings, etc. I shouldn't need to justify that.

UserDefaults has several different ”domains”. There is a global domain, and app scoped domain, argument domain, etc. the default use of UserDefaults is to store your keys and values in the app specific domain, but you can expand its use to other domains. in fact, you can insert user default values from the macOS terminal that can then be read by other apps in the system.

so it’s not that they’re worried about YOUR app’s preferences, they’re worried about the system as a whole. That being said, I don’t know how they would know if you’re being ”good” and only messing with your own preferences keys.

 

[badepaz89]

For those wondering about why UserDefaults has a privacy reason, don’t forget:

UserDefaults has several different ”domains”. There is a global domain, an app scoped domain, argument domain, etc. the default use of UserDefaults is to store your keys and values in the app specific domain, but you can expand its use to other domains. in fact, you can insert user default values into the global scope from the macOS terminal that can then be read by other apps in the system.

So I don’t think that they’re worried about YOUR app’s preferences or policing how you manage your app’s data, they’re worried about the system as a whole; because an app could “fingerprint” the device‘s global domain. Apple has long stated not to store sensitive information in user defaults anyway. But if App A fingerprinted your global user defaults store, then sent that to their Spy SDK, and then App B, who also uses Spy SDK, could take its own fingerprint, compare, and realize you’re the same person on the same device. That being said, I don’t know how they would know if you’re being ”good” and only messing with your own preferences keys or not.

 

[MisterSavage]

so it’s not that they’re worried about YOUR app’s preferences, they’re worried about the system as a whole. That being said, I don’t know how they would know if you’re being ”good” and only messing with your own preferences keys.

I store data in UserDefaults via an AppGroup that my widgets can read also. I hope that's still going to be allowed.

 

[badepaz89]

I store data in UserDefaults via an AppGroup that my widgets can read also. I hope that's still going to be allowed.

I think they probably will. That’s a major use case for developers that use extensions. And all of this isn’t as bad on iOS because of the required sandboxing. Sandboxed apps can’t get into other app specific domains. On macOS, though, if the app isn’t sandboxed, then i think it would be fairly easy to read into its defaults.

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. But it’s the ability of a spying app to take a “snapshot” of the entire user defaults database, for apps across the entire system, and then compare that against any other systems that launch an app with their spy SDK to see if it’s the same device.