Good morning. So just before we begin, a quick show of hands. Who either saw the App Sandbox talk at last year's WWDC or watched the video online? Okay, that's great. That's a lot of you. Who has tried App Sandbox with their app thus far? Show of hands. Okay, that's also a lot of you. Who has brought a pitchfork to this talk? That's also a lot of you. Okay. All right.

Excellent. So one thing, this talk stands on its own. You don't have to have seen the last years to be able to follow along with this one. But a lot of the introductory material that was discussed in last year's talk is shortened this year. And this talk is actually being repeated on Friday. So for those of you who want sort of more of an introduction to all of this, you could actually come back for Friday's talk and until then actually watch last year's presentation online.

But you don't have to. And if you're here, you should definitely stay. And let's talk about fSandbox. So, App Sandbox, you know, we're going to be talking about safety engineering. That's what App Sandbox is all about. And I thought we'd start with an example of safety engineering that all of you are familiar with, which are cars.

So, last year, the American NHTSA, the Highway Safety Traffic Administration, announced that accident-related, car accident-related fatalities have been at their lowest level since 1949. Big milestone because people are driving more and there are more cars on the road, but the number of accidents keeps dropping. And there are a lot of reasons for that.

Primarily, there's been a ton of innovation in the space of making sure that you never wind up in an accident in the first place. So, everything from things that we take for granted, like anti-lock brakes now, to very new systems, like I think this year is the first year that some cars are shipping with a system that can detect when you're drowsy because you're drifting between lanes and can actually warn you, you probably shouldn't be driving, you're drifting, don't do that. So, traction control, stability control.

A lot of these systems that try really hard at blind spot detection, they try really hard for you to never wind up in an accident. But, at the same time, sometimes accidents happen. And when they do, you want something to contain the damage and the injury to the accident. And for this, another set of innovations, like the seat belt and airbags, which are now mandatory, have been invaluable. So, you can really see how much you can do with these things.

And this is very different than how computer security has traditionally worked on desktop operating systems. There, almost all the effort and all the work has gone into making sure that an attack never succeeds in the first place. But if it does, there's never been an analog to seatbelts and airbags that try to contain the damage from that attack.

And that set up this really bad dynamic between attackers and defenders, where defenders, in order to keep your system safe, have to defend everything 100% of the time, whereas an attacker only needs to find one hole, one place to take over, and if they do, it's game over. They've succeeded. The attack has been launched. There is no containment of damage to what they can do. They can just do anything they want.

Why is that? Well, it turns out that the assumption in computing that's led to this state of affairs is now 40 years old. That's 4-0. And the assumption is this: every program you run should run with all the privileges that you, the user, possess. In other words, security should be something that we erect between different users of a system, but not between different programs of the same user.

And it should be pretty clear that that assumption isn't really a good assumption these days. For one, most computing devices that we use today are actually single user computing devices. It seems pretty obvious that not every app you run should be able to access all the data you have. In fact, an even stronger statement is that every app you run should really only be able to access the data that it needs to get its job done.

But instead, we were in this situation where here is my favorite app. This is Watch Grass Grow app. It's an app that lets you watch grass grow. You know, if you exploit watchgrassgrow.app, you get to read the user's email and steal all their files and try and attack their passwords and get their full browsing history. There's just, there's absolutely no limit on what exploiting this app that should never have access to any user data can do.

So in response to this, you might say, well, why don't we come up with a way to ask the user what data do they want to make available to this app? What should this app be able to do? And it turns out that that doesn't work either. This is what your users see any time you put up a dialogue that asks security questions.

So there's this fantastic saying in Washington politics, which is, if you're explaining, you're losing. And this is true for security UI. It effectively does not work. Every time you put up a piece of user interface where the user has to make an informed decision about security, they're overwhelmingly likely to just click the button that they think will let them keep going as quickly as possible. And we've basically been -- the whole industry has been using Pavlovian conditioning to get users to just dismiss security dialogues as quickly as they can. So this is not a good approach.

