Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How new Mac security measures will impact AppleScript

Lex Friedman | March 2, 2012
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.

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 ( Macworld rated 4.5 out of 5 mice ) 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.

 

1  2  Next Page 

Sign up for CIO Asia eNewsletters.

COMMENTS
blog comments powered by Disqus