Hello, you crazy people. So, I'm Sal Soghoian. I'm the product manager for Automation Technologies at Apple Computer. And I'll be presenting today with Chris Nebel, who's the senior engineer of the Automation Technologies team. And this topic today is very important to people that like to get things done, that like to automate, and like to deliver a good computing experience for their customers, whether it's the company they work in, or people they sell scripts or automation-type things to.

A big question that has come up over the last year is, well, how does this all fit together? How do we enter this new phase of OS-ness with some of the funkiness from the last OS-ness? And I hope some of your questions get answered today. Secure Automation Techniques in... OS X Session 206.

So, I'm here today to discuss how the introduction of security and a focus on security that is highlighted by the new app sandbox architecture in Mountain Lion and the Gatekeeper architecture affects the world of automation and how that works together. In this particular session, we're not going to be looking at the security structures in great depth.

Instead, we're going to look at how the two technologies intersect and the work that we've done over this last year to make sure that the experience continues to be very useful and productive for you. So, we will recommend a couple sessions at the end of this talk that you can attend if you're more interested in some of the security details.

Now, for each release of OS X over the years, culminating in the release of Lion, with dozens and dozens of very productive features, Automation has remained an essential element of the operating system. It's been core to what makes a Mac a Mac and how a Mac runs. This continues in our new operating system release, Mountain Lion.

Now, in Mountain Lion, as you caught the keynote and have seen from the massive press that's been happening, it has a lot of new features. There's over 200 new features in the operating system release. It has a lot of focus on social, as well as some hardware-related things like AirPlay as well. But in addition to all of those features, it does have a focus on security of delivering a really safe computing environment to customers.

And specifically, there are a couple new things. There's Gatekeeper, which allows the user control over which applications are going to run on their operating system. And a new sandboxing architecture that determines the scope of what an application can do and how far it can extend its abilities and its powers.

Now, we have basically the two different kinds of worlds here. We have a world of automation that's used to kind of like an openness, open access, open abilities, that kind of a thing, with the world of security that is more defined, more controlled. So we have automation and security coming together, and what we've done is make it so that it becomes automation with security. And we hope that you find that the work and the things that we've put into place will satisfy your needs as people that automate and deliver automation tools.

Now, when we were designing this new architecture, we had a couple goals in mind. First was to preserve the functionality that you're used to. As people that write automation tools, you look for a certain set of abilities, and you rely on those abilities, and you build those abilities into the things that you do and the things that you deliver and that make you a livelihood.

We wanted to preserve as much of the functionality as we could. Secondly, we wanted that interaction between the world of automation and the world of security to be as transparent as possible, without a lot of dialogues, without a lot of interaction required. We wanted it to be logical and smooth.

And finally, we wanted to minimize any changes that we request of you as developers. We had your needs in mind in that one, especially because we know how much work it takes. You're in busy production cycles, and there's all these other things in the OS, and oh, by the way, you need to do this too.

So we wanted to minimize that, and those were the goals that we set in mind. And to outline how we achieved that, we're going to go through four different automation scenarios that kind of highlight the typical use of automation in Mac OS X and how those uses interact with the world of security.

So first will be personal automation, where we, and this encompasses all of the scripts, the workflows, the command line tools, all the different services, the things that you make yourself to run on your computer. Next, we'll look at distributing scripts, the process of making these available to other people, especially online, to download and use.

How does that get affected by this new world of security? Thirdly, we'll look at application-to-application automation, where applications talk to each other and ask requests of each other or commands to each other. So we'll look at that. And finally, we'll look at attaching scripts, which is a scenario that's very commonly used, where an application might host a script menu or make itself attachable to certain events. And we'll look at that scenario as well.

Okay, let's begin. Personal Automation. As I said, this is the kind of tools that you make yourself. You might pass them out in your shop, or you might just use them in your studio, or these might be tools that you as a developer provide to your customers. And they use the built-in automation technologies of Mac OS X, like AppleScript, Automator, Services, the Terminal.

All of those kind of things get encompassed into the world of personal automation. And it begins with... our friend Otto. And in case you didn't notice, this is the new Streamline Otto. He might have lost a little weight. He looks a little bit slicker. He's got new shoes.

