Web-based document copy/print/save protection

We recently needed to publish some documents which required some fairly strong restrictions on usage (viewing only ... in other words no printing, no copying, and no saving). Even though I find these restrictions to be a little draconian for something destined for the Web, I always try my best to accommodate any requests.

Initially I had posted the documents in PDF format since it's easy and has built-in security against printing and copying. I had also thought you could prevent saving, but that turned out not to be the case, and something I didn't realize at first. Much fuss was made regarding this "problem" because we had signed a contract outlining the copy/print/save requirement in return for our usage of the documents.

Upon further investigation I found another problem in that the security features of PDF are voluntary to the reader. Naturally Adobe's products follow the restrictions, but it's possible that other products out there may ignore the restrictions.

Then there's always the fact that the user can just save the original file from the link to it (right click + "Save link as ..." from most Windows-basec browsers).

Many issues to consider with regard to this "no saving" clause. I think the tech group should have been consulted regarding the final contract. I don't think we would have ever signed off on that clause because it's the nature of the Internet ... in order to view something stored remotely it has to be copied locally. And even if you could prevent disc storage the document would have to be placed in memory on the local machine. So "no saving" is really a difficult problem to tackle.

But tackle it I did ... by moving to Flash. With Contribute 2 Macromedia provided a nifty little program called FlashPaper. FlashPaper is like a Flash version of PDF (or more accurately PDF lite). It's missing some featuers that make PDF useful but it pretty much serves the needs for this particular problem. I was able to make the document unsavable by using a shell Flash presentation to load the FlashPaper document. Now if someone attempts to save using the web browser's save functionality all they'll get is the shell Flash presentation.

One annoyance with this method is that the FlashPaper navigation bar no longer floats on top of the document. Viewing a FlashPaper document directly the toolbar maintains it's size and adjusts the number of on-screen controls available based on the width of the display window. If the presentation is resized with an embedded FlashPaper the toolbar resizes like any ordinary Flash object. Worst of all the toolbar buttons do not scale up very well.

That's just an annoyance, though. One important feature is lost by moving to Flash and that is the accessibility enhancements provided by PDF. When I scanned in the pages (as images) the PDF did some OCR magic so that the text of the documents was actually accessible to screen readers (awesome!). This is an incredibly useful feature that requires further investigation. At any rate, converting to Flash killed the OCRed text.

References:

• Importing FlashPaper 2 Documents into Macromedia Flash and Using the FlashPaper API
• FlashPaper API

Update 2006-05-09:
Note to self, pay more attention to what's going on around you. Apparently I did get a copy of the "contract" at some point and may have even signed off on it (though it's hard to say because it came via hard copy and has no date stamp). I'll keep this in my files as a sample of a bad contract.

Mass Mailing: 2061 Connections - March/April 2006

The March/April 2006 issue of 2061 Connections went out on 21 April 2006 at 2:13:20 PM to 3888 recipients.

Scripting: Browser Security Updates

Browser makers have been focusing a lot on security with their latest updates in an attempt to decrease the exposure of their users. Mostly this is a good thing, but some of the changes are starting to interfere with development of the IERI utility. Specifically, all of the major browsers ¹ now no longer allow web pages to access local files except through approved user controls such as the file upload form field.

This is a major problem for the utility because we have been relying until now on locally viewed video as a means of decreasing cost and management time. The quickest way of resolving the problem is to switch to streaming for video playback, but this assumes the user has access to a high-speed Internet connection. Plus it would require a significant investment in infrasturcture (storage, connections, and streaming server software) and administration of a movie database.

Another solution is to use signed JavaScript, which I have previously investigated and which has problems of it's own.

A final solution I have in mind would be to create a locally installed HTML application, which would cost less in terms of software but require a significant time investment to develop. This method would rely on a remote database for storage but would run the shell of the utility on the local machine. This approach might also run into security issues, however, so it would require a bit of investigation to determine its viability. Plus updates would be more difficult to implement.

At present I don't know of any other resolution, but I'm keeping an eye on relevant discussions to see if anyone else finds a solution.


(1) Starting with the following versions (not authoritative): Firefox 1.5, Safari on OS X 10.3, Internet Explorer 7

IERI R3: Sending mail via PHP

The mail functionality included in PHP by default is pretty light. There's not much functionality for making it easy to produce e-mail messages that conform to standards. Just one example is the lack of wrapping long lines in the body. I found a function online that will format text as quoted-printable, though it had to be modified to take into account line length requirements. I think it can probably be simplified a bit, but my concern at present is making the system functionally complete ... code efficiency, scalability, and performance will need to wait for another day.

Note: There's also a function for quoted-printable encoding in the comments for the mail() function, but it also does not take into account line-length requirements.

The built-in mail() function appears to be susceptible to manipulation by user-submitted data for the purposes of SPAM or other causes (see the comments for the mail() function). While this isn't a big concern with IERI it's something that needs to be kept in mind if I plan on using this function in the future. I found some information that will provde useful in weeding out SPAM hacks such as detecting newline characters and e-mail header text.

Unfortunately the e-mail functionality I've developed based on mail() and other functions is pretty limited in scope. The PEAR project appears to have a fairly full-featured mail package. I don't think it will be necessary to install for use with IERI, however, as e-mail is not the core purpose of the utility. Unless additional functionality needs are required down the line I'll probably stick with what I've developed so far.