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.
"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.
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.
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.
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.
That's a given.
http://developer.apple.com/library/mac/#documentation/Miscel...
The below link explained the error, and how it only occurred on certain volumes: http://www.xlr8yourmac.com/OSX/itunes2_erased_drives.html
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.
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.
They're not stopping people who don't distribute this way.
Anybody can release software outside of it and just forget about Apple's rules.
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.
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.
The sandbox has been around since Tiger (or at least Leopard) and with a proper configuration it works fine with Ruby/Python.
Apple's developer relations with anyone who doesn't want to fork over $100 just to read the docs are really poor.
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.
I guess my "membership level" can't see the tech docs.
https://developer.apple.com/library/mac/#documentation/Secur...
Thanks, that's what I was looking for.
http://developer.apple.com/library/mac/#documentation/Genera...
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.
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.
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.
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.
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?
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.
http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox...
(HN discussion link: http://news.ycombinator.com/item?id=3191021)
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.
