I find all this somewhat amusing and depressing because all I can think is “…and you’re SURPRISED by this?” If you have even a conceptual grasp of sandboxing, the fact that TextExpander’s new version won’t be in the Mac App Store should be about as surprising that one won’t find daisies growing in a tar pit. But first, let’s see a tl;dr explanation of sandboxing:
App Sandbox provides a last line of defense against stolen, corrupted, or deleted user data if malicious code exploits your app. App Sandbox also minimizes the damage from coding errors in your app or in frameworks you link against.
Turns out not everyone is happy with Apple’s sandboxing rules
So okay, sandboxing is designed to protect against malicious code exploiting an application. For example, by reaching into another application’s process, and oh, I don’t know, monitoring everything the human types, and taking predermined action if the “right” thing is typed. Now, if you’re an awesomely cool dev like Smile Software, there’s no harm. You type, say “mosx” and poof! “Mac OS X” appears on your screen. Handy, no?
But if you’re an evil dev, then you look for things like phone numbers or numbers separated by a ‘random’ dash or space, or the heck with it, just copy everything typed, and send it out to a server somewhere.
So what’s the difference, other than intent and use of the data? Well, nothing. The same technique can be used for good or ill. For example, I’m in IT. I use a number of tools for things like security scanners that allow me to see if there are any holes in my setup, so I can patch them. But a black hat using those same tools would do very different things with that data. For me, it’s something to be fixed. For them, something to be exploited.
The point is, for any OS to play “good code/bad code” is a fool’s game. There’s no such thing. There’s stuff that’s allowed, and stuff that is not. Sandboxing obviously increases the latter and decreases the former, and one of the specific reasons is to keep applications out of each other’s business. This is not a theoretical risk mind you, there’s already been a bit of malware that took advantage of earlier implementations of OS X’s Input Manager to spread itself about.
This was in the OS X 10.4 days, which is why Apple changed how Input Managers worked starting in 10.5. Fortunately, this trojan/worm, Leap-A, aka “Oompa-Loompa,” didn’t do any damage other than keeping infected applications from running — which ironically slowed its ability to spread — but still, it’s a useful data point that shows what one person can use for good, someone else can use for ill.
That’s what Sandboxing is about: keeping application A out of application B outside of a specific set of defined entitlements. To be honest, there’s not a real problem for most applications. Most applications just don’t care about twiddling inside of other application processes.
Most applications are happy to limit their ‘external’ interactions to user-initiated ones, like saving, opening, printing, and maybe some automation via scripting. (Scripting is also affected by sandboxing, but that’s a tale for another time.)
In fact, looking at my dock now, I see, out of over 50 applications, maybe five that need to reach out and touch other applications the way Smile Software’s TextExpander does, and one of them is TypeIt4Me. (I’m old skool, sue me.) For most applications, sandboxing is really not an issue, they either never need to reach out and touch other applications, or, they do so in ways that are easily defined and so specific entitlements can be used. (Microsoft Office is a good example here.)
However, you do have applications that are affected by sandboxing. Like TextExpander. Face it, there’s no way to do entitlements, because Text Expander would need one for everything. It’s supposed to work in every application you run. If you’re going to grant a God Mode entitlement, why even bother with sandboxing at all?
Apple even has some basic guidelines for applications to determine if they can play in a sandboxed world, in the App Sandbox Design Guide. This includes:
- Use of Authorization Services. With App Sandbox, you cannot do work with the functions described in Authorization Services C Reference.
- Use of accessibility APIs in assistive apps. With App Sandbox, you can and should enable your app for accessibility, as described in Accessibility Overview. However, you cannot sandbox an assistive app such as a screen reader, and you cannot sandbox an app that controls another app.
- 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, as described in Entitlement Key Reference.
- Sending user-info dictionaries in broadcast notifications to other tasks. With App Sandbox, you cannot include a user-info dictionary when posting to an NSDistributedNotificationCenter object for messaging other tasks. (You can, as usual, include a user-info dictionary when messaging other parts of your app by way of posting to an NSNotificationCenter object.)
- Loading kernel extensions. Loading of kernel extensions is prohibited with App Sandbox.
- Simulation of user input in Open and Save dialogs. If your app depends on programmatically manipulating Open or Save dialogs to simulate or alter user input, your app is unsuitable for sandboxing.
- Setting preferences on other apps. With App Sandbox, each app maintains its preferences inside its container. Your app has no access to the preferences of other apps.
- Terminating other apps. With App Sandbox, you cannot use the NSRunningApplication class to terminate other apps.
Apple has clearly anticipated classes of applications that are not compatible with sandboxing. Does that mean they can’t run on Mountain Lion? No. What it really means is that a new versions of a non-sandboxed application can’t live in the Mac App Store. You can make bug fixes to existing non-sandboxed applications, but a new verison or updates that aren’t bug fixes? Nope, no Mac App Store for them.
Is this, as some have painted it, some kind of trend that could cause scads of developers to leave the App Store? Hardly. Again, the number of applications that actually cannot work within sandboxing are small compared to the overall population. The Mac App Store isn’t for them. Should Apple grant, as Harry C. Marks suggested, a “special” license for approved developers like Smile to bypass them? No. The point of security is that exceptions are very rare, and preferably, never issued. Yes, it sucks that a group of really good people like Smile had a product affected by this.
But it was going to happen. If not to them, then to someone else. Security is no longer something that only happens on a firewall. It’s everywhere.
Sandboxing is an important part of overall improved security without things like unusable passwords, anti-malware scanners, and the like. Sandboxing is something that protects people who don’t know how this stuff works or why. It’s for people like my father-in-law, who is a friggin’ genius at things like building houses, but doesn’t want to have to care about his computer. He just wants stuff to work, and if he can get that and never have to pay Symantec or Sophos another dime in his life, he’ll be just fine with that.
This is not Apple giving Smile the middle finger. This is Apple saying “If you want to be in the Mac App Store, you have to play well with sandboxing. If you don’t, you can still be on the Mac; OS X is not iOS. But you can’t be in our store.”
Apple is doing this for the huge number of Mac users who will never get on a Mac blog, or website, or ever comment about any of this. They’re doing it for the vast majority of their customers who just want stuff to work, be safe, and trust the Mac App Store to be a source of safe applications. Unfortunately, security is pain. The more security you have, the more pain you have. That expectation of safety means that there are kinds of Apps that simply can’t be in the Mac App Store.
For edge case applications like TextExpander, the Mac App Store isn’t a place they are compatible with any more. It’s a shame, but it’s not some great OMG, ALL MY APPS ARE TEH DEADZ0R!!!! It’s just the consequences of security becoming more important.
[Some images courtesy Shutterstock.]