We're prevented from putting a Nike logo on there because of a bunch of legal interaction. But anyway, he looks so much better now, we think he's really improved. So Automator is a visual interface tool that customers can use to create automation recipes that are called workflows. And these workflows can then be saved as either applets that run themselves or act as droplets, or as system-wide services that get installed contextually throughout the operating system.

Automator's been a very popular tool. It's in Macworld. It has a monthly feature on it. It's widely used by a lot of different customers. We use it internally as well. And so I'm very pleased to announce to you today that Automator in Mountain Lion runs with no restrictions whatsoever. If you... Well, I like how this is going. Okay, so if I keep saying the word no restrictions, you're going to keep applauding? Okay.

I like these guys. They're just my kind of people. So, all the workflows that you have, that you use, if you build in Automator technology into your applications, and you have your own internal actions, and you make those available, all that runs with no restrictions. You just create the workflows and run them like you always do, and it works fine.

Next, AppleScript, the AppleScript Editor application in the system-wide script menu. Now, AppleScript is an amazing technology. It's why it came to Apple 15 years ago. Yes, some days I feel like a dinosaur looking for a tar pit. But AppleScript's an amazing technology, and it has constantly been growing and improving. A couple system releases ago, we introduced AppleScript Objective-C, which really revolutionized the way that AppleScript works.

It's very popular to use, and the scripts that you write and run out of the AppleScript Editor, and those scripts, whether they're shell scripts or AppleScript scripts that you load into the system-wide script menu, and you execute from there, I'm pleased to announce they run with absolutely no restrictions.

Yay! I could just do this for an hour, and you would be so happy. And so would I. I could take the Kevlar off. No, no Kevlar today. So, that's Automator and AppleScript. Next, there's always the Unix command line. And what can you say about the Unix command line? But we love to love it.

You have all your various command line tools, and in addition to that big library that ships with every Mac because it's a Unix operating system, there are some commands dealing directly with Apple Events and with Automator. There's OSA script and the command Automator for the Automator. And with those, you can run and send Apple Events, plus you can also execute workflows files as well. And again, like everything else, it runs with no restrictions.

Yay! And this is because all of these tools that you use to create your personal automations, the AppleScript, the Automator, the Services, the Terminal, all of those tools, the code for that is executed by the operating system itself. So if you write the code and it gets executed by the operating system, there are no restrictions.

So, to summarize one more time, personal automation, scripts you write yourself on the OS, anything that you write that's executed by the operating system runs with no restrictions whatsoever. Okay, applause. All right, now let's get down into it. For the good stuff. No, it's all good. You're going to love this. So that's personal automation.

Next, let's look at distributing scripts. And this is really a common practice. You know, you find a nice tool that you're looking for. One of the great things about writing automation is the ability to share with other people. We always like to do it. It's like showing off the new shiny toy.

Look, I can make it do this. I can make it do that. Well, you can share on a friendly basis between office mates, or you could actually be part of your professional persona that you post scripts for other people to use as professional tools. You know, at Apple, we even do that, too.

And we just recently released a tool called the Mastered for iTunes Droplet, and it's part of the Apple Audio Mastering Tools and part of the new iTunes Mastered for iTunes initiative. And it's being used by hundreds of thousands of professionals worldwide to preview their songs and their audio files as to how they're going to sound in preparation for iTunes.

It's very high quality, and all of that preparation and all of that preview work is done by an Apple Script Droplet. So at Apple, this is an important tool for us. We take this very seriously. So how does this get affected by? the new features in Mountain Lion, specifically Gatekeeper.

Now, Gatekeeper was designed to give the user more control of which applications can run in the operating system. It lives in the security and privacy preference pane and it has a section to it that has three different settings. This setting that I'm showing right now is the Anywhere. That means that any app you download, it can just run.

The first setting is for the Mac App Store, and that means that only applications that were purchased or downloaded from the Mac App Store are allowed to run on this computer when that setting is active. The next setting is the Mac App Store and Identify Developers, those developers that have signing certificates with Apple.

And it is the default setting. That's really important to note that that is the default setting. That, as developers, is what you can expect your customers will find on the computer. Now, let's see how that interaction now will occur if the user is using Mountain Lion with the default setting. So here I am on this great website, macos10automation.com, and I found a droplet that I'm interested in. I click the link on the page.

I download the droplet. It unpacks and starts to run, and I get this dialogue that appears. And it says the applet that you've downloaded can't be opened because it is from an unidentified developer, and that your security preferences allow installation of only those that come from the Mac App Store and Identify Developers. So it's basically saying because the way you have Gatekeeper set up, I can't open this applet.

