

Mac App Store apps must implement sandboxing as of March 2012 - kinetik
http://developer.apple.com/news/

======
teilo
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/Secur...](https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html)

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
"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.

------
lukifer
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
> Although if Apple starts making stupid rejections and standing by them, then
> I take it all back.

That's a given.

~~~
ugh
Apple typically didn’t stand by stupid rejections. They made them, didn’t
stand by them.

~~~
benatkin
We shouldn't have to embarrass a company before we get access to a useful
application.

~~~
betterth
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.

~~~
WayneDB
Has any application ever "jacked" all of your data? Is the app store really
going to debug apps for everyone?

How do over a billion PCs run Windows when there's no app store doing this for
them??

~~~
frankus
(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.

------
extension
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
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
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.)

~~~
gte910h
Huh? They're just talking about selling things in the Appstore.

They're not stopping people who don't distribute this way.

~~~
lukifer
For now. We're talking about a hypothetical future under 10.8+. I don't expect
it to change, but neither would it surprise me much.

------
ghshephard
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
> 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.

------
dgallagher
This SO question raises an interesting issue:
[http://stackoverflow.com/questions/7419912/how-will-lions-
ne...](http://stackoverflow.com/questions/7419912/how-will-lions-new-security-
model-affect-things-like-python)

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
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
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.

------
LeafStorm
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.

~~~
biot
It's free to register as an Apple developer and your ID will then work:

<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
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
You're right. I should have verified that before posting.

------
ewoodrich
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
Did you even look? It's publicly available:

[https://developer.apple.com/library/mac/#documentation/Secur...](https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html)

~~~
kstenerud
Click top link, follow the "App Sandbox Page" link from Apple's page
(<https://developer.apple.com/devcenter/mac/app-sandbox/>), get redirected to
<https://developer.apple.com/devcenter/ios/unauthorized/>

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

~~~
wes-exp
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/Genera...](http://developer.apple.com/library/mac/#documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html#//apple_ref/doc/uid/TP40010543-CH2-SW6)

~~~
droithomme
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.

~~~
planb
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.

------
ricg
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
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
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
Well, it restricts my ability to have a clean menu bar. Honestly, it's the
reason I haven't installed Growl from the MAS.

------
Too
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.

------
startupcomment
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.

------
pavlov
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...](http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox-
makes-me-sad/)

(HN discussion link: <http://news.ycombinator.com/item?id=3191021>)

------
kennywinker
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
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.

~~~
Groxx
/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.

~~~
kennywinker
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.

------
mattgreenrocks
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.