All the while, the computing landscape itself has changed a lot. There has never been this many apps or this many developers writing apps. It's never been this easy to find new apps and download them and run them. Computers have never been more connected. And the security challenge has very much unambiguously moved to how do we isolate different programs instead of just different users. Ivan Krstić Another landscape change that you can see is that ones and zeros have started appearing all over the world. Actually, you know what? I love stock photos.

I'm just going to take a moment to reflect on this because if you look for stock photos of like a toaster and you find a toaster and it's a picture of a toaster, it's just a toaster, right? But if you take ones and zeros and you put ones and zeros over the image of a toaster, now it's a hacker toaster. I love ones and zeros. Anyway, sorry. Back to your regular schedule program. Okay, so... The number one enemy of security is complexity. And the software we're building is ever more complex. This is, I think, the biggest challenge for the entire software industry as a whole is complexity.

Complexity is rising, complex systems have vulnerabilities, they have problems, and the current set of affairs is that all you need is this one buffer overflow somewhere in the enormous amount of code that's powering your app and everything underneath it, and it's game over, the attacker wins and your user loses.

And, you know, the reason that this is an important point to stress is because I've heard this question a lot, actually, from you guys. Well, why would anyone bother attacking my app? Like, I have a small app, it's, you know, maybe it's not even super well known outside of its, like, niche of users. Why would anyone bother attacking it? Well, they might not. They might not bother attacking your app, but what you should remember is that your app probably accounts for a very small number of lines of the actual total code. That's being run when your app runs.

So there are all these frameworks and libraries whose code you don't control. And my favorite example, I mean, if you're showing a web page anywhere, if you have a web view anywhere in your app, that's millions of lines of code that you didn't write. Enormous complexity, including a just-in-time compiler and a full-blown JavaScript engine that's emitting native code in real time. A successful attack on any of that is enough to take over your app, which if not limited, means that the entire system has been taken over.

So that's the backdrop. That was not a good state of affairs. So it's against that backdrop that in Lion we introduced App Sandbox, which was an approach for more secure applications that tried to drive security policy by looking at user intent, which was a very different way of approaching security, one that does not rely on asking the user with dialogues what to do, and that focused strongly on containing exploit damage. If things ended up going wrong, can we contain the fallout? So specifically in the case of applications, we wanted with App Sandbox to make it hard for benign but exploited applications to steal or corrupt or destroy user data.

And the basic premise here, and I know that this is familiar to most of you because it sounds like most of you have tried App Sandbox, is that you as developers know what your app is supposed to be able to do during its normal course of operation, you know, when it's just doing its job and it hasn't been taken over. So, you can express that now to the operating system.

The operating system takes each application and puts it in its own container, basically giving it its own little home directory. And access to documents is actually controlled by the user but through implicit interactions that they're already used to. So, I'll show you what that looks like. And mind you, all of this, even though there's tight control on the user choosing what documents your application can access, all the sort of common special cases like the recent menu items or drag and drop or the pasteboard. They just all work.

So here is how app sandbox is built. There are basically four key elements. We're going to run through them very briefly. Entitlements are the list of those permissions that specify to the operating system what it is your app, what kind of permissions does your app want to be able to get its job done. There are things like my app needs access to the address book or my app needs access to the network.

And entitlements are very simple. They're basically a single property list, one level deep. You can edit it directly in Xcode, but there's also a very nice user interface in Xcode itself that we'll show you in a moment. And these are meant to be very straightforward to understand. There's only about 20 entitlements in Mountain Lion. Some of them have read only and read write flavors, but there's basically 20 base entitlements in Mountain Lion. So the number is intentionally very small. In fact, here is the complete list in Mountain Lion.

I mentioned containers and giving each app its own. So the way this works is also very simple. There's no kernel magic, there's no remapping of file access. All we do is export these two environment variables, home and cfx-user-home, that basically tells all the Cocoa APIs that an application directory that's been assigned to your particular app is the home directory.

