7 ms·

Mac App Store apps must implement sandboxing as of March 2012

78 points by kinetik 15y ago

teilo 15y ago
Time to settle down, people. This is not the bad news you think it is. Please take the time to read what exactly is entailed in Sandboxing a Mac App before you presume this is a restriction on your freedom. You can start here: https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html https://developer.apple.com/library/mac/#documentation/Secur... The vast majority of apps on the App store can be sandboxed without effecting their functionality in any way. Sandboxing on OS X is not like Sandboxing on iOS. You can still access all your files. Your app just can't do it without asking. You can still send Apple events to other apps - you just can't send them to whatever apps you feel like. They must be defined, and permission granted via entitlements. True, you cannot access another applications preferences. However, an application can present an API that other applications can access. In other words, this change forces apps to be designed much more securely. It reminds me of the Android permissions model.
- kennywinker 15y ago
  "Sending Apple events to arbitrary apps With App Sandbox, you can receive Apple events and respond to Apple events, but you cannot send Apple events to arbitrary apps." "By using a temporary exception entitlement, you can enable the sending of Apple events to a list of specific apps that you specify..." The word at WWDC was temporary exceptions are temporary and just there to ease the transition to sandboxing. I.e. they will be REVOKED at some point in the future.
  - deleted 15y ago
    [deleted]
- natesm 15y ago
  > You can still access all your files. Your app just can't do it without asking. Sort of. You can't access files across restarts of your app right now. So something that needs to maintain a database of files in the filesystem (say a music library) will be able to access them when the user adds the files, but then will stop working after you restart. The only way around this is a "temporary" exception - they absolutely need a permanent solution for this situation.
- DrJokepu 15y ago
  I'm a 100% behind the idea of sandboxing, one of my apps in the Mac App Store already comes with sandboxing enabled even though it's not required yet, but I feel like the current way to do it can be very limiting. Some perfectly legit applications would be inherently broken with no easy way to fix them. Heck, even Xcode would be broken as you only open the project file directly, how could you edit the source files in the project individually without opening them one by one? The only way I can think of is having the whole project, including the source files in a single bundle but that would break everything currently out there.
LeafStorm 15y ago
Apparently, I am not authorized to view any information on sandboxing besides "[a]s of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing" and that it "is a great way to protect systems and users by limiting the resources apps can access and making it more difficult for malicious software to compromise users' systems." Apple's developer relations with anyone who doesn't want to fork over $100 just to read the docs are really poor.
- alastairpat 15y ago
  http://developer.apple.com/library/mac/#documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html#//apple_ref/doc/uid/TP40010543-CH2-SW6 http://developer.apple.com/library/mac/#documentation/Genera... provides pretty much everything on sandboxing from a non-architectural, developer point of view.
- biot 15y ago
  It's free to register as an Apple developer and your ID will then work: http://developer.apple.com/programs/register/ http://developer.apple.com/programs/register/ Though to your point, I'm not sure why Apple requires someone to login just to read the docs.
  - fleitz 15y ago
    No it isn't. I'm an iOS dev but not Mac and I can't read the docs. You have to pay to read the docs and find out what sand boxing entails. But I suppose if you're not distributing through the App Store why would you even care?
    - biot 15y ago
      You're right. I should have verified that before posting.
    - jensnockert 15y ago
      I'm not a registered dev, and opening the link works fine.
ewoodrich 15y ago
I wish I could find better documentation for this. I'm curious how their sandboxing implementation will work. I guess my "membership level" can't see the tech docs.
- davidcann 15y ago
  Did you even look? It's publicly available: https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html https://developer.apple.com/library/mac/#documentation/Secur...
  - ewoodrich 15y ago
    I did, but only on the landing page of the OP's link, which was forbidden based on my dev membership. Thanks, that's what I was looking for.
  - kstenerud 15y ago
    Click top link, follow the "App Sandbox Page" link from Apple's page (https://developer.apple.com/devcenter/mac/app-sandbox/ https://developer.apple.com/devcenter/mac/app-sandbox/), get redirected to https://developer.apple.com/devcenter/ios/unauthorized/ https://developer.apple.com/devcenter/ios/unauthorized/