I don't know where it is. I don't know where it came from. So what's a customer going to do with that dialogue? A common customer is just going to look at it, and there's only an OK button, and they don't know what else to do. Now, a power user might know that you can select the applet in the desktop, and then you can select open from the action menu, and you get a similar dialogue informing you that it's from an unsigned developer. But it will allow you the ability to open and then continue to open. So you can do that once you've opened it once.

But as developers, it's really important not to depend on this, because this is put in place for a small fraction or a subset of customers who are really professionals, know what they're doing, want to run the downloaded item. So as somebody that provides tools for others to use, it's important for you not to rely on that. The default setting in Mountain Lion is that second one of Mac App Store and Identify Developers.

So then what's the solution? How do you provide a good experience for your customers? How do you let them run your applets or your scripts? And what you do is you use the developer signing certificate that you've gotten and a couple command line things, and you code sign the applet.

And then it will run as a normal downloaded process through Gatekeeper. The user will be able to download your app and run with no problem. So here to give you a demo of how you sign in Applet and exactly what goes into it is my good buddy, Chris. Take it away, Chris. Thank you, Sal.

So we've been working hard. We've finally come up with this brilliant applet that now we want to share with the world. So how do we do that? So the first thing we want to do, and this applies to any applet that you distribute really, is you want to set a bundle identifier for it.

Give it a unique bundle identifier. This helps the rest of the system out in identifying what this application is, what preferences belong to it, that sort of thing. It used to be you had to just edit the info.p list directly. This is new in Mountain Lion, part of the bundle contents drawer. There's now direct UI for changing the bundle identifier. So I've already got it set up here.

So now we want to send it out into the world. And so anything that you download through Safari is going to get flagged as being, you know, this came from the Internet. Gatekeeper needs to take a look at this. I'm actually going to simulate this process here by dropping it on a little applet, which, yes, was written in AppleScript.

So now if we try to open this, we get this Gatekeeper dialogue that essentially says, "You downloaded this from the internet. I have no idea who it's from, and you told me not to allow that, so there you go." Now, like Sal said, a power user might know, "Okay, you can work around this with a contextual menu," but most users aren't going to know that.

So how do we do this correctly? So the very first step is get yourself a signing certificate. I'm not going to go into the details of how to do that. There was a session earlier today on specifically dealing with developer ID. But the presumption is you've already got one. It'll show up in Keychain Access. Here's our signing certificate with an identity of Roswell, Inc.

And for the rest of this, we are going to need Terminal. So the first thing we're going to do is actually change the applet's permissions slightly. We're going to mark the applet's script as read-only. Applets, by default, like to write back to themselves so they can do persistent properties.

The problem is that once an applet is signed, writing back to it like that will actually invalidate the signature, and we don't want it to do that. So we're going to flag it as read-only, chmod a minus w. Thank you. And realize that, of course, properties will not persist after this point. You can't rely on that. So use NSUser defaults, preferences, preference file of your own devising, something like that.

The second step, and this is the really good bit, of course, is code sign the applet. So code sign, give it your developer ID, and also give it a signing identifier, which should match the Which should match the bundle identifier. And it's going to want our private key. Yes, we want to allow that.

And if we take a peek at it here, code sign minus display, this all looks like what we want. Right executable, here's our bundle identifier. So now if we pretend we downloaded this again. and run it. We still get a Gatekeeper dialogue because we still download it from the internet. Gatekeeper is very suspicious about this internet thing. But now it just says, you download it from the internet.

Are you sure you want to open it? Why, yes, we are. And there it goes. And now that we've approved it once with Gatekeeper, it's not going to ask us again. Next time we launch it, it just plain runs. So that's how to sign your applets for distribution. And with that, back to Sal.

You guys are so polite. I love that. You were taught well by your parents. Okay, so that was the second case we were looking at. The first case was we were looking at user scripts, then we looked at downloading.

And when I click the link, instead of a standard script window, the AppleScript Editor application comes to the foreground and presents this new text window.

And in this text window, you'll notice that there is the sample code. You can read the sample code, see exactly what the script is going to do. You can even select the sample code if you want, and you can copy it, or you can even drag it to the desktop as a clipping.