So what that means is here's your app, we'll just put it in a sandbox, and if the app was to use a low-level call to try and access a documented user home directory directly, the sandbox would actually deny this access. But if you use a Cocoa API like NSHomeDirectory, that's actually within the container and the sandbox would allow it and everything's happy.

Powerbox is another key element of the overall design. So if you think about Cocoa open and save panels for a moment, they're this incredibly unambiguous declaration of user intent. When there's an open panel on the screen that an app put up and the user picks a file, it's very clear what they want to have happen.

They want the app to open the file that they just picked. And we use that user intent declaration, which is implicit, to drive security policy, which means in a sandboxed app, when an open panel comes up, it's actually run through a trusted mediator called Powerbox. And then when the user selects some files and folders, only those that are selected are actually made available within the sandbox of the app that's put up the panel.

And the important thing to point out here is that having this trusted mediator process and informing security policy by user intent means that it's of paramount importance for App Sandbox to know that the panel that the trusted mediator is putting up is actually being driven by the user and not by the app that might have gotten exploited and is trying to, you know, trying to use PowerBox to get access to everything.

And what this means is that sandboxed applications cannot synthesize user input. They can't fake mouse movement, they can't fake keystrokes, and the reason for that is simply that if they could, then the whole premise of driving security policy by user intent breaks down and suddenly the app is not sandboxed anymore.

Finally, because AppSandbox relies on this idea of the principle of least privilege, which is that applications should have only the amount of privilege they need to get their job done and no more, the idea of taking applications and breaking them up into different pieces that have different privilege requirements -- for instance, a piece of the app that just needs to be able to talk to the network, but not look at any user files, and then a main part of the app that needs to be able to deal with files but not talk to the network -- it's a very important idea. And because of this, XPC services, which are a new mechanism since Lion, have allowed you to take your applications, break them up into functional pieces, assign different entitlements to every piece, and do this faster and easier than has ever been possible in Mac OS X.

So each of these XTC services gets their own entitlements. Life cycle management is completely taken care of for you. You don't have to fork and exec these helpers or services. They just come up when you need them, they go away when you don't, and they're only available to the app that actually started them. So if you ship them in your bundle, they're only available to your app.

So what does this look like when it's all put together? Well, I used the example of Adium, which is an app I like a lot. It's a popular open source system messaging client. I'm sure most of you have heard of it. Very full-featured, makes really great use of a lot of OS X functionality. The app itself, so ignoring frameworks, is about 250 source files, about 75,000 lines of code, and then another 65,000 lines of code just in the app's framework. So not system frameworks, but actually just the frameworks that Adium itself provides.

And if we were to try and sandbox Adium, our process would basically be the same as for trying to sandbox any app, which is we're going to try and pick some entitlements that seem reasonable for this app for, you know, when it's doing its normal operation. We're going to sign the application, add those entitlements, we're going to run the program, make sure that it's actually sandboxed, and then we'll see if any sandbox violations come up. So let's see what that looks like.

Okay, here is ADM. And what we'll do is here's the main ADM target. We'll say that we want the code signed this. We'll scroll down. And down here, we'll say we want to enable entitlements. App Sandbox comes up automatically. And ADM needs to be able to receive files from our buddies, so we'll enable that.

It needs to be able to access user-selected files if we're sending files to buddies or receiving them, so we'll enable that. And... For our buddy list, we want this to be able to access our address book, so we'll enable that too, and we'll run it. And we'll run it.

So here's Adium. It came up. So the first thing we'll do is we'll switch to Activity Monitor, and in the View menu in the columns, we'll enable the Sandbox column. And so we'll see here that the Sandbox is enabled for Adium. Unfortunately, it's not connecting to the internet. I'm not seeing my buddy list, and in fact, if I look into my accounts, I can see that there's an error. Connection failed. It's going to try and reconnect. So I don't know what happened. Let's look at console.