kennywinker 15y ago
It's time to write the eulogy for application automation and inter-application communication on the Mac. AppleScript (beast that it is) was innovative when it was created, and still has not been replaced. Automator is built on AppleEvents, and with sandboxing will come a sharp decline in the number of applications that can receive AppleEvents and the extinction of apps that send them.
- sipefree 15y ago
  Not at all! Sandboxing brings with it XPC, which is an IPC framework for doing very fast and awesome message passing. It's got some great features for separation of privileges. For instance, you might have an XPC sandboxed process for, say, rendering a H.264 video to a buffer. That process never gets access to the filesystem, the graphics card, or anything apart from the strip of memory that contains the file, and the buffer it has to write its pixels to. Then you can use this to render a H.264 video in your application, and if a buffer overflow is found that could lead to a video containing shellcode to be executed, you have no fear that bad things can happen to the filesystem or users' stuff. If I'm not mistaken, I'm pretty sure XPC is how they implemented the crazy feature where you open a QuickLook window on an image or something in the Finder, and if you it the Open with Preview(.app) button, the Finder's QuickLook window turns into a Preview window.
  - kennywinker 15y ago
    I tried very hard at WWDC this year to get a comment on this. Nobody would clarify if XPC could be used in the way Apple Events are... All the documentation I could find were about splitting your single app into multiple processes, and using XPC to communicate between them. Does XPC provide a way to query the interface of an app you don't own? Can I ask for an XPC "dictionary" a la AppleScript?
  - Groxx 15y ago
    /me tries the quicklook -> preview thing That's kinda cool... never tried that before. But yeah. Sandboxing does not at all imply not-scriptable. It tends to imply breakage with older systems of scripting, but that's about all, and only until wrappers are made.
elHeffe 15y ago
An I wrong in thinking this sounds like app armor for Linux? A good thing if implemented properly.
- wes-exp 15y ago
  Seems so: "In Mac OS X v10.7 and later, placing your application in an app sandbox is a great way to minimize the potential damage caused by successful exploits" http://developer.apple.com/library/mac/#documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html#//apple_ref/doc/uid/TP40010543-CH2-SW6 http://developer.apple.com/library/mac/#documentation/Genera...
  - droithomme 15y ago
    Putting my applications in a sandbox doesn't really prevent my application from doing exploits because my applications are not malware to begin with. Well behaved applications that are not malware are already not malware. The real issue is what about malware, will this stop them. Well, obviously malware authors are not going to put their applications in a sandbox. They will continue releasing them as before. And so, obviously, this system won't work unless all software is sandboxed, not just the normal innocuous non-malware that didn't need to be in the first place. It's the same principal where you can't stop gun crime by banning only law abiding citizens from having guns. You have to completely eliminate all guns or it doesn't work. All or nothing. To me, this tell me where this is headed. Obviously total sandboxing of everything has to be done for this to be effective at all. And with total sandboxing of everything we no longer have a desktop computer that can be used for general productivity, we have an information appliance that provides a nice consumer experience.
    - nknight 15y ago
      Any application that interacts with untrusted data is a potential vector for malware. Ignoring that is the worst kind of arrogance a developer can display.
    - planb 15y ago
      Putting your applications in a sandbox prevents you application from being exploited. A bug in you chat software can't be used to get access to your private files anymore. It also prevents that chat software from installing malware on you mac.
extension 15y ago
This is the only sensible security model for third party software in the world of today. Actually, this is the only sensible security model in the world of ten years ago. Windows has been endlessly criticized for not sandboxing apps. It's gotta be done and Apple is doing the transition the way that has always worked for them: fast and ruthless.
cageface 15y ago
The real question is this: Is Apple going to eventually make the app store the only way of installing apps on a Mac? I think this is likely and if so is going to be the end of the line for me as an Apple customer.
- lukifer 15y ago
  I draw the line here too. I accept the control tradeoff on iOS because I view them as appliances, not computers, and there are upsides to the curated experience. But if I can't fully control my primary computing device, I'm out. (I'd be okay with the machine shipping in "grandma mode", so long as there's an official way to disable it completely.)
  - jayfuerstenberg 15y ago
    Your opinion is valid. There is one way to disable it as these rules still only apply to apps sold via the MAS. Anybody can release software outside of it and just forget about Apple's rules.
    - pyre 15y ago
      I think the fear is that Apple will decide that the MacAppStore is the only way to install software on OSX.
      - droithomme 15y ago
        Not just a fear, but a reasonable conclusion. Obviously sandboxing won't be effective for third party software unless 100% of all third party software is enforced to use sandboxing and won't run without it. It's pretty much an inevitable conclusion that that is coming because the system doesn't work unless you go all or nothing.
  - pyre 15y ago
    Wait until you void your AppleCare if you disable 'grandma mode.' Or until any third party decides that they will only support Macs in 'grandma mode.'
