Secure Viewer Software
Why Locklizard uses its own secure viewers
The reasons for preferring to use our own secure viewer can be summarized under three headings: security, control and resilience.
Using your own secure viewer also allows you to take steps to reduce hacking opportunities. This may be by implementing code obfuscation, or by changing packaging between version updates, or by implementing code checking to prevent code injection, or any number of other techniques used in security systems. Naturally these are not accessible when you are merely arbitrary add-on code to someone else’s system.
Conclusion: if you are offering security, and you are not in charge of the environment then you are not offering security.
Implementing a good DRM system is not for the faint-hearted. Whilst all information publishers agree that they want controls that prevent free re-distribution of their materials, few of them agree as to precisely which controls will meet their business requirement(s). This creates a situation where feature/function rich control systems have to be available in order to service a multiplicity of overlapping requirements. If the control application is not in command of its environment – it decides what features to display, it decides not to include code that could be used to circumvent controls – then it does not impose overall environmental control.
If you are not running your own secure viewer it simply is not possible to obtain this fundamental level of control that is a prerequisite to operating a DRM management system.
Conclusion: if you do not own the environment then you cannot realistically enforce controls that are ultimately outside of your control.
When you are delivering services that rely completely on an environment provided by another party, then you are exposed to a high element of risk that any change introduced in their environment will impact on yours. The upgrade from Windows XP to Vista brought that problem home to many people, despite the testing that went on before launch to try and reduce risk. Using a fixed and controllable secure viewer means that you are insulated from the market pressures that the supplier of another viewer product faces. Also, code and data attacks that may work against other viewers may have no meaning if launched against you. Data attacks commonly rely upon exploiting buffer overflow because the attacker can predict what will be overwritten. But when hackers are trying to mount an attack against an unknown environment that is constantly changing (as far as the attack vectors shown to the attacker) their problems are increased significantly, and the likelihood of sustaining an exploit reduced at the same time.
Conclusion: if you are designing a DRM environment then you should place reliance in as little as possible if you want to achieve resilience.
Whilst it may be fashionable to claim that there are advantages to using ‘recognized standard viewers’ because, in theory, they offer the greatest satisfaction of access to new features and interoperability, this is to ignore fundamental security tenets. If the foundations of a product are open to ready attack, then anything built upon them is equally flawed. Security systems have to be judged on the degree to which they are independent of the environments in which they operate, and the range of control functions they can deliver. New features and functions are always highly attractive, but their price is a lack of security.