Apple’s sandboxing technologies make it possible to control at a very fine-grain system level exactly which system resources an application should be allowed to access. It offers control over reading and writing  files, opening  network resources, and much more.

I’m really excited about sandboxing and also really terrified. Apple has given us, thus far, a limiting set of entitlements that don’t quite cover everything that reasonable apps want to do, or even everything that Apple itself has approved as acceptable behavior in the Mac App Store. Yet Apple has made it clear that it wants to see all apps adopt sandboxing, and the writing is on the wall that in particular, participants in the Mac App Store should be prepared for the day when non-sandboxed apps may not be approved for sale in the store.

For us developers looking into sandboxing our own apps, it can be tough to wrap one’s head around exactly what privileges need to be requested. One way to go about it is to sandbox your application with the strictest of controls (basically disallow everything disallowable), and see what breaks. Then you could add back whatever entitlements are necessary to get things working again.

On the other hand, it would be handier to have the system simply tell us what kinds of behaviors our app is engaging in, and what the corresponding entitlements would be to allow it to work even while sandboxed. Thanks to a tracing mechanism in the sandbox, this is in fact possible. Furthermore, you can use a command-line tool to apply arbitrary sandbox profiles to an application without having to modify the application itself.

I defined a handy shortcut in zsh for running an arbitrary app with the “trace” mechanism enabled, to show exactly what the app is accessing, simplify the output, and open it in my default text editor:

function sbx()
{
        echo '(version 1)\n(trace "/tmp/traceout.sb")' > /tmp/tracein.sb
        sandbox-exec -f /tmp/tracein.sb $1
        sandbox-simplify /tmp/traceout.sb > /tmp/tracesimple.sb
        open -t /tmp/tracesimple.sb
}

After you’ve defined this in your .zshrc (other shells, you are on your own!), you can do something like:

sbx /Applications/FastScripts
.app/Contents/MacOS/FastScripts

Then you use whatever features in your app you are concerned about, and quit the app. A text file will open with exquisite details about all the privileged actions your app was permitted to do, which would otherwise be forbidden by the sandbox.  Great, just copy that list of permissions into your sandbox entitlements plist, and we’re done. Right? Not quite.

The rules generated by the trace are very precise and may not be sufficient to cover your app’s behavior in practice. For example, if I open FastScripts, my scripting utility, and run a single AppleScript that controls the terminal, the resulting permissions trace reveals a sandbox rule that would allow that behavior to happen:

(allow appleevent-send
       (appleevent-destination "com.apple.terminal"))

That’s well and good for a utility that only ever needs to send events to the Terminal, but of course FastScripts is a general purpose scripting application that needs to send events “wherever the heck the user wants to send them.” Currently, Apple doesn’t offer a sandbox entitlement for this broad behavior, so it is not possible to sandbox FastScripts.

I think that Apple would have a lot more developer enthusiasm for this feature if it wasn’t so clear to many of us that our apps will be forced to lose features in order to adopt sandboxing. And while users may be happy about the prospects of improved security with the sandbox, I think there will be less excitement about the diminished functionality of apps whose features don’t fit nicely into the sandbox confines.

Developers and power-users can use the sandbox command-line tools now to get a good sense for what will or will not work down the road if sandboxing, with the current set of entitlements, is enforced by Apple for a large number of 3rd party applications. There is some documentation for these tools in e.g. “man sandbox-exec”, but the documentation is pretty minimal. If you want to read more, check out this useful document, which aims to give a better understanding of the sandbox, entitlement profiles, and how to use the command-line tools.

After the stress of moving (tomorrow!) is passed, I’ll be tackling a slate of new challenges this fall, including the usual work at Red Sweater, developing future versions of MarsEdit and my other apps. But I’ll also be punctuating the season with a few speaking opportunities at three great conferences.

• Çingleton. October 14-15. Montreal, Québec. My friends Guy English, Scott Morrison, and Luc Vandal teamed up to put on a very small, very focused “symposium.” I love the small scale and single-tracked nature, but it comes with one huge drawback: low capacity. Just as the similarly formatted C4 conferences sold out quickly every year, I expect Çingleton will do the same.
• MacTech. November 2-4, Los Angeles, California. This year’s show features a keynote from Guy Kawasaki, which will be exciting for me, since I’ve corresponded with Guy over the years: he’s provided a ton of valuable feedback about MarsEdit. Also exciting is the addition to the organization team of Scotty from iDeveloperTV, who will be running the developer side of the conference.
• Voices That Matter. November 12-13. Boston, Massachusetts. The floating conference moves back to Boston, the site of its first show, at which I also had the pleasure of speaking. They have just posted the schedule, revealing that Aaron Hillegass will be delivering the opening keynote. Definitely wake up for this!

The Voices That Matter folks are offering a coupon code with a twist: $150 off for the purchaser, with a $50 bonus for me as the speaker. I am not paid for the speaking itself, so if you are looking for a discount, consider using “BSTSPK5“. When combined with the early-bird pricing, it brings the cost of the conference down to $395.