lukifer 15y ago
Though there have been many disturbing trends in the evolution of the App Store(s), this one is actually quite mild, if not welcome. Honestly, it's always unsettled me a little that any software can just start arbitrarily scribbling bits to the hard drive. (The system folder is protected, but my data isn't.) The concern is only a little about malware, and mostly about buggy code. All the sandbox requires is that apps only have access to files when the user initiates the action. And unlike most App Store policies, you're also allowed to request specific exceptions as needed by your app, and I'm expecting they'll actually be reasonable about it. [1] This creates more work for developers, but I think overall these changes will help keep users' data safe. As also mentioned in this thread, these changes have big implications for inter-app communication. But sandboxing doesn't take the capability away; it just requires devs to do more work, again in the name of user security. There will be a big usability hit on apps which don't see regular updates, and apps whose developers neglect to update this aspect of their apps. But the same capabilities will exist, and eventually most apps will catch up to the new norms. [1] Although if Apple starts making stupid rejections and standing by them, then I take it all back.
- benatkin 15y ago
  > Although if Apple starts making stupid rejections and standing by them, then I take it all back. That's a given.
  - ugh 15y ago
    Apple typically didn’t stand by stupid rejections. They made them, didn’t stand by them.
    - benatkin 15y ago
      We shouldn't have to embarrass a company before we get access to a useful application.
      - ugh 15y ago
        That’s one valid way of seeing it. I don’t share it. But a nice derail you did there.
dgallagher 15y ago
This SO question raises an interesting issue: http://stackoverflow.com/questions/7419912/how-will-lions-new-security-model-affect-things-like-python http://stackoverflow.com/questions/7419912/how-will-lions-ne... What if your app uses Python to perform IO? What if you wrote your code using PyObjC? Is there any way to sandbox that, or are you out of the Mac App Store for good?
- makecheck 15y ago
  That's a very good question. I use Python a lot and I combine it with C++ and Objective-C to build a very complex application. While it looks like a regular app and behaves like one, underneath it starts out as a Python interpreter that runs a script and loads compiled libraries. It's a model that works extremely well and I hope it continues to "just work". Sure, it's unconventional and I'd understand if Apple didn't expect most things to work this way, but I hope they don't just break it completely for me.
  - jensnockert 15y ago
    It should work just like for Objective-C applications, it isn't implemented in Cocoa but at a kernel level. The sandbox has been around since Tiger (or at least Leopard) and with a proper configuration it works fine with Ruby/Python.
mattgreenrocks 15y ago
I thought this was supposed to be done by the end of this month? I'm excited, even if only for the prospect that anything I install from the App Store can't lodge itself everywhere in my system.
Too 15y ago
Will this have any effect in practice or will it just be the same as the different trust levels in .NET? The functionality for sandboxing is built in it's just that nobody uses it or knows how to test or enforce it. (with the exception of sysadmins). In any case i welcome all sandboxing, this is even something i would consider switching from windows because of, given that it actually works out good. Let's take an example from yesterday, i want a simple pdf-merge program. As it is now i have to spend 20 minutes researching a program on forums and other sites before i even install it to see if it's safe and everything. Compared to just installing and see if the result works. This is also why web apps are so popular, you can try hundreds of them with 0 risk for your other data.
ghshephard 15y ago
If this means that I can be reasonably certain an application that I purchase from the App Store will be prevented from screwing up parts of my system without my permission - then, as a user, I'm all for it. One day, in the future, apps will run in a chrooted/isolated virtual environment, with some actual guarantees that they are _incapable_ of touching anything but their sandbox, regardless of developer intent. Until that day though, this seems like a reasonable evolution to that world. Perhaps it speaks to my paranoia - but I've always been unnerved by the concept that an application can basically do anything to the OS that I can from from finder/shell. I have to believe that this sandboxing will reduce the potential for malware doing damage to the OS. The question I have is - will I be able to give applications like "Backblaze" the ability to read (but not write) from my entire set of user folders? If so, then that's the best possible case. Puts the power to control damage that an application can do in my hands.
- jbrennan 15y ago
  > The question I have is - will I be able to give applications like "Backblaze" the ability to read (but not write) from my entire set of user folders? Sure. This sand boxing only applies to App Store apps (for now at least). I imagine so long as you can install non-Appr Store apps, you can also have non-sandboxed apps.
