Prevent users from copying content

[Jan]

How do I prevent users from copying and pasting content from the WebHelp output into other software? Of course, it's copyrighted material but how can I be sure someone cannot do the above?

[Nita Beck]

I don't know of any way that one can prevent someone from copying from a web page, whether in a WebHelp system or a common web site. It's the operating system that allows copying and pasting.

In the distant past, it used to be that WinHelp could include a copyright notice so that the copied from and pasted elsewhere content would be accompanied by a copyright notice. Maybe there's a way of attaching a "copyright stamp" of some sort to material copied from WebHelp, though I've never heard of it. Perhaps the experts on the forum can offer better insight.

[NorthEast]

You can disable aspects of the broswer functionality using scripts (e.g. disable the right-click menu), so there may be a way to disable copy and paste.
It's probably worth having a look in google.

However, I don't think these techniques are foolproof; there are most likely to be ways round them if someone really wants to copy the content.

[RamonS]

Disabling copy & paste won't do anything against screen shots, which when of decent quality can be edited, printed, and scanned. Let's say you publish the content in print, how would you go against copyright infringements? You'd need to first become aware of the infringement, find the person who copied the content, take them to court, and get an injunction or a verdict for damages. Same thing applies to web content.

This question comes up every other month and my comments are roughly the same. You are likely trying to fix a management problem with technology, which often enough doesn't work and sometimes just gives the illusion that it does (such as preventing copy & paste). In order to give some better advice it would be interesting to know why exactly you want to prevent copy and paste in the first place. Also, keep in mind that preventing copying content may collide with fair use rights. I agree that the courts are all wishy-washy about this, but quoting copyrighted material for example for a scientific study report is typically accepted practice given that the source is fully disclosed. This may or may not apply to your content.

My guess is that there is a better solution and adding tricked out tech gadgets is just taking cannons to shoot at the wrong sparrows.

[Andrew]

If there is a contractual or legal reason you must disable copying, I'm pretty sure it's possible to do using JavaScript (there may be other ways, too). A simply google search will reveal methods. Of course, as RamonS noted, none of the methods is foolproof -- if you can see it, you can capture it and copy it.

However, unless one of those two reasons apply, it's probably not worth the effort, or the amount you will piss off your users who have legitimate reasons to copy information (for example, they want to create an internal procedure guide, and they want to start with your document's content rather than retyping or starting at zero).

[LTinker68]

One thing you could do is make a watermark, at least when the content is being printed. You could make a graphic with faint gray text with your company name in it, then use set that graphic as the background image for the body tag in your print medium. You'll probably want to have it repeat the image, so you might want to have some extra white in your graphic around the text so the watermark doesn't end up having a close wallpaper effect. Maybe make the image 3" x 3" or something like that. That won't save you from screen captures, unless you also add the watermark to your default medium for online outputs.

[doc_guy]

You have to remember that when somebody views something on the internet, they only do so because that content was downloaded ONTO the computer they are using. That content has been transferred from the server to the user's computer. There is no effective method to prevent all users from being able to something with the content that has been downloaded. Somebody will be able to find a way to take that content and do something with it. If it is finding the text in a cached location, taking a screen shot and feeding that into an OCR program, or some other technique, your content is not safe as soon as you post it on a Web server. It is a simple reality we face as content providers. But, in essence, it's not that different than if they have a hard printed copy. They scan it into their computer and use OCR software to copy the text. If somebody is determined enough, it is easy to get around the text copying restrictions.

So you have a balance here: do I try to prevent the malicious users? If you try, you'll fail for the truly malicious ones, and you'll just make it more difficult to use for the non-malicious ones. Or, do you not bother? If you don't do anything, the truly malicious ones will still have access (no functional difference there), but you will make life easier for your non-malicious, general users who are just trying to get something done.

I have yet to see a really good argument for adding content protection scripts to web pages. In most cases, it doesn't stop the determined ones, and while it may prevent casual misuse of your content, you risk alienating and frustrating the very users who you are trying to help.

[RamonS]

Aside from that, any scripting would need to be a client side script. Nothing is easier than downloading the page source and removing the script. As mentioned before, it is chasing after something with technology that does not have a technology solution.

[LTinker68]

Of course, if the user has scripting disabled on their browser then the blocking of the right-click may not even work. And if disabling the scripting blocks the entire page from being displayed, then it's an even greater disservice to your customers. And they might not even want to turn on scripting just for your help, because they might be worried about what scripting you have in your help.

[Madcap Guru]

There is a technote on how to stop someone from copying an image

http://kb.madcapsoftware.com/Content/Fl ... loaded.htm

[QBF]

People should be aware that there are customers who do not allow scripting in the help systems they receive. I realize this is not an issue for most writers, but these customers exists, such as certain "Government customers" that will not accept any added scripting of any kind.

[RamonS]

I don't allow scripting in my browser and only selectively turn it on. Works like a charm with NoScript.

[QBF]

I don't allow scripting in my browser and only selectively turn it on. Works like a charm with NoScript.

To clarify, there are customers that will not allow adding any scripting to the help in the first place, not just turning off scripting on the client side. Just something a "small" number of tech writers have to deal with, but it is something those writers need to keep in mind when creating help for that particular customer base.

[RamonS]

I didn't disagree, I think having scripting turned off is way more common than we might expect. I think client-side scripting is a bad idea to begin with, but there are some advantages.

[Andrew]

People should be aware that there are customers who do not allow scripting in the help systems they receive. I realize this is not an issue for most writers, but these customers exists, such as certain "Government customers" that will not accept any added scripting of any kind.

Er, if they don't allow client-side scripting, then WebHelp is pretty much out, isn't it? It's a whole lot of JavaScript glue for xml and xhtml topics, right?

[QBF]

People should be aware that there are customers who do not allow scripting in the help systems they receive. I realize this is not an issue for most writers, but these customers exists, such as certain "Government customers" that will not accept any added scripting of any kind.

Er, if they don't allow client-side scripting, then WebHelp is pretty much out, isn't it? It's a whole lot of JavaScript glue for xml and xhtml topics, right?

If you read carefully, I said no "added" scripting. My comments were meant for the very, very few writers who work with a very specific customer base. My comments do not pertain to anyone ouside this highly specialized category. If you worked in this area you would understand.

[Andrew]

Ah, I had interpreted "added" to mean added to the xhtml at all, rather than added to the WebHelp output. Clearly, I do not work with the sorts of customers you are talking about.

[GaryUK]

I managed to stop pasting of text by adding the following to the body in the master page:

<body oncopy="return false" oncut="return false" onpaste="return false">

The right-click copy option still appears but when you paste, nothing happens. I haven't figured out how to do it with diagrams because I don't think you can do it with styles.
This also works for HTML help (CHM) - text and images.
PDF targets have options for copy and paste protection on the PDF Options tab

As several people point out, they'll always find some way to copy, but no sense in making it easy.

[RamonS]

And that fails entirely when a user opens the source of the page loaded, copies the source, removes what you added and then saves the file out again. There are also plenty of crawlers that download the entire set of files. A multi-file find and replace takes the stuff you added out within a minute. After knowing why the copy & paste fails reworking your help to be copy & paste enables takes a few minutes of work.

This issue comes up with regularity and there is nothing that cannot be somewhat easily circumvented that will keep those who are determined to copy the content of the help. Consider anything in the help "public" and do not add anything that is not "public". If someone wants to get the content and distribute it, they will do just that with less or more effort. If you do not want that to happen, do not publish the content in the help file.