So here I've just filtered by SandboxD, which is the sandbox logging daemon. And I'll notice that there's a bunch of sandbox denials that took place for ADM. And most interesting to me are these ones down here that say that sandbox denied a network outbound operation to these IP addresses and these ports. So that sounds like something that's important. And, you know, why is that? I don't know. Let's look back here in the target. Right, because I allowed ADM to receive inbound network connections but not to make any outgoing ones. So we'll just enable that and rerun it.

Okay? How about now? All right. That worked great. So, one thing I want to point out, when we were debugging this and trying to figure out what's actually happening, you notice these one-line summaries of what happened, but actually if you expand the little disclosure triangle and click full report, What you'll get is a nice, symbolicated backtrace of exactly where the violation occurred.

So, in here I can see that, you know, ADM was calling into AppKit, Core Foundation, CF Network, that eventually made it into libpurple, which is its networking library, and that tried to connect and make this network outbound connection, and because it didn't have the entitlement that enabled that, App Sandbox denied it. And as soon as I enabled the entitlement, everything was good again. So that's it. We now have ADM running in a sandbox, and it's able to make a connection, it's online. That was it. That was the whole process for sandboxing ADM.

So why? Why did we just do that? What was the point of that exercise? The point was that once we sandboxed ADM, an attacker who can take advantage of a vulnerability in ADM, or any of its frameworks, or any of its libraries, or anything underneath it, previously can take over basically the whole machine, has access to all of your data, all of your documents, everything that's there. But now, when sandboxed, if an attacker was to exploit a vulnerability in ADM, all they would have access to are the files that you sent or received from your buddies during that one runtime of ADM.

Meaning, only that one session. If you quit it and turn it back on, the file access is basically gone and the attacker has access to nothing. So if you didn't send and receive files, the attacker has almost nothing that they can do on the machine unless they have a second vulnerability on the system, and the second exploit for that, and can basically chain these vulnerabilities together to try and escape the sandbox. But basically, the bar has just gotten immensely higher for any successful attack against ADM once we put it in a sandbox.

App Sandbox came out in Lion, and since then we've put in a lot of work to add some really great stuff to make it support even more apps and even more features. Let me tell you about what we did. There are four key new features that I'm going to be talking about. And you'll notice that two of them are actually available already in Lion. So let's talk about security scope bookmarks first.

When, as I just mentioned, for ADM, when you quit it, any files that the user had selected during the previous run are, you know, the app no longer has access to the next time it starts. And that's, that default behavior where the app loses access to user-selected files when it's quit should make total sense to you. You don't want the app to just forever accumulate access to every file that the user has ever selected. So the idea that by default it loses access is the right default. But there are times when that default is simply not appropriate.

So most commonly, applications want to be able to allow the user to, in the configuration, pick, like, a commonly accessed set of files or a directory for either, you know, input or output that's really part of the app's configuration. Like, you know, write out all my files to this directory. I configured the app to do this.

I wanted to do it every single time it writes out a file. Well, if the user did that and picked a directory, the app needs to be able to preserve access to it across relaunch. And the default of losing access is not there. So that's not correct there.

Another common case where this is a problem are applications whose document formats rely on being able to reference files that are elsewhere on disk that are not stored in the document itself, which means once the user goes through PowerBox and selects the document to open, the app gets access to the document, but it can't follow those references elsewhere to the file system to pick up the reference files. So security scope bookmarks address both of these use cases. And I'll show you how. For the first case I mentioned, basically per app configuration, we have something we call app scope bookmarks. And these are available. They don't have new entitlements on them.

They are simply available already if you have the user-selected files access entitlement. And an example here is Mail. Mail is sandboxed in Mountain Lion, and Mail lets you pick a downloads folder, where do you want all of your attachments to get downloaded to. So Mail does this by using an AppScope bookmark. And AppScope bookmarks, as I'll show you, are locked to both the user and the app that created them. So here's what I mean.