ricg 15y ago
The end of utility apps? What makes (used to make?) the Mac such a great platform is that apps integrate seamlessly. Making them work together in new ways that were not anticipated by the developer is incredibly powerful (Unix philosophy anyone?). Sure, sandboxing will allow your app to talk to another app, but only if you request permission beforehand. But what if the app my app wants to intact with has not been written yet? What about application launchers like QuickSilver, Launchbar, and all the hundreds of other utility apps? Only allowing sandboxed apps will change the nature of apps that we will find in the app store from "utility" shifting to "just-do-one-thing". And about the question about whether the Mac App Store will become the only way to install apps on the Mac: the question is not if, but when.
- natesm 15y ago
  This has already sort of happened. Apps are forced to have some sort of permanent presence now. In the past, you could be running many of these and still have a clean menu bar. Now, you have to have an icon for Growl, an icon for Quicksilver...
  - ricg 15y ago
    Sure, but that's not restricting functionality. Sandboxing on the other hand will simply mean that those apps won't get into the App Store in the first place.
    - natesm 15y ago
      Well, it restricts my ability to have a clean menu bar. Honestly, it's the reason I haven't installed Growl from the MAS.
pavlov 15y ago
I've been making Mac apps for nearly a decade now. I wrote a summary and opinion piece on this: http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox-makes-me-sad/ http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox... (HN discussion link: http://news.ycombinator.com/item?id=3191021 http://news.ycombinator.com/item?id=3191021)
startupcomment 15y ago
Now if only they can implement something like this for Safari so that individual browser pages are sandboxed from each other, as is the case in Chrome.

78 points by kinetik 15y ago

teilo 15y ago

Time to settle down, people. This is not the bad news you think it is. Please take the time to read what exactly is entailed in Sandboxing a Mac App before you presume this is a restriction on your freedom. You can start here: https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html https://developer.apple.com/library/mac/#documentation/Secur... The vast majority of apps on the App store can be sandboxed without effecting their functionality in any way. Sandboxing on OS X is not like Sandboxing on iOS. You can still access all your files. Your app just can't do it without asking. You can still send Apple events to other apps - you just can't send them to whatever apps you feel like. They must be defined, and permission granted via entitlements. True, you cannot access another applications preferences. However, an application can present an API that other applications can access. In other words, this change forces apps to be designed much more securely. It reminds me of the Android permissions model.

kennywinker 15y ago
"Sending Apple events to arbitrary apps With App Sandbox, you can receive Apple events and respond to Apple events, but you cannot send Apple events to arbitrary apps." "By using a temporary exception entitlement, you can enable the sending of Apple events to a list of specific apps that you specify..." The word at WWDC was temporary exceptions are temporary and just there to ease the transition to sandboxing. I.e. they will be REVOKED at some point in the future.
- deleted 15y ago
  [deleted]
natesm 15y ago
> You can still access all your files. Your app just can't do it without asking. Sort of. You can't access files across restarts of your app right now. So something that needs to maintain a database of files in the filesystem (say a music library) will be able to access them when the user adds the files, but then will stop working after you restart. The only way around this is a "temporary" exception - they absolutely need a permanent solution for this situation.
DrJokepu 15y ago
I'm a 100% behind the idea of sandboxing, one of my apps in the Mac App Store already comes with sandboxing enabled even though it's not required yet, but I feel like the current way to do it can be very limiting. Some perfectly legit applications would be inherently broken with no easy way to fix them. Heck, even Xcode would be broken as you only open the project file directly, how could you edit the source files in the project individually without opening them one by one? The only way I can think of is having the whole project, including the source files in a single bundle but that would break everything currently out there.

