Password Protecting Your Help System

[kevsheehan]

Hi all,

Is anyone password protecting your help system in some way when posted on your website? If so, how? I'm new to Flare, but in my research in the help materials and on the forums it looks like the only way to do it is through the server on which you place your help system files, not through the help system files themselves.

Thanks.

[LTinker68]

Correct. Different types of servers implement password-protection in different ways, so having Flare password-protect the output means you'd have to specify your web server parameters in the Flare project and given the number of web servers, revisions of those web servers, etc., that are out there, it would make things more complicated than they need to be, especially since that type of info is generally beyond what most tech writers would understand. Plus, troubleshooting would be a pain and your IT guys would get annoyed, since the password protection isn't something they'd have control over implementing which makes it a lot tougher for them to troubleshoot.

All around, it's just a better idea, IMHO, to not implement password protection via Flare but rather the server hosting it.

I think you can password-protect PDF output, but I'm saying that from memory of the PDF target screen so I could be wrong about that (not running Flare at the moment).

[RamonS]

Do it at the server level either through .htaccess files or a server side script. Leaves the question, why do you want to password protect the help in the first place?

[kevsheehan]

I don't. But it's not up to me. This feedback helps, though. Hopefully I can convince the final decision makers that it's not worth the trouble.

[RamonS]

It usually isn't. The typical reason is to prevent unauthorized distribution. Since it is a piece of cake to download the entire help to any client PC it is entirely pointless to put password protection on it. There are some more tricks to make it more inconvenient, but the content displayed on screen can always be copied either by screen shot or with a good ol' camera. If there is documentation not intended for everyone don't put it on the web.

[ljs_tech]

Password protecting Flare-generated PDF files is not included in the Flare-PDF generating process. Not sure I'd want that as we have to edit the PDF file bookmarks afterward before locking them for delivery.

We have Flare build the PDF files, then we password protect them using Adobe Acrobat Professional. Then the 'locked' PDF files are uploaded to the server, ready for viewing when called by a link.

[kevinmcl]

It usually isn't. The typical reason is to prevent unauthorized distribution. Since it is a piece of cake to download the entire help to any client PC it is entirely pointless to put password protection on it. There are some more tricks to make it more inconvenient, but the content displayed on screen can always be copied either by screen shot or with a good ol' camera. If there is documentation not intended for everyone don't put it on the web.

This is all very true, but the point of password protection is to control who gets in.

While you can't prevent people who gain access from copying and distributing your content, there's a simple feature that could make the difference in controlling such transgressions.
If each served page got marked with an unobtrusive serial number, or perhaps a hash of the logged-in viewer's userid, then when any photos or screen-caps got distributed, there'd be a way to trace back to the culprit who either:

a) used his/her valid credentials to rip you off or

b) allowed her/his password to be observed by somebody unauthorized.

Not sure if that could be done via Flare, or if it would have to be a server function.


-k

[RamonS]

True, but fact is that the files get downloaded to the local client and then are open to manipulation. That is especially easy with HTML and PDF files as they are well-documented formats where hiding something isn't that easy. A signature can be removed, even on a screenshot. All you know (if you find out) is that someone leaked the docs and probably violated an agreement, but it no longer tells you who it is. Measures like this will slow people down, but it won't stop them.
That is why I always ask about the motivation when the "we want to password protect our help" topic comes up. In all cases I came across so far the cause is a management issue that is attempted to get fixed by technology. And there are plenty of examples that show that this is doomed to fail.

[kevinmcl]

I guess part of the issue is whether you are trying to protect in-house documents from employees that you don't trust - a managment problem, to be sure - or whether you are trying to protect trade secrets that you can't avoid placing in "limited" publication (your customers).

Non-disclosure agreements are all very well, but if somebody at customer-Y decides to raid the Help system of the product that you sold to customer-Y, and you later discover that your info has gone public, you'd like to know which of your customer companies to blame for their lax security and poor management.

In that case, it might help to have fairly large-scale differences in the generated help that you provide to each major customer.
"AHA! All the leaked pages have background of such-n-such image" or "All the leaked pages have color RxxxGyyyBzzz in these major components, where all other published versions have each a slightly different color. We now know that customer-M is the source of the leak. Quickly, fire up the lawyers!"

Likely there are holes in that scheme. But it could be a useful approach for a company with mostly large and institutional customers, and some heavy trade secrets to protect.


For retail products, don't bother. Or perhaps the "signature" hash thing would at least be a bit of a deterrent.

- k

[RamonS]

In general, whatever is put on a public facing web server will sooner or later get downloaded and (ab)used by entities not authorized. If that really is such a concern, don't put it there.