Adobe will employ a new sandboxing technology
in the next version of its oft-targeted Reader in the name of hardening security. However, the effort won't make Reader more secure in the long run -- and likely not even in the short run. I'm a big believer that the best predictor of future behavior is past behavior, and if you look at the two-decade history of security sandboxes, you'll see they all eventually failed big.
The best example of failed sandboxes can be found in Java
, which used an especially locked-down sandbox from the very beginning. In fact, it was so secure (no long-term writes outside the sandbox) that it proved too locked down. Nobody could use it to develop any substantial apps. To save a game score or spreadsheet, you needed long-term storage.
Sun then developed a more granular model in SDK 1.2, which involved asking users for permissions to do things outside the sandbox and allowed applet digital signing. This model proved to be too complex for users and developers alike, and it never caught on. With both sandbox models, Java has had well over 100 critical security vulnerabilities, and it continues to be patched on a regular basis, even though Sun has had more than 15 years to perfect the sandbox.
Google's Chrome browser has one of the best security models of the major browsers, and it includes a security sandbox. During the last two CanSecWest hacking contests, Chrome has been the only tested browser left standing. The hacking experts often credited Chrome's security sandbox for its seeming impregnability. In reality, though, Chrome is hackable; it just doesn't get hacked a lot in real life.