With such a busy speaking lineup, I have once again had to pass on some other conferences where I would have enjoyed the less demanding experience of simply attending. In particular, I am bummed to be missing:

• 360iDev. September 11-14. Denver, Colorado. Another show I haven’t had the pleasure of attending yet, but that is celebrated by many of my peers. The schedule a more conventional, multi-track affair, which is great for those who prefer to pick a favorite topic from a variety of choices. The keynote address will be delivered by my friend Matt Drance, whose work you may also know from his past life as an Apple evangelist.
• SecondConf. September 23-25. Chicago, Illinois. Seen by many as the organic successor to C4, I have been hoping to attend for the past two years. This year’s roster of speakers is outstanding, featuring some well-known developers and … Andy Ihnatko! But it’s also notable for featuring some folks who don’t do as much public speaking, including Mike Rohde, the designer of Red Sweater’s logo!

Suffice to say, there is a lot going on this fall. If you are looking  for something to do, take a click-through to some of these great shows and see if any of them sounds like the right place for you.

I was hired at Apple on May 13, 1996. I was twenty years old, and had been using a Mac for approximately two years, during which time I had been contracting for Apple on and off as a QA engineer, while I finished my B.A. at UC Santa Cruz. Gil Amelio was the CEO.

I had grown up using mostly non-Apple products. My dad bought me a Timex Sinclair when I was six. I moved on to a Commodore 64, an Amiga 1000, and finally a Unix-based Sun 3/50 before I caught Mac fever in 1994. Two years later, I was working full-time at Apple as a software engineer at Apple.

When I signed on, Jobs was long gone, but his legacy was strong. Ten years after his departure from the company, bumpers in the parking lot remained plastered with the aspirational “The Journey is the Reward” proverbs that he had famously reiterated. Jobs made his mark, and the pursuit of excellence was alive and well inside Apple.

In late 1996, Apple announced that it would acquire Steve Jobs’s NeXT computing. Steve Jobs, in one role or another, was returning to Apple. I was overwhelmed, but excited. Although I had never worked for Steve Jobs, I felt that I had been working on his vision.

When I left Apple in 2002, it seemed that Jobs had won. He proved himself to critics by rescuing Apple from the throes of bankruptcy and restoring it to a company of huge successes. The iMac, iPod, and Mac OS X were all new testaments to his enduring legacy at Apple.

But he was just getting started. Still to come were not only the obvious iPhone and iPad, but dozens of less obvious successes ranging from the ever-improving Mac OS X, to the incredible Airport Express, to the fact that every damn thing Apple makes just works so damned well together.

Pixar Animation Studios is another of Jobs’s great successes. My three-year old, Henry, has lately been obsessed with everything Pixar. This includes “Cars,” which I have seen more times than I care to admit. It’s actually a pretty great film, and I’m fond of the romantic interlude where the protagonist Lightning McQueen is led on a carefree drive through the desert by his love interest, Sally. Their ride is set to an upbeat Randy Newman tune, which helps to pack an emotional punch in the scene.

Today I was driving in my own car, and heard an old Bob Dylan song that I realized the Randy Newman score reminds me of.  Steve Jobs is known to be a huge Bob Dylan fan, so it’s especially poignant that on the day of his retirement as CEO of Apple, I may have found myself listening to one of his favorite songs. Buckets of Rain also includes a concise proverb of its own, which serves as an appropriate comment on Jobs’s career:

“Life is sad, and life is a bust, all you can do is do what you must. You do what you must do, and you do it well.” — Bob Dylan, “Buckets of Rain”

Well said, Bob. Well done, Steve. For the rest of us: let us do what we must do, and do it well.

Those of us who do a lot of typing on Macs are familiar with a variety of keyboard shortcuts for navigating lines, words, and characters in text editors that use standard “Cocoa key bindings.”

Among those common keyboard shortcuts are cmd-arrow to move to the beginning or end of a line, and option-arrow to move between words in a sentence.

Starting in Lion, Apple fine-tuned the behavior by changing the definition of what constitutes a word delimiter for option-arrow navigation. While it used to stop on e.g. period-separated words, now it considers such chains.of.words to be a single “word.”  My friend Mike Ash noticed this and, when he complained about it to me, I set about finding a solution.

It turns out there’s a supported preference setting to alter this behavior. Look in your System Preferences under the Langage & Text pane, and you’ll find a “Word Breaks” setting with various options, including a special one just for nerds:

For most people, the “Standard” setting is probably the right choice. But computer programmers are far more likely to encounter words that are separated by syntactic characters such as periods, colons, etc. For us, it makes more sense to have the system pause at these word breaks than to breeze right by them.

Updates:

1. You should take note that after changing the setting, you won’t notice changes in applications until they have been quit and relaunched again.
2. As noted in the comments, this feature was apparently available in 10.6 as well, and was possible more along the lines of the default in 10.5 and previous. The growing consensus seems to be that it was in the update from 10.6 to 10.7 that a previous selection of this setting was not preserved.