But the one thing you can't do in this window is run that script. It's just there for you to view, and it gives you the Gatekeeper warning that this script is from an unidentified developer. Your security preferences currently tell me not to open this. Do you want to go ahead and create a new script with this? And if you click the New Script button, then the code is taken from that window and placed into a new script. And then you can complete it. You can compile the script, run the script, whatever you like to do at that point. So there is this extra layer of interaction that does occur if you click a link, and it's an AppleScript URL.

Not a big thing, but that's something different. A little bit more security I think we can all live with for a better world. So, about distributing scripts. Now, if you work with Gatekeeper, then it may restrict your downloaded applets. So, therefore, you'll need to sign them if you don't want that restriction to occur, and then also be aware that Gatekeeper might interfere with the execution of the AppleScript colon URL by bringing up the extra little bit of security. Not a big issue, but I thought you'd want to know about it.

The next thing we're going to look at is the App Sandbox. Now, there's been a lot of talk about the App Sandbox and how it impacts automation, and everybody's had their own ideas about how this works, but we want to make sure that you hear from us how well automation works with the new App Sandbox. So, let's take a look at this.

So, app-to-app automation, using Apple events with your application. So, we know that applications Throughout the history of the Mac, have been able to use Apple events to communicate with each other, to make like a request for data from one application to another and return back information, or even to request an application do something crazy for it, like generate a picture of me.

So, in the world of a sandbox, an application can do what it wants within its own window, within its own environment. It's free to do and send itself events and do whatever it likes. It can exist in its own world. However, if it wants to send an Apple event to another application, it can't do that by default. Applications can receive events, but they can't send events to other applications, whether the target application's in a sandbox or not.

That's the default behavior. Now, to allow the communication and all the benefits of Apple events to still occur, we've created this structure called an entitlement. And if you request and get an entitlement to talk to a particular application, then your Apple event works fine. And here to talk to you about Apple events and entitlements is Chris.

Thank you. So first, I wanted to spend a little time talking about Apple Events security policy. There have been some misconceptions about this, so let's get the real deal. So first off, there are no restrictions on receiving events. As a sandboxed application, you can still receive anything. The practical upshot being that a scriptable application is still just as scriptable after it's sandboxed, with no code changes required.

Chris Nebel, Sal Soghoian So I think we're going to start with one caveat, which is that because of how the sandbox deals with files and extending the sandbox to access a particular file, if you're going to pass file references in and out of your application, those need to be actual file types, not just a text string that is a path.

Chris Nebel, Sal Soghoian The Apple Event Manager is clever. It will notice file references in Apple Events and create sandbox extensions for them, but it does not try to do that for just plain text paths. Chris Nebel, Sal Soghoian It's too open to a bit. Chris Nebel, Sal Soghoian So the sandbox people like to say that one buffer overflow shouldn't ruin your whole day.

That's where AppSandbox came from, is the notion of being able to restrict what an application can do so that when, not if, when it gets exploited, there's only so much damage it can do. Chris Nebel, Sal Soghoian And the thing is that if an application can't do that, then it's not going to be able to do anything. So the sandbox people like to say that one buffer overflow shouldn't ruin your whole day.

That's where AppSandbox came from, is the notion of being able to restrict what an application can do so that when, not if, when it gets exploited, there's only so much damage it can do. Chris Nebel, Sal Soghoian And the thing is that if an application can escape its sandbox, then suddenly it's unrestricted again. You're back to this old world where a single exploit ruins your whole day.

Chris Nebel, Sal Soghoian And Apple Events make a great way to escape the sandbox. You can use the finder to escape any sort of file system restrictions that you have. If you can talk to Safari, you can get around any network restrictions. Chris Nebel, Sal Soghoian You can just tell Terminal to do anything you like. It'll be happy to run a script for you. So, no Apple events by default. That said, there are perfectly legitimate reasons to send Apple events to other applications. One fairly common use is telling Mail to make a new message with your own document as an attachment.

And you can get an entitlement to let you do that. So here's what it looks like in Lion. We want to send an Apple event to mail. There's an entitlement, com.apple.security.temporaryexception. appleevents, and the value is a string, which is the code signing identifier of the application we want to talk to, com.apple.mail. So now we have permission to send whatever Apple event we want to mail, such as compose a new message.

