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.
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.
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.
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...
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.
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.
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).