A user picks a file or a folder, in this case, let's say, in mail, that I picked an alternative downloads folder. And through doing this through PowerBox, the user provides access to the file or folder to the app. The app can take this file or folder that it now has access to and send it into the NSURL Bookmark Data with Options API.

Which is going to return this cryptographic ticket, essentially, just an NSData object, just bytes, to the app and say, here it is, this is your bookmark, your AppScope bookmark for access to this file or folder. And the app, once it has this NSData, can actually store it anywhere it wants. It can put it in its container somewhere in the file system, or it can put it into user defaults or preferences, or it can put it in core data. It doesn't matter.

The app can just put it somewhere where it'll have access to it immediately after it's launched. Later, when the app is relaunched, it can pick up that NSData that it received previously, send it into the NSURL API called URLByResolvingBookmarkData. That will check the cryptographic ticket, and if it checks out, it'll send back the file or folder, basically make it available within the sandbox that the Apps.co bookmark was created for.

And since I mentioned that these are locked to the app and the user, if another app was somehow to get access to this cryptographic ticket and try and resolve it, that would actually fail because, again, we're locked to the app and the user. Of course, if this other app made its own Apps.co bookmark and the user gave it access, that would work just fine.

For the second use case, which are document formats that themselves allow file references to be placed in the document, we have a different feature of Security Scope Bookmarks called Document Scope Bookmarks. These actually have a new entitlement, the Document Scope Bookmarks entitlement. And they basically allow you to solve exactly this problem where you have a document and you want it to embed references to other files. Now, there are a few differences. Unlike AppScope bookmarks, DocumentScope bookmarks can only embed references to files, not folders. And they cannot embed references to files in certain system locations or hidden locations like Tilda Library.

Let me show you what this looks like. The user creates a document within their app, and let's say the user also picks a really, really big movie that they want to insert into the document, so the app doesn't want to take this multi-gigabyte movie and write it into the document. It wants to just maintain a reference within the document to the movie.

So what it would do now is actually take both of these and send them into the same API, Bookmark Data with Options, and it's important that unlike in AppScope where we just were saying, "What do we want to bookmark?" With DocumentScope, the app is actually indicating both what it wants to bookmark, in this case the movie, and what document it plans to put the bookmark into, in this case the document that the user created. Out comes a cryptographic ticket that is no longer locked to the app or the user, but is locked to the document that the app specified.

So, the presence of this bookmark in the document, you can think of it as later redeemable. It's a cryptographic ticket that can later be redeemed for access to the movie that it references. What this means is that when the app later comes along and the user just opens that document, normally the app right now, it has access to the document but not to the referenced movie. But what it can do is take the NSData that it got previously, send that and the document it got it from to the API.

The API will check that the bookmark is valid, that it's locked to the right document, and if these checks pass, it'll send back access to the movie and the app can now show it as part of the document. Thank you. As I mentioned, if another app was to get its hands on the same document, this works just fine because documents code bookmarks are meant to be interoperable between users, between machines, and between apps that know how to handle this API.

So we build security scope bookmarks with basically no new API for the bookmarks themselves. Mind you, bookmarks, I guess I should mention, since Snow Leopard bookmarks are the canonical way on OS X of locating files persistently, meaning even if they change names or they move to a different location in the file system, bookmarks can do this. So they're a replacement for some of you that have been doing this for a long time for things like aliases and FSRFs and so forth.

They're the modern way of doing persistent file references. So all we did was to provide some new flags on the existing APIs at the NSVRL level, and we also actually do have core foundational level APIs for this, and that's all you need to be able to use this functionality. But there is one key difference, which is that when you resolve... So if you have a security scope bookmark, even though all you get back, like in the normal case, is a URL telling you, you know, here's the movie.