LeafStorm 15y ago

Apparently, I am not authorized to view any information on sandboxing besides "[a]s of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing" and that it "is a great way to protect systems and users by limiting the resources apps can access and making it more difficult for malicious software to compromise users' systems." Apple's developer relations with anyone who doesn't want to fork over $100 just to read the docs are really poor.

alastairpat 15y ago
http://developer.apple.com/library/mac/#documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html#//apple_ref/doc/uid/TP40010543-CH2-SW6 http://developer.apple.com/library/mac/#documentation/Genera... provides pretty much everything on sandboxing from a non-architectural, developer point of view.
biot 15y ago
It's free to register as an Apple developer and your ID will then work: http://developer.apple.com/programs/register/ http://developer.apple.com/programs/register/ Though to your point, I'm not sure why Apple requires someone to login just to read the docs.
- fleitz 15y ago
  No it isn't. I'm an iOS dev but not Mac and I can't read the docs. You have to pay to read the docs and find out what sand boxing entails. But I suppose if you're not distributing through the App Store why would you even care?
  - biot 15y ago
    You're right. I should have verified that before posting.
  - jensnockert 15y ago
    I'm not a registered dev, and opening the link works fine.

ewoodrich 15y ago

I wish I could find better documentation for this. I'm curious how their sandboxing implementation will work. I guess my "membership level" can't see the tech docs.

davidcann 15y ago
Did you even look? It's publicly available: https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html https://developer.apple.com/library/mac/#documentation/Secur...
- ewoodrich 15y ago
  I did, but only on the landing page of the OP's link, which was forbidden based on my dev membership. Thanks, that's what I was looking for.
- kstenerud 15y ago
  Click top link, follow the "App Sandbox Page" link from Apple's page (https://developer.apple.com/devcenter/mac/app-sandbox/ https://developer.apple.com/devcenter/mac/app-sandbox/), get redirected to https://developer.apple.com/devcenter/ios/unauthorized/ https://developer.apple.com/devcenter/ios/unauthorized/

kennywinker 15y ago

It's time to write the eulogy for application automation and inter-application communication on the Mac. AppleScript (beast that it is) was innovative when it was created, and still has not been replaced. Automator is built on AppleEvents, and with sandboxing will come a sharp decline in the number of applications that can receive AppleEvents and the extinction of apps that send them.

sipefree 15y ago
Not at all! Sandboxing brings with it XPC, which is an IPC framework for doing very fast and awesome message passing. It's got some great features for separation of privileges. For instance, you might have an XPC sandboxed process for, say, rendering a H.264 video to a buffer. That process never gets access to the filesystem, the graphics card, or anything apart from the strip of memory that contains the file, and the buffer it has to write its pixels to. Then you can use this to render a H.264 video in your application, and if a buffer overflow is found that could lead to a video containing shellcode to be executed, you have no fear that bad things can happen to the filesystem or users' stuff. If I'm not mistaken, I'm pretty sure XPC is how they implemented the crazy feature where you open a QuickLook window on an image or something in the Finder, and if you it the Open with Preview(.app) button, the Finder's QuickLook window turns into a Preview window.
- kennywinker 15y ago
  I tried very hard at WWDC this year to get a comment on this. Nobody would clarify if XPC could be used in the way Apple Events are... All the documentation I could find were about splitting your single app into multiple processes, and using XPC to communicate between them. Does XPC provide a way to query the interface of an app you don't own? Can I ask for an XPC "dictionary" a la AppleScript?
- Groxx 15y ago
  /me tries the quicklook -> preview thing That's kinda cool... never tried that before. But yeah. Sandboxing does not at all imply not-scriptable. It tends to imply breakage with older systems of scripting, but that's about all, and only until wrappers are made.

elHeffe 15y ago

An I wrong in thinking this sounds like app armor for Linux? A good thing if implemented properly.

