Encrypted HTML HELP files - useful or not?

Sun Jul 21, 2002 7:22 pm

We have a new interesting sample help file on
http://www.ec-software.com/pgm/porsche.zip (310 kb)

This sample is yet not complete. I used it to demonstrate an encrypted HTML HELP file.
What about this file?

• Please download the zip archive and unpack it.
• Open the help file - you will notice that it's a standard HTML HELP file like any other.
• Do you see the drop-down menu on the detail pages?
• If you are curious enough how this was accomplished, please right-click the topic(s) to view the source.
• What you see will perhaps surprise you.

Such a function could be used to protect the content of a HTML HELP file. In addition to a function that disables copy & paste and perhaps a password dialog before particular topics can be displayed. This all does not make sense, however, as long as the user can easily decompile a help file and view it offline. So encryption of the content is a neccessity. This encryption is not absolutely secure, but sufficiently hard to crack for an average user.

Disadvantages are:

• The compiled file is slightly larger (compression compensates most of the overhead).
• The topics load slower, because they are decrypted on the fly.
• There are several problems with JavaScripts if used in HTML topic templates.
• Full text search does not work at all.

The question is, would it make sense if we implement an encryption function for HTML HELP in the next version of Help & Manual? Is there any (and enough) demand for that? Do you see any benefits? Feedback is welcome.

Derek Grainger · Sun Jul 21, 2002 10:05 pm

Hi Alexander,

Well I consider myself paranoid, especially where ppl seeing the source of my work is involved. This is a bit far even for me, lol. Some ppl might want it, but I can't think of any particular reason to encrypt help files, I mean you can just copy and paste them anyways. This is like the switch in pdf where you can stop ppl printing the file - seems a bit pointless to me removing functionality of help files just to satisfy paranoia.

Unread post by **Tim Green** » Mon Jul 22, 2002 5:24 am

Hi Alexander,

I think I agree with Derek. The only time I can imagine wanting to encrypt a help file would be if I had developed some sort of whizz-bang code that did something special -- but even then, HTML and Java Script code always get known sooner or later anyway, they're practically open source by definition.

Apart from that I can't really think of anything. I mean, as Derek says, the text is fully visible all the time anyway...

Mon Jul 22, 2002 9:04 am

The example was not clear enough...

You can disable text selection in a HTML HELP file, so that the user cannot copy & paste the content. Furthermore, one could think of a Java script password dialog that grants only registered users access to particular topics.

This all, however, does not make sense as long as one can easily decompile the help file and view the pages with a browser.

Thomas Fritz · Unread post by **Thomas Fritz** » Fri Apr 04, 2003 9:50 am

Maybe I can provide a clearer Example:

Sometimes our Software behaves strange - Some Functions do not work on one Computer - others using the same version do not face any Problems.

So there is a list of "dirty" tricks.
e.g. Installing a new Version of Internet Explorer when occasional Errors appear or checking VxD Drivers if Blue Screens happen. Maybe the Network Adaptor has to be changed if some error messages occur.

The trobleshooting serviceman tries some of them. Of course we do not want our customers to do this alone. Too many damage can be done.
The only Tool that ist always in Place ist our Software - so why not putting this secret troubleshooting list in a secure area of the Help file?

John Smith · Unread post by **John Smith** » Sat Apr 05, 2003 2:29 am

I have to agree with Tim & Derek.

I have worried for some time that as soon as my help file is distributed to customers, they may copy and paste certain sections and send the details to competitors. Ok the encryption coupled with no text selection would stop that, but they could just send the whole file to the competitor.

There may be some way for the help file to check if our software is actually installed, but this may cause other problems.

At the end of the day, someone could easily capture a picture of the details and print it that way or use OCR software to turn it back into text. Or just send the file to someone.

In other words, with a little help from a customer, details of your software (functionality) can easily get into competitors hands. They probably only have to read your Web site to get most of the details anyway.

So if the point of encryption is just to stop plagiarism, you have to ask, how much of the text is that valuable when it details how to use a certain software application.

I never put any software source code in my help files, and any explanation on how it works is from the Users point of view. I doubt many help files are much different.

Unread post by **Tim Green** » Mon Apr 07, 2003 7:58 am

John:

Exactly. Code you protect and make inaccessible as well as you can but there's no way to protect user-readable text, that's a contradiction in terms. In fact, if you want to present anything in human readable or viewable form you have to accept that it can and will be copied. If it appears on the screen there is simply no way of preventing that. If users can read it anyone can read it, and if it's valuable making it a little more difficult (e.g. forcing the user to pull graphics screenshots instead of using text copy) isn't really worth the effort.

Also, if you want to include information for help or maintenance staff I wouldn't code it into the application or help file, I'd give them a protected link to an online site where I can update the information whenever necessary. Then I don't have valuable data sitting on thousands of users' hard disks waiting to be hacked.

Actually, I think trying to protect the information might ultimately be counterproductive anyway because you don't prevent pirates and also annoy your honest users who might want to copy sections of your documentation for their own private use, for whatever reason. It's a little like photographers who go to great lengths to prevent users from saving the examples of the work they present in their online galleries, for example with transparent GIFs covering the photos or JavaScript that switches off the right mouse button.