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:<p><a href="https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html" rel="nofollow">https://developer.apple.com/library/mac/#documentation/Secur...</a><p>The vast majority of apps on the App store can be sandboxed without effecting their functionality in any way.<p>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.<p>In other words, this change forces apps to be designed much more securely. It reminds me of the Android permissions model.
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.<p>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.<p>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.<p>[1] Although if Apple starts making stupid rejections and standing by them, then I take it all back.
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.
The real question is this: Is Apple going to eventually make the app store the <i>only</i> 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.
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.<p>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.<p>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.
This SO question raises an interesting issue: <a href="http://stackoverflow.com/questions/7419912/how-will-lions-new-security-model-affect-things-like-python" rel="nofollow">http://stackoverflow.com/questions/7419912/how-will-lions-ne...</a><p>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?
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."<p>Apple's developer relations with anyone who doesn't want to fork over $100 just to read the docs are really poor.
I wish I could find better documentation for this. I'm curious how their sandboxing implementation will work.<p>I guess my "membership level" can't see the tech docs.
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?).<p>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?<p>What about application launchers like QuickSilver, Launchbar, and all the hundreds of other utility apps?<p>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".<p>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.
Will this have any effect in practice or will it just be the same as the different <i>trust levels</i> 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).<p>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.
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.
I've been making Mac apps for nearly a decade now. I wrote a summary and opinion piece on this:<p><a href="http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox-makes-me-sad/" rel="nofollow">http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox...</a><p>(HN discussion link: <a href="http://news.ycombinator.com/item?id=3191021" rel="nofollow">http://news.ycombinator.com/item?id=3191021</a>)
It's time to write the eulogy for application automation and inter-application communication on the Mac.<p>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.
I thought this was supposed to be done by the end of this month?<p>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.