Now, some of you may be thinking at this point, what do you mean temporary, exactly? What is that? This entitlement works, but we're not real happy with it. We like Apple events. We're not real happy with this entitlement, and here's why. There's something in security called the principle of least privilege. The idea is that an application ought to have just enough privileges to get its job done and nothing else.

And the existing Apple Event Entitlement basically stomps all over that. It allows you to send any event you want. And mail can not just compose messages. And we didn't just get permission to compose messages, we got permission to send it anything. Which means we could also tell it to, you know, grub through all your mailboxes and collect all your email addresses and package them up in a different message and send them off to Croatia.

Not exactly what we want. So the existing entitlement is simply too broad. It grants too many privileges. What we want is the ability to ask for just part of a scriptable applications interface. We want to be able to send it a specific command and say that that's all we're going to do. And that's what we're introducing in Mountain Lion. So they're called access groups, Apple Event Access Groups. An access group defines a set of scriptable operations, a set of commands and classes and properties.

They can be sliced and diced in a very flexible way. They are part of the application's scripting interface. It's SDEF. There's documentation on the exact format in the SDEF man page in Mountain Lion. And it's actually already being used in a couple of Mountain Lion applications. Mail and iTunes are both marked up with access groups. Mail for composing a new message, and iTunes with access groups to let you do playback and get information about the currently playing track and two for arbitrary reading and writing of the library. So let's look at what this looks like in an application scripting interface.

So this is a fragment of mails SDef. Like I said, this is real in Mountain Lion. So it starts off with a definition of the application itself and how it extends the base application class. And it says it has an element which is outgoing messages. So application contains some number of outgoing messages. There's a class definition for outgoing message itself which contains things like recipients, content, subject, yada, yada, yada.

And finally a command send to actually send the thing. So now we want to create an access group. So we do that by adding the new access group element to the SDef. So putting it inside the element declaration there, we give it an identifier, com.apple.mail.compose, and an access read/write. So this means now that as part of this access group, you are allowed to make a new mail message and get an outgoing message.

Now this doesn't give us permission to actually do anything with parts of an outgoing message. To do that, we add another access group element with the same identifier to the outgoing message class. And this, because we placed it directly inside the class element, it applies to everything inside that class. So all its properties, all its elements. So we've now got full access to everything that is part of an outgoing message.

And when it comes time to send, we actually made the specific decision that sending should be up to the user only. A sandboxed application really should not have permission to do this ever. So if it's not an access group, then you cannot use it with the new entitlement, which I'll talk about in a moment. Now, this has application to your applications potentially as well. If you have a scriptable application, you should be looking at marking it up with access groups.

It'll make it much easier and much safer for clients to use you in a secure environment. And the general rule you want to use for creating an access group is look at -- divide things along functional boundaries. Look at the kind of clients you use. Look at the kind of tasks they do. Is there a common task that you can say, "Okay, this group of things goes together." So we'll make a single access group for that.

Access groups are perfectly free to overlap. Something might wind up in a couple different access groups, such as the iTunes read and read/write, entitlements or access groups. And like we saw with Send, not everything needs to be in an access group. You might decide that, okay, for a sandboxed application, this is just not appropriate. If you had a personal user script, it is, of course, free to access anything. But a sandboxed application, eh, no thanks. So from the client application, you're the person -- you're the application that wants to control mail now.

There is a new entitlement for this: com.apple.security.scriptingtargets. The value is a little different now. It's now a dictionary. The keys are the code signing identifiers of the application you want to talk to, and the value is a list of all the scripting -- of all the access groups that you want to use. So in this case, we're composing a new mail message.

Here's the entitlement key. The dictionary containing the case-sensitive code signing identifiers. And finally, the list of access groups. So now this application, with this in its entitlements plist, has permission to tell Mail to make a new outgoing message and modify it arbitrarily, add attachments, whatever, but nothing else.

So principle of least privilege again. So to sum up for app-to-app automation, if you are receiving events, if you are scriptable, keep all your existing code, minor caveat about files versus text I mentioned before, and add access groups. Mark your application up with additional access groups, make it safe to use in a secure environment. If you are sending Apple events, all of your code stays the same.

If you are sandboxed, you will need an entitlement. Use the new scripting targets entitlement if you can, if you are talking to Mail or iTunes or some application that has added access groups. Otherwise, keep using the temporary exception entitlement. It will go away eventually, but for now, use it if you have to. And with that, back to Sal.

