The App Store, sandboxing, and AppleScript

When I read the Security section of John Siracusa’s Lion review at Ars Technica, I got a little nervous. Here’s what he says about sandboxing and the new behavior that will be forced on applications that want to be sold in the Mac App Store starting this November:

In Lion, the sandbox security model has been greatly enhanced, and Apple is finally promoting it for use by third-party applications. A sandboxed application must now include a list of “entitlements” describing exactly what resources it needs in order to do its job. Lion supports about 30 different entitlements which range from basic things like the ability to create a network connection or to listen for incoming network connections (two separate entitlements) to sophisticated tasks like capturing video or still images from a built-in camera.

It might seem like any nontrivial document-based Mac application will, at the very least, need to declare an entitlement that will allow it to both read from and write to any directory owned by the current user. After all, how else would the user open and save documents? And if that’s the case, wouldn’t that entirely defeat the purpose of sandboxing?

Apple has chosen to solve this problem by providing heightened permissions to a particular class of actions: those explicitly initiated by the user. Lion includes a trusted daemon process called Powerbox (pboxd) whose job is to present and control open/save dialog boxes on behalf of sandboxed applications. After the user selects a file or directory into which a file should be saved, Powerbox pokes a hole in the application sandbox that allows it to perform the specific action.

He said basically the same thing on the most recent Hypercritical episode. The part that worries me is the restriction on elementary things like reading and writing to files. If these are only allowed when “explicitly initiated by the user” how can AppleScripts work? An AppleScript that reads and writes files isn’t doing so under the explicit action of the user, it’s doing it under the control of a script, which seems to be exactly the sort of thing sandboxing is designed to control.

Maybe, I thought, if the user launches the AppleScript that would count as “initiated by the user.” Still seems like a vector for the kind of mischief Apple wants to quash.

Clark Goble of Clark’s Tech Blog wrote a post about AppleScript and sandboxing that showed he was nervous about Apple’s commitment to AppleScript, too.1 I tweeted a link to Clark’s post, which started a three-part conversation between him, me, and Ivan Krstić (@radian). Here it is, with links to the original tweets if you don’t trust my quoting:

drdrang: Unsurprisingly, @ClarkGoble is also wondering about Lion’s sandboxing and AppleScript: http://xrl.us/bk3kro.

radian: That post is wrong. Sandboxed apps can receive Apple Events by default. Temp. exceptions are only required for sending.

drdrang: Don’t apps like FastScripts and TextExpander need to send Apple Events?

radian: They do, but the post claims you need exceptions to receive. You can receive by default. Exceptions needed for sending.

drdrang: Fair enough. My concern is that if apps that send go away, there’s no reason for apps to receive. The whole AS ecosystem dries up.

ClarkGoble: The problem is the general case of sending AppleEvents.

ClarkGoble: The post doesn’t say you need exceptions to receive. I had thought you had to set the entitlement though to receive.

ClarkGoble: Reading through guide it looks like you don’t. http://goo.gl/o6mLk

Clark has fixed the mistake Ivan was talking about, but I think his main point stands: Apple’s new requirements for getting into the Mac App Store are going to make AppleScripting less attractive.

Sandboxing will be handled through entitlements, which are described in this developer guide. Briefly, every app that wants to be in the Mac App Store will have to request specific entitlements to be allowed to do things like read and write files, open network connections, access the camera, and so on. The full list is given in the aforelinked guide. As part of the vetting process, Apple will assess the request for entitlements and will give a thumbs-up or thumbs-down depending on whether the request matches the real needs of the application.

The ability to send Apple Events is in the entitlement area is called temporary exceptions, which, I confess, sounds a little mysterious to me. I’m not sure what the word temporary refers to. Clark seems to think it means these are actions Apple is allowing now but may shut down, or substantially change, in the future.

In any event,2 here’s what Apple says about this exception:

Send Apple events—The ability to send Apple events to the specified destination application.

So it looks like your application will be allowed to send Apple Events,3 but it will have to specify the destination app. It’s not clear from this language if you’ll be allowed to send Apple Events to more than one app, but if you are, you’ll certainly need to request an exception for each app.

Which sounds like a big problem for applications like FastScripts and TextExpander, because these programs need to work with any and all apps.

