To the average user, the two new security technologies coming to OS X this year—sandboxing and Gatekeeper—should be virtually invisible. But they could be all too visible to more advanced users, particularly those who use AppleScript and Automator.
As we’ve reported previously, Apple will soon require that all Mac App Store apps implement sandboxing, which forces developers to request specific permission (or, in developer-speak, “entitlement”) from Apple to give their apps access to certain parts of a user’s system. Few apps in the Mac App Store today employ sandboxing, but come June all new apps and updates to existing ones will.
With the upcoming OS X Mountain Lion, another new technology, Gatekeeper, will verify that an app you’ve downloaded and tried to run matches a digital signature that Apple has given the developer; if it doesn’t, Gatekeeper can prevent the app from running. In other words, it could prevent you from running malicious facsimiles of apps you think are OK.
Both of these new security technologies will have an impact on scripting and automation.
AppleScripts of your own: Apple doesn’t want to annoy you, or restrict you from doing the things you want to do with your Mac. So if you run a script “by hand”—whether from AppleScript Editor, from within Automator, or as a standalone app or droplet—it should be able to do whatever it’s scripted to do, just as it can today. Put another way, you should be able to continue to run scripts by hand just as you always have.
Internal application scripts: Some apps use “internal” AppleScripts to handle certain actions of their own. (For example, BBEdit () uses such scripts when it installs its command-line tools.) Such scripts are built into the app; you never see them in menus or elsewhere. Such self-referential scripts should continue to work as they always have.
If, however, a sandboxed app wants to use AppleScript to interact with another app or with other parts of your system—a menubar app that uses AppleScripts to control iTunes, say—then the new restrictions will come into play. A sandboxed app can’t use AppleScript to communicate with another app on your Mac, unless the developer specifically requests (and receives) an entitlement to do just that.
Apple awards such entitlements before a sandboxed app can be approved for the Mac App Store. Internal scripts will be subject to the same restrictions and entitlements as the app that contains them.
External application scripts: Apps can also use AppleScripts “externally”—which is to say the user initiates them, typically from the app’s Scripts menu. In Mountain Lion, such scripts will have to be installed in app-specific folders within ~/Library/Application Scripts. By default, applications in Mountain Lion won’t be able to save files to that folder, but users will be able to.
A developer offering a sandboxed app could therefore offer a downloadable set of AppleScripts from its own website. If the user then installs those scripts in the proper location, those scripts can be freely run by the user within the app, with no special entitlements needed. That’s because the user needed to intentionally install those scripts and then to trigger their execution. Because Apple considers the user the ultimate authority over his or her own Mac, the script will be allowed to run.
Developers who worry about whether or not users will install scripts in the right place will be able to create installers that place the scripts correctly; if the user runs and authorizes the installer, that’s treated as permission to put the scripts in the right place.
Gatekeeper: We noted above that user-created AppleScripts will run without problems. Apps from other sources that use scripts, however, might trigger a Gatekeeper warning: If they are distributed online without an Apple-approved developer signature, then Gatekeeper will alert the user to the issue.
Developers hoping to avoid run-ins with Gatekeeper for their app-based scripts will be able to do so, thanks to a new archive format offered with Mountain Lion called XIP. While AppleScript and Automator applications and droplets can’t be signed directly, XIP archives can be. By enclosing scripts (or custom Automator actions) within XIP archives, then, developers can sign the actions and distribute them without raising Gatekeeper’s ire.