Not really. If there are apps using these disallowed APIs, why would Apple care about breaking them if they removed access? In every case where an app is discovered using the APIs, they remove them from the app store. App compatibility is not the issue.

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.

Compatibility is absolutely why they try to catch these things in review. Apple doesn't want a situation where iOS 10 results in 90% of the top apps breaking, because users will blame Apple and their reputation will suffer.

But it is not a security thing at all.

Either way, why not just deny access? It guarantees that apps won't break in this way, removes some pain from the process of approving apps (they don't need to check for this anymore), and improves privacy / security as a side effect!

They do deny access, and they usually seem to try to do it in a backwards-compatible way. For example, if you try to get the list of installed apps by brute-forcing URL schemas, they return "no more entries" after 50 calls now.

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.

Deny access how, exactly? Strictly enforcing privilege separation within the same process is basically impossible without running lesser-privileged code in a VM or something basically equivalent.

Isn't this what entitlements do? I honestly have no idea how they work - perhaps blog material? :)

Entitlements regulate what out-of-process facilities you're allowed to access. (For example, entitlements let you access certain parts of the filesystem, or the network, or access location services.) Private APIs are regular boring in-process classes, methods, and functions which just aren't documented by Apple and aren't part of their public interface. You call them in the same way as you do a public API: by jumping to the function, or invoking objc_msgSend to send a message to an object, all within your process.

Sure, if Apple banned Objective-C/C/C++ and assembly code (never mind that most games are written in C++), set up a new system where all developers had to upload Swift IR, removed all unsafe APIs (at a sometimes very high performance cost), and audited all the rest of the gazillions of APIs for memory unsafety in the face of deliberate misuse, then they could implement an in-process object capability system that had only a few thousand vulnerabilities, similar to WebKit.

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.

Because enforcing restrictions in code makes the kernel and runtime more complex.

But that's its job!

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

It is not the runtime's job. It is the kernel's job, but the whole point of private API is that they're within the same process and don't require a syscall to invoke. Calls which require kernel involvement that you're not supposed to be able to call already have access control mechanisms so you can't call them.

You're both right. It's the kernel's job to ultimately enforce this policy, and calling private APIs should only be a compatibility problem, not a security risk.

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

In what way is the sandbox not fine grained? I thought the whole idea with entitlements was that access to individual facilities could be controlled separately.

Well yes, I meant it's the kernel's job. If the information is already in-process, then there's no access control at all and an app could just read it directly, rather than calling a private API.

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.

Right. It's confusing in a discussion about private API in general, because private API is pretty much by definition calls with no access control which are merely undocumented. Thus saying that Apple should be more clever about prohibiting private API calls is weird. But if it's just one particular call that needs better enforcement, yeah, they should do that. And it will involve promoting it beyond "private API."

> My original question was why Apple don't restrict this restricted information.

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'm not sure I understand your argument. Because there is already some complexity in the kernel, we should be fine with adding more complexity to it?

It could use many of the existing access control methods already in the kernel. No extra kernel complexity required.

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 believe now that apps can get the level of info shown in the article it will become a user privacy issue--making it quite closely linked to security.

If so, then Apple will add restrictions to which apps are able to make these calls, by moving them out of process and adding actual security checks. That's how everything that's actually security-critical (calls that manipulate other processes, filesystem access, hardware access, etc.) already works.

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.

I agree that enforcement is the best way to go here. Hopefully they will improve the granularity of sandbox control to make detecting private APIs purely a compatibility issue.