I suppose Daniel Jalkut could argue that FastScripts itself doesn’t send Apple Events, it just launches AppleScripts written in and packaged by Apple’s own AppleScript Editor. Given the problems he’s had getting FastScripts into the store—rejected because it won’t run a buggy Apple-supplied script that fails in Lion—I suspect that argument won’t fly.

The folks at Smile have no such argument. TextExpander’s AppleScript snippets don’t run code written and packaged elsewhere; you put the source code directly in TextExpander and it runs it when called. TextExpander has no way of knowing ahead of time which applications it will be sending Apple Events to. The only possible answer to that question is “all of them.” I don’t see how this is compatible with Apple’s sandboxing rules.

Now, TextExpander is already in the Mac App Store, so maybe all these sandboxing issues have been worked out and my worries are unfounded. If that’s the case, I’d like to hear someone from Smile weigh in and explain it. Because I’ve written quite a few AppleScript snippets, and I don’t want to see them sandboxed out of existence.


  1. I should mention here that AppleScript itself—a language I despise—isn’t the issue. It’s the Apple Events system of message passing that Clark and I are worried about. AppleScript is certainly the most common way to send and receive Apple Events, but it’s not the only one. Both Python and Ruby can handle Apple Events through the Appscript library

  2. I slay me. 

  3. I pretty sure Apple used to capitalize the word events, a style choice that made more sense than the current lowercase. I’m sticking with the old style. 


6 Responses to “The App Store, sandboxing, and AppleScript”

  1. Clark says:

    I think the real problem is that Apple isn’t clear at all what they want to do with Apple Events. Honestly I’d love an alternative solution that (a) deals with security and (b) is a little more intelligently designed.

    Right now though the silence from Apple overwhelms things. Given how halfhearted Apple’s support used to be for Applescript and how there’s been nearly no expansion the last 3 years I think some fear is warranted. Honestly the last new Applescript Apple did was Numbers and there they didn’t even have an Applescript to create a new document! None of the glaring problems with its own applications have been fixed.

    With regards to the language, to be fair, Apple did release AppleScriptObjC with 10.6. In 10.5 they released the Scripting Bridge but the major problems with the Scripting Bridge still haven’t been resolved. I often get the feeling these small changes were more due to independent initiative by someone at Apple rather than any real corporate value towards Applescript or Apple Events.

    What Apple has to realize though is that there are a lot of Applications that use Applescript, for all its many flaws, to do inter-application communication. Especially trying to get around flaws in Apple’s own applications. (i.e. syncing iPhoto between machines; fixing iTunes metadata)

    I’m 100% behind Apple’s security push. But explaining how this works would be helpful. As I said in my post I suspect Apple’s working on an alterantive. However Apple’s historic silence on all plans until near their release means a lot of developers are getting ulcers…

  2. Dr. Drang says:

    I believe Apple’s working on an alternative, too, but I doubt it’s being given much priority. Apple blows hot (Automator! AppleScript 2! Rails!) and cold on scripting, and we’re in the middle of a decidedly cool spell.

  3. Daniel Jalkut says:

    Interesting clarification: FastScripts, too, is already in the store :) I was motivated to submit after learning about sandboxing at WWDC and realizing that some degree of “grandfathering” might be an advantage.

    So, FastScripts 2.6 was accepted, and is currently available for sale in the Mac App Store. 2.6.1 is being held up indefinitely, ostensibly because of its behavior with the buggy Apple script you alluded to.

  4. Dr. Drang says:

    Sorry about the mixup, Daniel. As an old FastScripts user, I’d never even looked for it in the MAS.

    I wish you the best of luck, of course, but I’ll be surprised if grandfathering cuts any ice with Apple if they interpret the rules as the language of the developer guide suggests. It didn’t help Camera+ when Apple learned that it allowed the iPhone’s volume buttons to be used as a shutter release.

  5. Daniel Jalkut says:

    The difference is with these “established” MAS apps, Apple is either going to have to find a way to grandfather existing apps, or take the heat of MAS customers finding the very apps they have purchased in Apple’s trusted store are not just limited, but outright removed from the store.

    This is a dereliction of trust between Apple and end-users. Of course, we 3rd party software developers will also take some of the automatic blame, but hopefully Apple will consider the backlash they face as the stewards of the store before outright banning whole classes of existing software from the store.

  6. Clark says:

    That’s a really good point Daniel I’d never thought about. That said I think Drang’s right. It’s unlikely Apple will do a Grandfathering claus. I think they’ll just reject all apps not sandboxed come November.