flash pdf

Flash PDF Viewer & HTML5

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

The 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

Limitations 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

HTML5 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

HTML5 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

HTML5 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

Bad 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