In general, this type of sandbox is a Good Thing. I would love to live in a world where the default environment for any program is a very limited sandbox that can only interact with the outside world via standardized UI elements. That is, outside a data store specific to the application, it can only access files via the standard dialogs, and so forth.
The potential for malware distribution would be significantly reduced in such a world, because yes, there will always be stupid users, but you cannot blame all the stupidity on the user.
Even I as a power user would like to try out little programs that I find on the internet - and that includes small games and screensavers, which are cliche carriers of malware. Yet I simply cannot safely try them out without an exorbitant amount of work. Having a proper sandbox environment as de facto standard outside of web browsers would be awesome.
That said, it absolutely sucks that Apple combines an idea that is a Good Thing in principle with idiotic policies - if it is indeed true what the article claims.
I just watched the Apple developer videos about App Sandboxing and have to agree that it in most cases it's a good thing.
With that new enthusiasm I went ahead and tried the AppSandboxQuickStart code sample that loads a webpage in a WebKit WebView.
Enabled sandboxing, app failed because of missing network.client entitlement. Enabled that as the tutorial said to get it to work: app still fails.
Turns out that the WebView, or rather the Flash plugin is trying to load the AIR apps that are installed (why, I have no clue, I was loading apple.com).
The app didn't start at all. Only hint were errors in the Console. As a developer I'm afraid that those "perceived crashes", that's what they will look like to users, will become a common theme.
This brings up an important issue. If an app uses an embedded webview and the user can navigate down links would the developer have to check off every entitlement that the webview might in the future need to access?
Navigating links shouldn't be an issue assuming that the app hosting the web view is allowed to connect to the network.
But how about plugins loaded by the web view? I assume that's what's happening in my case. The web view is loading the Flash plugin, which in turn tries to access the file system.
That's not allowed, because the plugin inherits the entitlements of the parent app. The Flash plugin really can't believe that access to it's Library folder doesn't work so it tries and tries and tries sending the main thread into an endless loop blocking the complete app.
That's actually what I meant by navigating links. Each page would load fresh content that might have plugins that require services not authorized in the main app.
For example, any typical RSS reader, alternative email clients, specialized browsers, or any dev tool that shows page previews using a webview. These all have to max out the entitlements so they don't break down the line.
It seems like it would be much more useful to make entitlements be a dynamic system instead, so apps can request extra privileges at runtime and asking the user to confirm instead of statically baking it into the app envelope. Same goes for the iPhone.
On what the article claims: my understanding is that the sandbox restricts all non-user initiated actions. That is, if a user initiates it by clicking, dragging, OK-ing, etc., then all the old system interactions are still allowed. If you want to take a screenshot, of course you can so long as the user hits a keyboard combo to do it.
Where it's a real hurdle, however, is for those programs who have to monitor and interact with files outside its sandbox without user interaction. Take fantastical, it has to check the user's iCal calendar (or iCloud, or whereever that file is these days) persistently. If it can only do that when the user tells it to, it loses a lot of its appeal and functionality.
That being said, I think these rules actually make a lot of sense on the balance. But it would be nice to allow the user to authorize complete access in some sort of double-verified-super-secure-foolproof way.
There's APIs to interact with the calendar store; no calendar application should ever be accessing the calendar files directly—so apps like Fantastical are probably already OK.
I haven't deeply examined the sandboxing rules and capabilities, but I think that this could improve application interoperability because they will need to work through APIs directly rather than through filesystem backdoors.
On what the article claims: my understanding is that the sandbox restricts all non-user initiated actions. That is, if a user initiates it by clicking, dragging, OK-ing, etc., then all the old system interactions are still allowed. If you want to take a screenshot, of course you can so long as the user hits a keyboard combo to do it.
How would that work? How does the system determine that the user intended for this particular action to take screenshots of other applications' windows?
I'm certainly no expert here, so take my thoughts with a large, large block of salt. By way of example, I do know that the typical action of dragging a file on to the application's icon in the dock will allow an app to open that file, just as would the open file dialog. Not allowing this would be, obviously, unworkable. Similarly, I believe (although I don't know) that a key-combo associated with that app (as is usually used to invoke screenshots) would signal that the user is acting on the application and, hence, authorizing the action. Although, I'm not sure screenshots would be inhibited by the sandboxing to begin with...
Sandboxing is great since less and less control is in the hands of the app. I am sure apple will keep rolling out features expanding sandboxing, this is just the default impl. This also means that basically it will be harder and harder for apps to be malware in an already hostile system.
I wish android had this. Android needs this much more than iOS.
Android does have sandboxing and its much better in than iOS. Each app runs in its own VM instance and requests for permissions. Additionally each app can also call other apps via intents. This allows for great sandboxing and reutilization.
Because all Android apps are sandboxed and have to request explicit permissions for connecting to the Internet, reading or writing the user's contacts, accessing the user's pictures and so on and so forth.
What is foregone about that conclusion? My impression is that Android's sandboxing is quite nice, thank you. In fact, I think the biggest failing is that there need to be stronger ways to ESCAPE the sandbox (eg: to build a virus-checker or a backup program).
The potential for malware distribution would be significantly reduced in such a world, because yes, there will always be stupid users, but you cannot blame all the stupidity on the user.
Even I as a power user would like to try out little programs that I find on the internet - and that includes small games and screensavers, which are cliche carriers of malware. Yet I simply cannot safely try them out without an exorbitant amount of work. Having a proper sandbox environment as de facto standard outside of web browsers would be awesome.
That said, it absolutely sucks that Apple combines an idea that is a Good Thing in principle with idiotic policies - if it is indeed true what the article claims.