Lion's new sandboxing feature has one groundbreaking aspect that has never been done with a sandbox environment before: Apple has enforced it on thousands of software developers through the Mac App Store.

The technical bits are not technically unique or groundbreaking, but the enforcement is. Apple is raising the bar on technical skill and expertise — and therefore the cost of production of all the apps on the app store. This has never been done for security, for fear of running off developers to another platform.

The technical principles behind sandboxing are well known. I first got excited about sandboxing with Dan Bernstein's software. For years djb has been writing secure software — at least secure compared to normal standards. His applications run as several separate processes with minimal interfaces (and defined, known failure modes), and the least interaction with the system required for their duties.

While the technique has been known for some years, the path of least resistance to application authors is the traditional monolithic program. It's much riskier, since a bug in one part of the program (say, the network side) can be exploited to do something to another part (say, the filesystem). So black hats can hit areas of code likely to have vulnerabilities (parsers that allocate and manage many buffers) to exploit a program to do something else (put files on the filesystem and/or execute code).

So breaking your program up separates the part that handles lots of buffers from the part that talks to the filesystem. It not only gets the programmer to think about the design more, reducing bugs, it also lessens the severity of any bugs that are left in. But it's only part of the battle. The system must also have the level of control which restricts the processes to just the set of resources necessary to do their jobs. Unix has some of this, but it's tricky. There also have to be standard services to call to get access to special resources, like arbitrary parts of the filesystem.

Even if all of that is in place, we still don't see tons of developers creating this type of secure software. So long as it's been possible for people not to write applications in this way, they will not. It's harder, and there isn't an economic payoff. It isn't a feature that users generally pay for, in part, because customers can't evaluate security well on a program by program basis.

But Apple has an incentive to keep the platform itself more secure. People may not evaluate single programs against each other, but they do know which platforms are riddled with security problems. The Mac has benefitted from low malware rates for years, and Apple has marketed on that fact. Now they must actively take care to keep that reputation.

iOS users are unprecedented in the current computer age for their trust and willingness to install applications. So far, that trust has been earned by Apple. Especially compared to Android, where trojans are removed only after they cause a few thousand people some harm. If Apple can make their Mac App Store as secure, then everyone with an ounce of technical sense will be telling their family members to buy Apple, if only to reduce their own support burden.

I applaud Apple for taking security seriously. Not because it's altruistic — they're doing it entirely because it's a measurable competitive advantage. I applaud them for gaining their advantage honestly, with real security improvements, instead of security theatre. They could have just tried to run from the bear a little faster than Windows. Instead they're trying something substantial, at a nontrivial cost.

Not only is it laudable, it's likely to teach a generation of programmers what secure software looks like. This could raise the bar permanently on what platforms are expected to provide, leaving a legacy of better-engineered code as the result. When all the dust settles, that may be the largest impact Lion has.