How new Mac OS X security measures will affect your AppleScripts

Advanced users and developers will need to rethink how they use the native scripting language

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 use sandboxing, but come June all new apps and updates to existing ones will need to per Apple's revised rules.

[ Discover what's new in business applications with InfoWorld's Technology: Applications newsletter. | Get the latest insight on the tech news that matters from InfoWorld's Tech Watch blog. ]

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 also affect 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 menu bar 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 the forthcoming OS X 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 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 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 (Mac OS X asks users to enter their password when an app is installed to give permission), that's treated as permission to put the scripts in the right place.

Gatekeeper: I noted previously that user-created AppleScripts will run without problems. But apps from other sources that use scripts might trigger a Gatekeeper warning: If they are distributed online without an Apple-approved developer signature, 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. Although applications and droplets can't be signed directly, XIP archives can be. By enclosing scripts (or custom Automator actions) within XIP archives, developers can sign the actions and distribute them without raising Gatekeeper's ire.

This story, "How new Mac OS X security measures will affect your AppleScripts" was originally published by Macworld.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies