Ivan Krstić provided a computer security primer with some interesting historical context when he introduced the Mac App Sandbox in 2011. I learned these important concepts when I started writing web software in 1995 with the Shockwave player, but I’ve never seen as clear an overview as in the first 20 minutes of this talk.

Here are some highlights:

unfortunate-assumption

history-of-assumptions

We are conditioning our users to ignore our security messages…

if-you-are-explaining-you-are-losing

What if we took this approach with car airbags?

security-ui-airbag-analogy

The root problem is one of “ambient privilege.” Just because of the person who happened to run a program, we give that program all of the privileges we would give to the person. However, no human can understand and review all of the lines of code that we execute every day.

We are building complex systems, which always have vulnerabilities.

Complexity is growing, and there is no limit on the kind of damage an exploit can do. From cars to fighter planes, the amount of code we are putting into our vehicles has increased dramatically over time.

vehicle-loc

100M lines of code in a car today….

car-loc

what-works

Mostly, the Mac App Sandbox introduces ideas that the Web Browser introduced in 1993, Shockwave in 1995 with a full program language, then with JavaScript running in its own sandbox a couple of years later. There are some new ideas, of course. One that I particularly like is the notion of leveraging the File Open dialog to capture a user’s intent and seamless allow selective file access only to those files that the user chooses to open.

We need more creative and thoughtful user experience design that allows humans to safely interact with a complex world.

Create a new application (File > New > Project)

Create a Single View Application as usual…

dialog box with 'Single View Application' selected
Create a Single View Application

Name your project:

XCode New Project Dialog box

Fill in project name, organization name, identifier (like com.yourcompany) and for now, unchecking unit tests. I’m experimenting with a new Mightyverse prototype so I filled in:
* PhraseRecorder
* Mightyverse
* com.mightyverse

which created the app identifier: com.mightyverse.PhraseRecorder

It will also create a folder full of files named with your project name and this will also be the name of the app. I don’t like spaces in file paths, so I use camel case with no spaces.

Run the app now and you should see a blank white screen. I usually use iPhone 5 since the screen is small and easy to preview on my laptop. Let’s go to the home screen and see how the project name is used as the app name. (Choose Hardware > Home or shift-command-H)

multiple icons on home screen, new app has truncated name followed by an elipsis

The name I picked was too long so it appears truncated with elipses. This wasn’t the name I wanted the end user to see anyhow. This is easy to fix in XCode 7 (though not very discoverable). Stop the app (using the VCR controls at the top of the XCode window). Then click the little folder icon to see your file listing, then double click on the target name in the middle panel and type a new name.

First item selected in first panel, target in second

Run the app again and… voila! your app has a new name.

I’ve noticed that people have the illusion that leaders are these “idea people” with throngs of followers who just do what they are told. Maybe some leaders work that way, but that isn’t true leadership. I’ve found that effective leaders identify people who are passionate about a shared goal. Organizations are effective when the people in them have personal goals that overlap with the group mission.

Sometimes people approach me with ideas that they think I can make happen as a leader. I’m excited when it is something that they are personally passionate about and want to help make happen. I’m dismayed when they think they can outline an idea and I’m going to independently make it happen — as if I don’t have three thousand ideas that are queued up just waiting for a few hours of spare time or the right collaborator to make happen.

I think the way media portrays leaders is unfortunate. I understand why it is convenient to focus on speeches and interviews with people at the tops of organizations. In many ways, it is the leader’s responsibility to communicate the impact of the work that all of their folks are doing, so folks can focus on making awesomeness happen. I love it when reporters dive into the details and find the people who make the the things, write the code, organize the events, and write the words. We need leaders to rally around and gather teams who will work better together and create a bigger impact than each individual would alone.