It behaves differently. You have this URL now. It got resolved. Everything is great. But if you try accessing the movie, it'll fail. It'll say, "I don't have permission." Because the URL you got back from the security scoped bookmark resolution API is something we call a security scoped URL, which means you have to call a method called start accessing security scoped resource on that URL before it's actually made available within your sandbox.

So the flow is you resolve the bookmark, you get back a URL, you indicate to the operating system that you plan to make use of this URL by saying start accessing the resource, and it's now available in your sandbox. You use it. When you're done, because the user, let's say, closes the document, you have to indicate to the operating system that you have no further use for that resource at this time. And you do that by calling another new method on that URL called stop accessing security scoped resource.

This is really important because if you don't do that, you're not going to get the same results. balance the calls. Well, obviously, if you don't call start, you simply can't use the resource, so you have to call start. But if you don't balance the calls with stop, what's going to happen is the kernel will eventually refuse to let you do any other new interactions with user files, which means if you don't call stop and you call start enough times, the power box will basically not work anymore.

You will not be able to access any new files selected through it. Drag and drop will not work anymore. Bookmark resolution will not work anymore. So, you know, the kernel is basically only willing to let you call start so many times without balancing it out with stop, which is why it's important to make sure that you're reasonably balancing these calls.

Another new feature added since Lion, but also available in Lion, just like Better Way Security Scope bookmarks, are something we call application groups. So App Sandbox strives for strong isolation between applications by default. Well, sometimes, again, that default is not the right default, especially when we're talking about groups of applications from the same developer, either app suites or apps and their helpers, where being able to share data on the file system or being able to do direct IPC is really important.

So we now have a special affordance for just this. There's a new entitlement called Application Groups. This is either a single group for each app or an array of groups. The only requirement is that every group name must begin with your Apple-assigned Team ID. And applications that are in the same application group get to engage in direct IPC and get a dedicated file system location where they can share data.

Here's what that looks like. Here's our application. If it calls in its home directory, it gets its container. The container is within the sandbox. Everything's happy. But if the app happens to have a helper, the main app can't look at the helper's container. This is denied by the sandbox. So if the app and the helper want to share some data, this was previously difficult. It required some temporary exception entitlements. But now what we can do is take this new entitlement, application groups.

And here we're going to pick our team ID, put it in, put a dot there. And let's say that because this is an app and a helper, the application group name can just be my app for both of them. So we're going to take this entitlement. We're going to apply it to our app. We're going to apply the same entitlement to our helper. And what's going to happen is now there is a file system location named exactly after the application group that both of these can access and read and write to.

Moreover, because they're in the same application group, they can do direct Mach communication, they can do direct post-ex communication. And in fact, we have this API called SMLoginItemSetEnabled. If your helper is a login item helper, so it has a lifecycle that's different from the main app, Now, when the main app comes online, you can actually establish XPC communication to your helper.

So, by the way, we have sample code showing you how to do all of this. In fact, this exact example with a main app and a helper and SM login items set enabled and the application group's entitlement, you should check it out. It's great and shows you exactly how to do this. Another feature, and this one in Mountain Lion only, is something we call related items.

When a user selects a file or a folder, sometimes the application really needs access to something that constitutes a related item, usually in the same location. So one example is a movie player where the user opens a movie file, and by convention, subtitles are usually in the exact same directory as the movie file, but they just have a different file extension.

And previously, if the movie player was sandboxed, this would be difficult because the user gave access to the movie but not the subtitle file, so now the movie player can't even look if the subtitle file exists without popping open a new open panel. Not a great user experience. Well now, in Mountain Lion, through related items, we can do better.

The movie player can specify that it supports playback of movie files and that movie files have a related file type, basically subtitle files, which will make it so that if the user picks a movie file, the application will be granted access to the related subtitle files automatically. automatically with no need for another open panel.