So I could tell you like the word entitlement, huh? You're going, wait a minute, wait a minute, this doesn't cover everything that I do. I don't want to ask for entitlement for everything. It's cool and everything, the access group breaking it down, making it, you know, okay, it's easier to ask for that, I can get that.

So the next thing we're going to look at, we'll expand this a little bit, and it's about attaching scripts. Now, if you have an application, you'll see this, it's fairly common, that sometimes applications want to host scripts written by users, and they want to make those scripts available in like a script menu that the user then goes to and runs a script, and the script does whatever the script wants to do, and then might get some information from somebody else and bring it back to the hosting application, or it might just target the hosting application itself and make it do a bunch of whiz-bang things.

But application can host and execute scripts, and this is a common practice, and it's been done for a while. Not only by presenting a menu, but many applications have events that users can attach a script to. For example, in Mail, you can create a mail rule, and this is an Apple script handler for dealing with a mail rule.

And when it gets executed, it gets passed, you can see up there, it gets passed a list of the messages that pertain to that particular rule or were approved by that rule, and it passes them to the script, and they can do whatever they want. So that's part of the standard mail application, is to be able to attach an Apple script to a mail rule.

Aperture also has attachability, and it has an Aperture import action, and here's what it looks like. And this particular one, it looks for if there are any movies on the import, and then will make a duplicate of the movies to the movies folder for you automatically, and then it will tweak the images based upon some ISO speed ratings as well. But here's another example of how an application can have an Apple script be attached to the application to use.

And the new Messages app also has handlers. It has numerous handlers for being able to respond to particular events, like somebody shows up or you get a message from someone. This one generates a random automatic response to your friend, and if you're really clever, you can keep them going for about 10 minutes before they figure out it's not you.

Now, the scripts that are attached or presented in the script menu are usually executed by the hosting application itself. The hosting application will load the script and then execute it for the user. And therefore, the restrictions on that script, it inherits the restrictions or the permissions of the hosting application. So that means if I'm living in this sandbox right here, how is this going to affect? Okay, so we have our little happy application in the sandbox, and it has a script menu and some user scripts.

So the user selects something from the script menu, and the application loads that particular script. And then if that script targets the hosting application itself, everything's fine, because in your own sandbox, you're king of the world, you can do whatever you like. And as long as the scripts are targeting your application, you can just go like crazy.

And they can do whatever you want. But let's look at a different scenario. So you have an attachable application here, and the user's created a script that wants to target another application. Well, we've seen in the prior section when Chris was talking about, you can't send an Apple event to another application by default. What you need to do is have an entitlement. And then once you have an entitlement for the target application, you can send it to another application. And then once you have an entitlement for the target application, you can send it to another application. Then it runs fine.

Well, this is all well and good, but there's an issue that arises in that the application, the hosting application, really doesn't have an idea of who the user script is targeting. There might be dozens and hundreds of apps on that computer, and the hosting application doesn't have a way of knowing what every application's in those user scripts. Therefore, it can't get in.

And so we're going to advance an entitlement for every possible scenario, because then applications would walk around, you know, they'd be entitlement bound with like tons and tons of entitlements. And it's too complex, too wieldy. So the solution to this scenario to keep providing the kind of functionality that you're used to, that the customer is used to, and still make it convenient as you have been, is to involve the user.

And what it does is the user takes the scripts and puts them in a sequestered folder that the system's aware of called application scripts. And then the application, when the user selects a script from the menu, the application requests the system to execute it. And because, remember, scripts written by you and executed by the system run without restrictions, the script runs without restrictions. So even though you're still hosting, you're still running.

So even though you're still hosting the menu and making it convenient, the code gets executed by the system rather than the application. Now, there is a new directory called application scripts, and there's a new class and foundation called NS user script task that makes this all possible. And Chris, why don't you tell us about it again? Semi-interesting? Okay, so NSUserScriptTask. So any application can use NSUserScriptTask, and it's actually something that we've kind of wanted for a while. It's a unified way to run user scripts.

One of the nice things about it is that it is a one-stop class that can handle any type of script. It handles AppleScripts, it handles Automator workflows, it handles Unix scripts. You can call them all the same way. And for AppleScripts, it runs them out of process now, which wasn't true with NSAppleScript.

