PDF Security: Adobe Flash, HTML5 & Flipbooks
Security & the dangers of rendering PDFs to flash & HTML5
When trying to deliver secure PDF documents to the screen, many different approaches are taken.
The problem to be solved is easily specified – to prevent, as much as possible, the theft of the information being shown on the screen, while retaining as much PDF functionality as possible (indexes, internal and external links, searching, presentation and so on) – solving the problem however is not so easy.
Free 15 Day Trial
Protect PDF files: control use
- Stop unauthorized access and sharing
- Control use – stop printing, copying, editing, etc.
- Lock PDFs to devices, countries, locations
- User and PDF expiry, revoke files at any time
PDF Flash Viewer and browser technology
PDF Flash Viewer and browser technologyThe dangers of using a Flash PDF Viewer to deliver PDF DRM Security
One technique suppliers use is to convert a PDF document into Flash pages, and send those to the client through the browser. The apparently good news is they ‘only’ have to install Flash on the desktop, and they can ‘log in’ with an id/password scheme to get hold of the document, and there is no download.
The bad news gets worse. Unfortunately the native Flash viewer has not proved to be secure. The problems are not new, and Flash users should by now have got used to doing updates consistently (except for the period of time when Adobe code-signing keys were compromised).
But the fact remains that browser plug-ins and mobile apps can open systems to a wide range of vulnerabilities starting off with remote code execution and moving on to windows stored passwords thefts. For those not of a nervous disposition, see the current known Adobe Flash Player vulnerability list.
These kinds of vulnerabilities are not enhanced by the frequent use of JavaScript, which is needed to provide some of the functionality that will be lacking in the Flash system, which has few system interfaces. Text search is an obvious problem. In most Flash systems it is done by searching the underlying source code, or an XML rendition, but neither of these is satisfactory from a security viewpoint. Sending the source kind of defeats the objective?
So although it seems to be a simple implementation, using Flash on its own only creates security problems, and leads to a low functionality result. Trying to improve the functionality makes the security even worse. More of a lose/lose situation.
PDF and HTML5 Viewer
PDF and HTML5 ViewerLimitations in HTML5 and ebook security
The next logical step for companies producing flipbooks and requiring a more robust solution was to move to HTML5 for the viewing of ebooks in a browser. This provides all the same interactivity and multimedia support with less of the flash specific security issues.
However, if you want security for your ebooks (stop users sharing ebooks, copying text, printing, etc.) then a browser can only provide a limited amount of control (since no software is installed on the client). If controls have been badly implemented it is relatively easy for users to edit the content in the browser and turn functionality back on – sometimes this is as simple as removing a piece of JavaScript. Even some DRM systems decrypt content on the server (rather than in the browser) making it easier for users to bypass controls.
Many HTML5 Viewers offer basic content protection such as:
- Stopping downloading
- Stopping sharing
- Stopping printing
Stopping downloading
Stopping downloadingHTML5 Viewers try and prevent users downloading content by disabling right-click and the (File→Save As) from the browser menu (File→Save As) but the content is still available on their local disk from the browser cache.
With Safeguard Secure PDF Web Viewer we only deliver encrypted chunks to the browser and each chuck is decrypted on the fly as it is viewed.
Stopping sharing
Stopping sharingHTML5 Viewers rely on a username and password login that can be shared with anyone. There is no limit to the number of people that can be logged in at any one time or any location (geoip) controls. So stopping sharing relies on the user not sharing their login credentials with anyone.
Safeguard Web Viewer limits the number of concurrent logins (the default is one user with the same credentials logged on at any one time) and enables you to automatically lock use to specific locations (say the location the user first logged on to the system) so you can be confident that your documents are not being easily shared across the Internet.
Stopping printing
Stopping printingHTML5 Viewers can disable the print options available in a browser. However it is important to test this functionality in all browsers as the JavaScript control (assuming the user has not removed it) may not work in the less commonly used browsers.
Safeguard Web Viewer will stop all printing and fail to load any content if any of the source code is modified.
Flipbook Security
Flipbook SecurityBad implementations and flipbook security
Apart from the security controls listed above (that are often next to useless), it is important to remember that flipbooks were not invented with security in mind – it was added as an afterthought and is often badly implemented.
For starters, content is not even encrypted. That is why some systems enable you to prevent Google and other search engines from listing your ebooks. So you are relying on access controls working correctly for your ebook protection – this can be rather worrying when some systems can be easily bypassed by removing the login screen by editing the source code in the browser. That is why a good system should also use encryption and extensive code obfuscation. If you have a $3 ebook you may not be too worried, but for a $1000 report a flipbook system would not provide adequate security.
Customer Testimonials
