The new Reader design will see core and risky PDF functions such as font rendering, Javascript execution, 3D rendering and image parsing happen within the confines of the application itself, isolating these from the privileges of the operating system.

This effectively relegates Reader to a new rung of privilege below that if the system user, which stops the application simply accessing key parts of the OS such as the Registry or file system as it likes. Instead all such calls will have to go through a trusted broker process if they want to communicate beyond the sandbox.

The new design won’t stop exploits targeting Reader but they will limit what can be done from within its confines. At the moment, that is more or less anything the attacker wants, including being able to take over the system.

As the developers admit, the potential hole in security is always the operating system itself, which can still be compromised, although exploiting such vulnerabilities is as easy as it easy a few years back. Microsoft’s software development lifecycle (SDL) has tightened up code security.

The first version sandbox will also not protect against read access to the file system (which allows data theft) or registry, or restricting network access, but future versions will look at this aspect of security.

Adding defence mechanism to specific applications other than browsers is an unusual approach to application design, but Reader’s security troubles have gone beyond that of most applications.