>I'm assuming the "no actual compromise [...] has succeeded" part of the above comment was a typo.
I think you're misinterpreting what he wrote. I read it as meaning that the _goal_ is to stop the malicious program _early enough_ (by limiting system access) that the exploit won't have a chance to succeed, by limiting the surface area of the system (not that it's already 100% effective today, just that is the goal/'focus').
For example, why on earth does a web browser need r/w access to all of the user's files all the time? What about confining the browser so it can only read/write its files (configuration, cache, history, etc) but it has no DIRECT access to any other files? Downloading/Uploading could partly be partitioned off to a seperate process... for a download... Browser asks the other process it wants to save a file named 'NAME', and the other process opens the file dialog for the user to select the file... then the browser pipes the data to the other process, and that other process writes it to disk (upload would be pretty much the same, just reverse the data flow). This'd basically limit browser based exploits to *only* being able to steal your browser's own data (and would also likely not be able to persist across instances), unless an additional exploit or two are also found in the limited area that the browser can actually access (which'd still be a huge improvement over the current model of 'screw the user, protect /bin/bash!' for non-server systems).