6 ms·

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 c

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.

dlikhten 15y ago
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.
- shareme 15y ago
  android does have it.. each Dlavik VM instance is its own sandbox
- Karunamon 15y ago
  Why is this gettting downvoted? It's good security practice, and the fact that Android needs better sandboxing was a foregone conclusion.
  - bad_user 15y ago
    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.
  - mcherm 15y ago
    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).
- arron61 15y ago
  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.
voxmatt 15y ago
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.
- JonLim 15y ago
  In that situation, would the user be able to enable a persistent permission? Whereby I allow the app to check as often as it needs to?
- pavlov 15y ago
  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?
  - voxmatt 15y ago
    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...
ricg 15y ago
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). >WebProcess(1319) deny file-read-data /Users/me/Library/Application Support/Adobe/AIR/ELS/com.prezi.PreziDesktop/PrivateEncryptedDatak 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.
- raminf 15y ago
  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?
  - ricg 15y ago
    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.
    - raminf 15y ago
      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.
grillz 15y ago
I think the part that bothers me is that this is going into place after many people, including myself, have started buying most apps in the App Store. It is insanely convenient to have all my apps and licenses in one place. New computer? Open the App Store and you're done. If I had known that Apple would move towards a sandbox model that breaks tools I use everyday, like Transmit and Coda (Viewing file tree etc.), I would have kept my license with Panic. What happens when a Transmit bug fix comes out and it no longer appears in the App Store? A whole new purchase most likely. Steve himself had called Macs our "trucks", with iOS device being cars. Not everyone needs a truck, but for those of us who do I am getting a little worried about the direction they're moving.
nikatwork 15y ago
"Yet I simply cannot safely try them out without an exorbitant amount of work." If you are on Windows, Sandboxie is excellent for this. Just right-click the untrusted .exe and select "Run sandboxed". http://www.sandboxie.com/ http://www.sandboxie.com/

dlikhten 15y ago

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.

shareme 15y ago
android does have it.. each Dlavik VM instance is its own sandbox
Karunamon 15y ago
Why is this gettting downvoted? It's good security practice, and the fact that Android needs better sandboxing was a foregone conclusion.
- bad_user 15y ago
  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.
- mcherm 15y ago
  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).
arron61 15y ago
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.

voxmatt 15y ago

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.

JonLim 15y ago
In that situation, would the user be able to enable a persistent permission? Whereby I allow the app to check as often as it needs to?
pavlov 15y ago
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?
- voxmatt 15y ago
  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...

ricg 15y ago

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). >WebProcess(1319) deny file-read-data /Users/me/Library/Application Support/Adobe/AIR/ELS/com.prezi.PreziDesktop/PrivateEncryptedDatak 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.

raminf 15y ago
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?
- ricg 15y ago
  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.
  - raminf 15y ago
    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.

grillz 15y ago

I think the part that bothers me is that this is going into place after many people, including myself, have started buying most apps in the App Store. It is insanely convenient to have all my apps and licenses in one place. New computer? Open the App Store and you're done. If I had known that Apple would move towards a sandbox model that breaks tools I use everyday, like Transmit and Coda (Viewing file tree etc.), I would have kept my license with Panic. What happens when a Transmit bug fix comes out and it no longer appears in the App Store? A whole new purchase most likely. Steve himself had called Macs our "trucks", with iOS device being cars. Not everyone needs a truck, but for those of us who do I am getting a little worried about the direction they're moving.

nikatwork 15y ago

"Yet I simply cannot safely try them out without an exorbitant amount of work." If you are on Windows, Sandboxie is excellent for this. Just right-click the untrusted .exe and select "Run sandboxed". http://www.sandboxie.com/ http://www.sandboxie.com/