wes-exp 15y ago
Seems so: "In Mac OS X v10.7 and later, placing your application in an app sandbox is a great way to minimize the potential damage caused by successful exploits" http://developer.apple.com/library/mac/#documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html#//apple_ref/doc/uid/TP40010543-CH2-SW6 http://developer.apple.com/library/mac/#documentation/Genera...
- droithomme 15y ago
  Putting my applications in a sandbox doesn't really prevent my application from doing exploits because my applications are not malware to begin with. Well behaved applications that are not malware are already not malware. The real issue is what about malware, will this stop them. Well, obviously malware authors are not going to put their applications in a sandbox. They will continue releasing them as before. And so, obviously, this system won't work unless all software is sandboxed, not just the normal innocuous non-malware that didn't need to be in the first place. It's the same principal where you can't stop gun crime by banning only law abiding citizens from having guns. You have to completely eliminate all guns or it doesn't work. All or nothing. To me, this tell me where this is headed. Obviously total sandboxing of everything has to be done for this to be effective at all. And with total sandboxing of everything we no longer have a desktop computer that can be used for general productivity, we have an information appliance that provides a nice consumer experience.
  - nknight 15y ago
    Any application that interacts with untrusted data is a potential vector for malware. Ignoring that is the worst kind of arrogance a developer can display.
  - planb 15y ago
    Putting your applications in a sandbox prevents you application from being exploited. A bug in you chat software can't be used to get access to your private files anymore. It also prevents that chat software from installing malware on you mac.

extension 15y ago

This is the only sensible security model for third party software in the world of today. Actually, this is the only sensible security model in the world of ten years ago. Windows has been endlessly criticized for not sandboxing apps. It's gotta be done and Apple is doing the transition the way that has always worked for them: fast and ruthless.

cageface 15y ago

The real question is this: Is Apple going to eventually make the app store the only way of installing apps on a Mac? I think this is likely and if so is going to be the end of the line for me as an Apple customer.

lukifer 15y ago
I draw the line here too. I accept the control tradeoff on iOS because I view them as appliances, not computers, and there are upsides to the curated experience. But if I can't fully control my primary computing device, I'm out. (I'd be okay with the machine shipping in "grandma mode", so long as there's an official way to disable it completely.)
- jayfuerstenberg 15y ago
  Your opinion is valid. There is one way to disable it as these rules still only apply to apps sold via the MAS. Anybody can release software outside of it and just forget about Apple's rules.
  - pyre 15y ago
    I think the fear is that Apple will decide that the MacAppStore is the only way to install software on OSX.
    - droithomme 15y ago
      Not just a fear, but a reasonable conclusion. Obviously sandboxing won't be effective for third party software unless 100% of all third party software is enforced to use sandboxing and won't run without it. It's pretty much an inevitable conclusion that that is coming because the system doesn't work unless you go all or nothing.
- pyre 15y ago
  Wait until you void your AppleCare if you disable 'grandma mode.' Or until any third party decides that they will only support Macs in 'grandma mode.'

lukifer 15y ago

Though there have been many disturbing trends in the evolution of the App Store(s), this one is actually quite mild, if not welcome. Honestly, it's always unsettled me a little that any software can just start arbitrarily scribbling bits to the hard drive. (The system folder is protected, but my data isn't.) The concern is only a little about malware, and mostly about buggy code. All the sandbox requires is that apps only have access to files when the user initiates the action. And unlike most App Store policies, you're also allowed to request specific exceptions as needed by your app, and I'm expecting they'll actually be reasonable about it. [1] This creates more work for developers, but I think overall these changes will help keep users' data safe. As also mentioned in this thread, these changes have big implications for inter-app communication. But sandboxing doesn't take the capability away; it just requires devs to do more work, again in the name of user security. There will be a big usability hit on apps which don't see regular updates, and apps whose developers neglect to update this aspect of their apps. But the same capabilities will exist, and eventually most apps will catch up to the new norms. [1] Although if Apple starts making stupid rejections and standing by them, then I take it all back.

benatkin 15y ago
> Although if Apple starts making stupid rejections and standing by them, then I take it all back. That's a given.
- ugh 15y ago
  Apple typically didn’t stand by stupid rejections. They made them, didn’t stand by them.
  - benatkin 15y ago
    We shouldn't have to embarrass a company before we get access to a useful application.
    - ugh 15y ago
      That’s one valid way of seeing it. I don’t share it. But a nice derail you did there.

dgallagher 15y ago

This SO question raises an interesting issue: http://stackoverflow.com/questions/7419912/how-will-lions-new-security-model-affect-things-like-python http://stackoverflow.com/questions/7419912/how-will-lions-ne... What if your app uses Python to perform IO? What if you wrote your code using PyObjC? Is there any way to sandbox that, or are you out of the Mac App Store for good?

