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:
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.
"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.
> 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.
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.
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.
We shouldn't have to have a degree in CS and our own testing platform just to see if an application is safe, relatively bug free and isn't going to jack all of our data.
(Not sure if this is a troll or not, but I'll bite)
"Is the app store really going to debug apps for everyone?"
No, but obvious problems will be detected, and sandboxing will significantly control the damage a poorly-debugged app can do.
"How do over a billion PCs run Windows when there's no app store doing this for them??"
The perception (and in the pre-Vista era, the reality) of running Windows is that you need to be extremely careful about what you download (or even which websites you visit) or you risk data loss, your system becoming unstable, or involuntarily joining a someone's distributed computing experiment.
What Apple was trying to achieve with their app stores (and to a very large degree has achieved) is to allow unsophisticated users to fearlessly experiment with third-party software.
You're quite right, while malware is a threat often the biggest issues come from unforeseen bugs. Users with a long memory may remember the iTunes 2 update fiasco. where Apple's own update script was responsible for wiping user data.
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 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.
Actually, the real question is: what would Apple gain from killing 90% of the app ecosystem?
There are some apps that can't be really sandboxed (Little Snitch, virtualization tools), some apps you can't sell on the AppStore (video/audio/photoshop plugins) and there's even Apple apps that aren't available there yet (Logic, Filemaker, ).
Also, Macs are the only way to write OS X and iOS apps, it would make the barrier to entry way too high for most people, shutting off potential developers. How would you write, say, your Rails backend to your iOS app, on your Mac, if it was locked down?
But yeah, I would jump ship to Linux immediately as well.
If you believe that Apple is making a lot of money with their App Stores, sure. But they don’t. Even with the absolutely massive iOS App Store. The Mac App Store is tiny in comparison.
You and the other reply missed the part where even the iOS AppStore doesn't make as much money to warrant them running a whole ecosystem and shutting off musicians/producers/video editors/developers/hackers/enterprise users/people using Java stuff.
Apple has backed off on harsh decisions for much less than that. Remember Final Cut X? I bet the video editing community is much smaller than the developer community. Google, as an example, uses a lot of Apple laptops. They'd instantly stop buying them if that happened.
Until there's any sign of Apple wanting to close OS X, this is purely FUD.
Except they repeatedly said they're just above cut-even on the iOS AppStore. It's strongly doubtful that they'd do something like that purely for financial reasons.
I don't think they are that dumb, of course they know they would lose customers like us.
Indeed! Look at a novice Mac user, and you understand why Apple built the MAS. No matter how easy software installation was, the process was still difficult for most users (how to handle a bundle, package, zip file). The MAS has streamlined both installation and paying for an application.
Also, it's what people who bought a Mac because of the iPhone/iPad halo effect expect.
Locking down OSX would be an epic technical and social battle. I can't think of any reason they would go to war with their power users just to do that, especially since they already have a curated platform. They probably just want to give novice users a safe, curated experience by default.
I can absolutely see them doing this... and SOON. Give the MAS ecosystem a year, two at most, to mature.
There WILL be a switch somewhere, in the system prefs... a defaults write command... why? Because of Adobe, ProTools, Microsoft, and to a lesser extent stuff like homebrew and macports.
If there is a switch then there’s no problem. There would be no social battle. (Some people would be annoyed but that’s about it.)
I can absolutely see Apple adding such a switch and activating it by default. It wouldn’t be a big deal. (Well, I think Apple technically already added that switch. As far as I know Parental Controls can be set up in a way to only allow apps from the App Store.)
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.)
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.
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.
> 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.
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?
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.
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.
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?
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"
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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?
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.
It doesn't imply it theoretically, but Apple hasn't pointed out a way that scripting is going to be a part of their ecosystem. Apple Events -are- going away. XPC doesn't work like that. What's left?
They could theoretically introduce a newer and better way to do this... Apple Events were far from... well far from usable actually in most cases... but I've seen amazing things built on them. The thought of easy public inter-application communication and automation going away makes me uneasy.
Imagine if Twitter, Facebook, or Google decided to kill all their APIs some time next year... This is like that on a more personal scale.
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.