I think part of the picture people are missing through the haze of quality information currently coming out of Apple regarding the SDK is exactly how Apple apple will bless some apps to run in the background and some apps not to run. It isn’t from having the kernel look at the name of the application.
Most likely it will be done using the same permission attributes that are built into OSX Leopard right now. We already know that code signing and sanboxing are part of the process. The other part most people don’t know that ties in with this is the fine grained control of the Trusted BSD Mandatory Access Control. When an app is signed and a sandbox defined for it in the form of a profile, that profile can state what the application is allowed and not allowed to perform.
Examples:
“This application reads and writes from the network”
“This application needs to be able to open a low port socket”
“This application should not be allowed to create any files”
The idea seed for this is to lock down an application so that if it is compromised it has a limited functionality and can’t be used to further an attack. This functionality exists right now in every shipping copy of Leopard. Apple is likely to leverage it for fine grain control on other versions of OSX such as the iPhone, where we know that every application has to be signed.
Possible iPhone Examples:
“This application never needs to communicate over the WIFI network”
“This application needs to be left running in the background”
“This application is allowed to send 15 packets up to 500 bytes per second through the EDGE network, but no more than 2000 bytes per second”
My best guess is that when you submit your application to the store you will submit it with the sandbox profile that it needs to run. Applications that need some non standard feature such as running in the background, accessing iTunes audio files, or accessing another applications files will have to add that key to their sandbox profile.
I would also guess that if you do add one of those features it will involved a more detailed review by Apple before being approved.
The point of all this is that the default set will meet the need of the vast majority of applications. Screaming that the exception proves that the default rules are absurd isn’t going to convince Apple to change the default. Cooperation will be gained by explaining why your particular application needs more access, because the sandbox allows the rules to be set on a per-application basis.