so you can avoid a bunch of crazy threading issues. So, like I said, NSUserScriptTask, you can use that for generic scripts. You don't get a lot of control over exactly how you run it, though. For that, if you need that, there are specific subclasses: NSUserAppleScriptTask, NSUserAutomatorTask, and NSUserUnixTask. These all live in Foundation Framework.

And like I said, you can start using this in your application, whether you're sandboxed or not, in Mountain Lion. So where NSU's script task becomes really essential, though, is if your application is sandboxed, because now the script runs outside of the sandbox. And what makes this possible is to, was to realize that Before the application was running the script itself, but the script is not really part of the application. The script is part of the user's stuff.

So, can we somehow make it so that the user designates that, "Hey, this is part of my stuff?" And the answer is that the user puts it in this particular folder in application scripts. And the application can create this folder, you can show it to the user in the finder, but it cannot write to it.

So this maintains the security. And the only way for a script to show up in this folder is for the user to put it there. And this is sufficient user intent to say, okay, it is okay for us to run this script outside the sandbox with no restrictions. So there is a new constant to let you find this folder. It goes with the NS file manager URL for directory call, which I'll show in a moment. The actual location again is twiddle library application scripts and then the code sign-in identifier of your application.

Once again, you can create this folder, you can read from it, you can enumerate the contents, whatever. The substructure of the folder is completely up to you, but you cannot write to it. And there is no entitlement required for using this. It's just considered part of the base application behavior.

So let's start looking at some code for how to use this. So this is the code to locate and optionally create the scripts folder. Like I said, this is part of NS File Manager URL for Directory. There's a new constant for it, NS Application Scripts Directory. The only domain for which it is defined is the user domain.

And like I said, you can create it. You can ask to create it. You do have permission to do that. And from there, you can use it to show to the user, build a pop-up of all the scripts there are, whatever. So when it comes time to actually run a script, This is what it looks like.

So in this case, we're just using a generic script, generic running. So we allocate a NSUser script task, init with URL. If the script is, you know, if your sandboxed script isn't in the scripts folder, or if it isn't a format that's recognized, you'll get nil and an error back.

And you'll actually get a concrete instance of one of those subclasses as the result from this. And to execute it, you simply call executeWithCompletionHandler. When the completion block fires, the script is done, and error will be nil if it worked, or non-nil if it didn't. Do what you need to. If you simply want fire and forget scripts, just pass nil as the completion handler, and it'll take care of itself.

So, as Sal mentioned, a common use for trigger-based scripts is they will trigger based on some event that happened in the application, like mail messages arrived, a calendar event went off, you imported some pictures, there were some new files added to a folder. And commonly for these handlers, they will get past the things that caused the change, the photos that got imported, the files that got added. So to do that, you would need to actually pass those to the script.

You'd be specifically running an AppleScript script, and here's how to pass extra information to it. So, allocation looks almost exactly the same, except that we're allocating an AppleScript task specifically. And then you build up an Apple event that represents all the information that you want to pass to the script. If you're already doing this using NSAppleScript, this is the exact same event that you would build up and pass to execute with AppleEvent.

And finally, you actually call the script. Execute with AppleEventCompletionHandler. Again, almost the same. The one difference is that the CompletionHandler not only gets the error back, it also gets another NSAppleEventDescriptor, which is the result of running the script, if you want to use that. So, to sum up, if you've got user scripts, use NSUserScriptTask. Works great whether you're sandboxed or not.

I should stress that it is for user-supplied scripts only. Because of this "runs outside the sandbox" thing, it would actually be inappropriate to use it for scripts that are built into your application. So, NSUserScriptTask can replace NSAppleScript, AMWorkflow, and NSTask in your application, but don't just do a blind find and replace. Only use it for user scripts.

Use the specific subclasses if you need particular control over exactly how you pass information to or get information back from the scripts. And use the application scripts folder. Again, NSApplicationScriptTask. The NSApplicationScripts directory for your scripts. The script must live in there if your application is going to be sandboxed. And that's it. Back to Sal.

Very cool. So, to summarize what we've done with automation and with security. In Mountain Lion, security is an important focus of the operating system, and we know that automation remains essential to the OS and the way that a Mac works. And what we've done is we've combined the two, enabling abilities so that you have automation with security. Now, for personal automation, again, the scripts that you write using AppleScript Automator, the Terminal, and Services, all of those run with no changes and no restrictions. For when you distribute scripts,