A similar case, although slightly different, is an application like TextEdit, where if you open a new document, it's a rich text format document, and you type some stuff in, it gets saved as a .rtf, that's great. But as soon as you drag in a file, an attachment, an image into this document, TextEdit undercovers, will actually want to replace the file with a directory that's called the same thing as the file was, but the extension changes to .rtfd for .rtf directory, and wants to put the attachments in there. So through the Related Items API, TextEdit can now do just this.

It can basically say that .rtf and .rtfd are related, which means even though the user only gave it access... ...to the .rtf, it can transparently, without popping open a new save panel, upgrade the file type to be a directory and append the D to the extension and call it an .rtfd, and this can all happen without further user interaction.

So the way we do this, this functionality, both of the use cases are implemented through NSFilePresenter, and the declaration of patterns that are allowed to be related are basically go through your application's Info.plist, not your entitlements. And then you can do this. And we'll have some more documentation and an explanation for how to best use this as we go forward.

So last but not least, let's talk about automation. The Mac has been the best automation platform in the world, and OS X has been the best automation platform in the world, and still is. And when we introduced App Sandbox, We have to introduce some restrictions on how automation can work.

Specifically, even though we put no restrictions on whether a sandboxed app could be scripted, meaning if you have script editor, you can still control a sandboxed app any way you could before, what we did have to do is restrict how a sandboxed application can script the rest of the system.

And the restriction was pretty strong. By default, applications could simply not script the rest of the system at all. But in Mountain Lion, we have two brand new mechanisms that address the most common use cases for safe scripting from sandboxed applications. This, by the way, has been, I've received a lot of questions about why is it, why aren't there entitlements, why isn't there some way to let my app script the rest of the system? And the answer is very simple, because the way scripting is built on OS X is on top of a mechanism called Apple Events, and by default, if you can send Apple Events, then you are not sandboxed. Why? Well, because if you can script Finder, you can escape any file system restriction. If you can script Safari, you can escape any network restriction. And if you can script terminal, you can escape any restriction.

Which is why, by default, Sandbox applications were not allowed to send any Apple events. And in Lion, in order to get a Sandbox app to send any Apple events, you have to use a temporary exception entitlement. So this is what sending Apple events to mail, for instance, to compose a new message looked like in Lion.

There was this entitlement, temporary exception Apple event, and you would say, I want to be able to send this to mail, and that's how that worked. And actually, I want to take just a moment to point out, there was a lot of consternation about the name temporary exception.

What does this mean? Does it mean that Apple events are going away? Are Apple events now a temporary mechanism? No, it doesn't mean that. It means that App Sandbox had no permanent, supportable, safe mechanism yet for doing Apple events, which is why the only one made available was a temporary exception. But now in Mountain Lion, you get to see what the non-temporary mechanism looks like.

New in Mountain Lion is a mechanism we call access groups. An application that defines a scripting interface, this is what we call an SDef, can now take certain commands and classes and properties in its scripting dictionary and mark them up into access groups that will be accessible by sandboxed applications. We did this in Mountain Lion already for a few applications, so Mail exposes an access group called mail.compose. iTunes exposes access groups called playback, library read, library write.

Access groups can be defined in any application scripting dictionary. The application itself doesn't have to be sandboxed. And once an access group is defined, so actually let's look at Mail here. Mail has the scripting dictionary. It can do outgoing messages. So what we did was we added an access group identifier called mail.compose that names the access group. And we did the same for this outgoing message. But then actually for the send command, we did not put it in an access group.

What this means is that an application, that sandbox, can now use a new entitlement in Mountain Lion called Apple Security Scripting Targets to indicate that it wants access to specific access groups in specific applications. In Mountain Lion, here's how you would safely, with no temporary exception, be able to pop open Mail Compose windows through Apple Events and Apple Scripting.

You would say, "I am going to declare a scripting target in my entitlements. The target is 'Mail,' and the name of the access group I want to target is 'Mail.compose.'" So this is great for application authors being able to carve up their scripting definition and say, you know, these things are safe for sandbox staffs to be able to do.

