The sweet spot in internet security.

New standards like HTML5 often try to address security problems by providing new security features. I think some of these are well-intentioned but are not moving us to a fundamentally more secure internet.

Let me commit blog suicide by starting with a chart that'll drive away most of my potential audience. (Bye :)

	Introduces New Tools	Improves Security of Existing Tools
Large Audience (Web Devs)	Limited. Slow to take hold. E.g., toStaticHtml	Good, but doesn't address zero-days. E.g. PHP magic quotes.
Small Audience (Library Authors & Security folk)	Good, but won't help legacy apps. E.g. <iframe sandbox="...">	The sweet spot. A (relatively) small group can address emerging threats quickly. E.g., native JSON support

Small groups respond more quickly

The chart is broken down by the size of audience needed to work with the new feature. There are many more web programmers than library developers and web security professionals put together. Any tool that requires most web programmers to use it and use it consistently is limited in its effects. Conversely, if a small audience can change a system to be more secure, then it can have wide-reaching effects. For example, browser developers, a very small audience are now implementing native JSON support. This means that many of the websites out there that have old buggy versions of JSON.js for which there are known script injection exploits, will become more secure because those old libraries were written expecting JSON to become standard and so defer to the newer native implementation on browsers where it exists.

Fix existing code; don't only enable newer better code

The chart is also broken down by scope; will the changes only affect new code that uses new APIs, or does it fundamentally improve the security properties of existing code. If it requires developers to update code, then it can definitely help, but its effects will be very slow to be felt, since existing sites will have to be updated to use it. Website developers are notoriously conservative, and often rightly so ; you can go out of business by updating too soon and breaking your site for old browsers.

Not everything needs to be in the bottom-right box and not everything can be ; there are no silver bullets in security. It is good to have new tools, and to have tools targeted at the web development community at large, but we should always prefer the bottom-right.

Getting Ahead of the Game

New tools also have a problem. Many new security tools are reactions to emerging threats -- the threat model has changed so the HTML and Ecmascript committee respond with new tools that are suited to the new threat model.

But the threat model is only going to keep changing. To get to the sweet spot, we need meta-tools that help small groups of security professionals bolt new security policies onto existing code while maintaining backwards compatibility. And a way to get these changes onto the web at large by targeting a small group -- content aggregators and social hubs that use a plugin model are a good candidate. Ideally we'll get to the point where we have a patch-and-update cycle for the web. As the threat model changes, security specialists use the meta-tools to adapt existing systems to just keep working, but better.

I think the best candidate for meta-tools are software virtualization tools, like the membranes and proxies proposed for Ecmascript 5. And my project, Caja is aiming at providing that layer. We're not in the sweet-spot yet : we've virtualized the DOM and network so we're able to provide a huge array of security policies, but our questionable library support keeps us out of the sweet spot; we're working on that.