makecheck 15y ago
That's a very good question. I use Python a lot and I combine it with C++ and Objective-C to build a very complex application. While it looks like a regular app and behaves like one, underneath it starts out as a Python interpreter that runs a script and loads compiled libraries. It's a model that works extremely well and I hope it continues to "just work". Sure, it's unconventional and I'd understand if Apple didn't expect most things to work this way, but I hope they don't just break it completely for me.
- jensnockert 15y ago
  It should work just like for Objective-C applications, it isn't implemented in Cocoa but at a kernel level. The sandbox has been around since Tiger (or at least Leopard) and with a proper configuration it works fine with Ruby/Python.

mattgreenrocks 15y ago

I thought this was supposed to be done by the end of this month? I'm excited, even if only for the prospect that anything I install from the App Store can't lodge itself everywhere in my system.

Too 15y ago

Will this have any effect in practice or will it just be the same as the different trust levels in .NET? The functionality for sandboxing is built in it's just that nobody uses it or knows how to test or enforce it. (with the exception of sysadmins). In any case i welcome all sandboxing, this is even something i would consider switching from windows because of, given that it actually works out good. Let's take an example from yesterday, i want a simple pdf-merge program. As it is now i have to spend 20 minutes researching a program on forums and other sites before i even install it to see if it's safe and everything. Compared to just installing and see if the result works. This is also why web apps are so popular, you can try hundreds of them with 0 risk for your other data.

ghshephard 15y ago

If this means that I can be reasonably certain an application that I purchase from the App Store will be prevented from screwing up parts of my system without my permission - then, as a user, I'm all for it. One day, in the future, apps will run in a chrooted/isolated virtual environment, with some actual guarantees that they are _incapable_ of touching anything but their sandbox, regardless of developer intent. Until that day though, this seems like a reasonable evolution to that world. Perhaps it speaks to my paranoia - but I've always been unnerved by the concept that an application can basically do anything to the OS that I can from from finder/shell. I have to believe that this sandboxing will reduce the potential for malware doing damage to the OS. The question I have is - will I be able to give applications like "Backblaze" the ability to read (but not write) from my entire set of user folders? If so, then that's the best possible case. Puts the power to control damage that an application can do in my hands.

jbrennan 15y ago
> The question I have is - will I be able to give applications like "Backblaze" the ability to read (but not write) from my entire set of user folders? Sure. This sand boxing only applies to App Store apps (for now at least). I imagine so long as you can install non-Appr Store apps, you can also have non-sandboxed apps.

ricg 15y ago

The end of utility apps? What makes (used to make?) the Mac such a great platform is that apps integrate seamlessly. Making them work together in new ways that were not anticipated by the developer is incredibly powerful (Unix philosophy anyone?). Sure, sandboxing will allow your app to talk to another app, but only if you request permission beforehand. But what if the app my app wants to intact with has not been written yet? What about application launchers like QuickSilver, Launchbar, and all the hundreds of other utility apps? Only allowing sandboxed apps will change the nature of apps that we will find in the app store from "utility" shifting to "just-do-one-thing". And about the question about whether the Mac App Store will become the only way to install apps on the Mac: the question is not if, but when.

natesm 15y ago
This has already sort of happened. Apps are forced to have some sort of permanent presence now. In the past, you could be running many of these and still have a clean menu bar. Now, you have to have an icon for Growl, an icon for Quicksilver...
- ricg 15y ago
  Sure, but that's not restricting functionality. Sandboxing on the other hand will simply mean that those apps won't get into the App Store in the first place.
  - natesm 15y ago
    Well, it restricts my ability to have a clean menu bar. Honestly, it's the reason I haven't installed Growl from the MAS.

pavlov 15y ago

I've been making Mac apps for nearly a decade now. I wrote a summary and opinion piece on this: http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox-makes-me-sad/ http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox... (HN discussion link: http://news.ycombinator.com/item?id=3191021 http://news.ycombinator.com/item?id=3191021)

startupcomment 15y ago

Now if only they can implement something like this for Safari so that individual browser pages are sandboxed from each other, as is the case in Chrome.