I'm just going to expose it to them. And then you get to adopt and say I'm going to use this as a scripting target. That's great. But there are use cases where any kind of restriction on what a script can do is inappropriate. And generally that use case are attached scripts.

So if you imagine the general idea of an event handler, like a mail rule, that wants to be able to, you want to say when I get a message that matches this rule, I want to run this script. Well, if you wrote the script, right? You shouldn't be bound by what mail within its sandbox can do.

I mean, maybe you want the script to take the message, take the attachments, put them anywhere on the file system, open Safari. There's really no reasonable restriction that can be imposed upon that. So the scripting definition markup with access groups doesn't really address that use case. So we introduced another automation security feature called Application Run User Scripts, and here's how it works.

Under the user's library directory, there is now a new directory called application scripts. And under that directory, there's a new directory named after each sandbox application that uses this functionality's code signing identifier that's normally the same as the bundle ID. So basically, we assign a special new directory for every sandboxed app that the app itself can only read from. It cannot write to it.

But Through a new API called NSUserScriptask that is available in Foundation, the app can say, "I want to execute this script that's in my per-application scripting directory with no restrictions." This can be an Automator script, it can be Apple script, it can be a Unix script or a binary, and there is no restriction placed upon what the script can do.

The script runs entirely outside of the sandbox. And the idea is that once again, we're basically driving security policy by user intent. Because the application cannot write to that directory, the only way for a script to appear there is if the user actually put it there. So mind you, the app can reveal the application script directory in Finder, and the user can put a script there.

And by the act of the user indicating that they want to put a script there and make it available to the app, the app is now able to invoke it. The system will run the script on the app's behalf. With no sandbox restrictions. And using this functionality requires no entitlements.

App Sandbox is the most advanced desktop security system in the world, but it is not perfect and is not meant to be perfect. Its purpose is to be another strong barrier against exploitation and against coding errors. It does this by driving security policy by user intent, and it's a technology that's really complementary to Gatekeeper.

We'll be talking about Gatekeeper more, I think, actually, in this very room immediately after this presentation. Another very frequent question is, "Well, why Gatekeeper if there's already App Sandbox, and why App Sandbox if there's already Gatekeeper?" And the reason is because they solve fundamentally different problems. Gatekeeper is a mechanism designed to prevent inadvertent installation of malware, of applications that were intentionally malicious. App Sandbox is a mechanism that tries to make it so that coding errors and vulnerabilities in benign applications and applications that are not malware do not ruin the user's day. So these technologies are very much complementary.

We have some great documentation for you guys in the App Sandbox Design Guide. We have some phenomenal sample codes showing how to use the new features like the application groups entitlement. And obviously we will be here all week to answer any other questions that you have. But here's the thing: 30 billion downloads on iOS from the App Store. Every single one of those apps, every app you've ever run on your phone, every third-party app has run in a sandbox from day one.

And it's given users this remarkable carefree experience where they can go into the App Store, they don't worry about, "Oh, is downloading this app going to do something really bad to my phone? Like, what's going to happen if it gets exploited when it's browsing the internet?" This is just not even in their mental vocabulary. And we want to bring that same delightful carefree experience to OS X with App Sandbox.

To help you do this, we'll be talking a lot about related technologies. I already mentioned Gatekeeper and Developer ID, which is happening here immediately after this session. I mentioned two great new automation security features in Mountain Lion, and actually there will be a session covering those in depth.

And finally, for XPC, there is a session that's sort of a deeper session, deep dive on XPC and GCD and asynchronous technologies. But actually, not mentioned on this list, on Thursday, there is a session at 4:30 p.m. about Cocoa-level XPC. So we have some really great new Cocoa wrappers for XPC in Mountain Lion. And I really encourage you to visit that session and see just how easy it can be to establish XPC communication between you and your helper apps. Come by, say hello, we'd love to work with you and we'd love to help you make your applications secure. Thank you.