Origin(al) Sins
Video is now up from a talk I gave in October at OWASP's AppSec USA conference -- something of a departure from my usual speil:
I made some pretty glaring errors in the talk: you can't combine sandboxing with seamlessness for cross-origin content. It's something I'm hoping we can improve on in the browsers/specs, but it's not the current state of play. I also failed to mention that CSP is Mozilla's brain-child and they deserve huge credit for pushing it down the field. Similarly, I failed to mention that IE 10's CSP support is actually quite shite, supporting only the sandbox directive. Lastly, my objections to the OCAP worldview may have been oblique so, before the flames arrive in the comments, let me try again:
I think that you'll always end up with some variant of "object capabilities", if only through wrapper objects that hide protocol details. The OCAP world calls these "membranes" for particularly high-fidelity versions of this. When you have a word for it, it's probably common. Vending objects that represent capabilities is natural at some level, but I strongly resist the urge to take the pun too far. Don't get me wrong, I'm a huge fan of capabilities as the model for building apps that have real security by default; and I hope their pervasive use combined with more restrictive, separated execution contexts creates the world we all want to be in. My only quibble is on the developer ergonomics front. OCAP encourages the (perhaps naive) programmer to build many things inside the same "vat" (heap, context, whatever), leading to brittleness whereas protocols and true sandboxing can create secure boundaries that, importantly, look like boundaries. Systems that provide big "this is a security boundary!" disclaimers on their APIs while making it hard to screw them up stand a better chance of weathering the storms of human imperfection. Can you do OCAP right? Sure, it's possible, but as I argue in the talk, betting on humans to do the right thing is eventually and inevitably a loser. So I favor large, knobby interfaces over which you can send messages and no more. Wrap 'em up with an RPC layer...cool...whatever. But design a protocol with side-effects that are straight-forward to reason about on both sides -- not an object which can be easily intertwined with many others in a dense graph -- and you've got my vote. I'm even in favor of building those protocols and then wrapping them with easier-to-use APIs (call it "CAP->O", if you will), but eliding the step of a large boundary over which you can only send data, and making it relatively hard to cross? Nah, I'll be over here with the easy-to-reason about solutions that don't make my small-ish brain melt, thanks.
Also, I wasn't sure to what extent Doug was joking about "incompetent" programmers in his talk, so our disagreements may not be what they seem. Caveat emptor.
Thanks to Jeremiah and the other organizers for taking a risk and inviting someone who's been out of the security space for so long to give a talk. I promise to them that should they be so foolish in the future, I'll be sure to duck out and get one of my betters on the Chrome Security Team to stand in instead ;-)