So while Apple is motivated to catch this stuff to an extent, they aren't that motivated, and they may well be perfectly happy with the current level of sophistication.
toucharcade.com/2015/09/23/bioshock-removal-2k-support-response/
http://stackoverflow.com/a/27686125
The reason they don't just do this for every API is due to the sandbox design, which makes this cumbersome.
The trend took big steps in iOS 6, when Apple created a mechanism for remote views, and moved things like sending SMS and email out of process, in addition to the mechanism for determining what process gets what touches (backboardd).
As you mentioned, MobileGestalt was another step in this direction, when Apple blocked access to the MAC address and UDID.
iOS was not originally engineered with this focus of security and sandboxing in mind. For example, CVE-2015-5880 (accessing contents of screen from anywhere prior to iOS 9) existed because the screen framebuffer was needed for QuartzCore to function, and Apple didn't take the time to re-engineer how things work.
The number of things you can still do from the sandbox is mind boggling, and Apple is aware of it, they just don't have the time to re-engineer everything.
There's still no clear reason why Apple choose to enforce the security via app reviews, rather than the system call returning 'permission denied' to apps without the right security level.
But it is not a security thing at all.
This way your code and most legit code that is not trying thousands of URLs works, but apps are trying to do this fail but don't crash.
Apple is probably in the unique position to actually implement such a system successfully, controlling the hardware, os, and even language choice.
Or they could continue with the current sandboxing system where security- and privacy-critical functionality is performed out of process, and plug the remaining leaks, of which there aren't that many.
open() would be a much simpler syscall if it didn't bother to enforce access controls. The code would be a lot easier to maintain too...
I believe the current sandbox design makes it more complex to promote system interfaces to require individual access control. It doesn't provide the fine-grained access, so more work is needed to separate code with the granularity that sandbox policies can control it.
This does happen over time (e.g. UDID in iOS 8).
I think we're talking at cross-purposes. My original question was why Apple don't restrict this restricted information. It appears we both agree that putting it behind an access control (like a syscall) would prevent this.
Because Apple wants to use this information, but they don't want anybody else to use this information.
If Apple requires security permission to get at the information, then they hose themselves as well.
e.g. the advertising ID could be stored in a file with appropriate permissions. All the API needs to do is open the file and read it out.
If there are any security implications to making a private API call then this implies that Apple's sandboxing system is broken. If so then the solution is to fix the sandbox. Better detection of private API usage might be good for them, but is neither necessary nor sufficient nor particularly useful for security.