> In that case, sandboxing could never be introduced. It is quite literally impossible to provide entitlements for any and all functionality under the sun, unle

> In that case, sandboxing could never be introduced. It is quite literally impossible to provide entitlements for any and all functionality under the sun, unless you include the entitlement "allow anything" in the mix. That doesn't follow. Sandboxing privileges present a wide spectrum ranging from providing no entitlements on one end to providing an "allow anything" entitlement on the other. Obviously, as developers, we want as much functionality exposed in a secure way but the unfortunate reality is that Apple either do not have the resources or willingness to do so. > However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are. While that's technically true, an argument can be made that due to the inclusion of the MAS as part of OS X, it's practically required for an app to be on the MAS as that's where a lot of the users are and it's how they get their software. > Can you give examples? Yes, Coda 2.5 [1] was not released on the MAS due to sandboxing issues. There are some radars on openradar [2] referring to other sandboxing issues, too - some of them are reasonable. Obviously, I do not have access to Radar itself otherwise I would have provided more examples. > But that's not even remotely a trivial task. I don't see that as a valid excuse for not providing an API while at the same time rejecting the usage of a temporary entitlement due to lack of said API. It's a given that providing functionality in a sandbox compatible way would not be trivial - the work needs to be done if we want everything to be nice and secure. I'm perfectly aware that the effort required to implement such an API would be considerable and it might not be worth it but that doesn't make it the right approach. And that's why I accept the current situation - it's a compromise between what could be and what Apple have decided to implement at present. > Others would require massive work. Yes and in an ideal world, if we're fully committed to sandboxing, that work would be done. You said: > Apple developed the OS that you're using, so there's hardly a trust issue when talking about running applications from Apple on top of the Apple-developed OS. Sandboxing is not just about trust, it's also about security. Apple's own software not being sandboxed means its vulnerable to exploits, exactly what sandboxing is trying to prevent. If you check Activity Monitor, you will see plenty of Apple and others' apps being non-sandboxed - all of these are potential targets. A system is only as secure as it's weakest link, so if we want a more secure system, we should working towards having more sandbox entitlements. As a side note, the trust side of things is taken care of by code signing. > And implied that this means Apple should allow third-party apps to continue violating rules because the existing experience of using that 3rd-party application somehow trumps everything else. No, the implication is that Apple should be working towards exposing more functionality in a secure, sandbox compatible way. [1] http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/ http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/ [2] http://www.openradar.me/search?query=sandbox http://www.openradar.me/search?query=sandbox