Protecting Webpages

05 June 2004

Introduction

Some people feel that when they create a webpage users should not be able to see anything except the final rendered page. Usually this comes from a desire to prevent other people from using either the HTML code or images on their own site. Sometimes the desire is to stop visitors from taking the textual content, or occasionally even prevent printing of the document.

Due to the nature of the world wide web, it is impossible to do this. For the browser to render it, the browser must receive it, and if the browser can receive it, then the user can get access to it.

Technological Techniques That Don't Work

There are a number of techniques that authors use in attempts to prevent visitors from gaining access to the HTML source or the images.

Blocking the Right-Click

A favourite technique is to interfere with the browsers context menu. The idea is that if the user can't get to the context menu, they also can't get to the View Source or Save Image As options.

This has side effects, as there are other functions on the context menu that visitors find useful, the bookmarking feature for example. Authors considering using such a script should ask themselves if they really want to make it harder for visitors to bookmark their page.

This doesn't work for two reasons:

There are ways to access the source, or save images other then the context menu
If a user disables JavaScript, the blocking fails

There are two types of scripts in popular use (among those who try to stop people accessing images or source).

Alert!

Scripts which display an alert (often with a copyright notice) introduce further problems. Users accustomed to using the context menu will repeatedly trigger the alert, requiring them to move the pointer to the alert box and click 'OK' each time. This very quickly becomes frustrating

Block!

Scripts which silently block the context menu are possibly worse. Users may not immediately realise why clicking the right mouse button does nothing. This leads to confusion and frustration.

In a similar vain, and usually used in combination with, blocking the context menu, some authors try to stop visitors from viewing the source by opening a new browser window without the menubar.

Guess what? Its ineffective.

For a start, some user agents won't get to see the page. Popup blocking, and lack of JavaScript can both stop the window from opening. So say goodbye to search engine positions.

Those users who do see the page can still get at the menu. Depending on the configuration and browser tapping Ctrl+N (or a different key combo) may open a new browser window, at the current page, with all the usual menus. Alternatively users can look at the source code of the opener page, and copy/paste the URL in to their address bar.

Encrypting the Source

By encoding the HTML in JavaScript, some authors attempt to make it unreadable to visitors who View Source. They also make it unreadable to user agents without JavaScript enabled – including GoogleBot and other search engine indexing robots (so they sacrifice most hope of appearing in a search engine).

Unlike the previous techniques, source code encryption is difficult, so there are a number of commercial `solutions'. However, like context interference it is ineffective and has side effects.

In order for the browser to display the webpage, it has to be able to read the source. If the browser is to be able to read the source, it has to be able to decrypt it. In order to decrypt it, it has to receive the key. If the browser can get the key, the visitor can the key. If the visitor can get the key, the visitor can decode the source.

That might sound complicated, but it isn't. The two most common techniques are rather easy.

Textarea

Browsers ignore HTML tags (except </textarea>) inside a <textarea>. By saving the page locally, and then editing the source to include a <textarea> around the entire page, users can open the new page and copy/paste the entire source from inside the <textarea>.

DOM Inspector

Even easier is the use of the Mozilla DOM Inspector. A user only has to open the page in the DOM inspector, then use the context menu to copy the HTML tree. Then it can be pasted into a text editor. It takes about five seconds.

Cover up

The cover up technique to make it harder to visitors to take copies of images is quite clever. The author sets the image to be displayed as a background image, and then places it under a transparent image of the same dimensions.

This may fool some people (who save the transparent image when they try to use the context Save Image As feature), but isn't effective overall - there are other ways to save images.

Saving Images

A number of techniques have been outlined that authors use to interfere when users try to save images, but there are some things that authors can not do anything about. Users can take screenshots, save the entire page (including images), or look in the browser cache. Some systems allow users to drag and drop images from webpages to local file folders.

Methods That Do Work

Hopefully this article has successfully pointed out that there are no technological solutions to the problem of protecting images and source code. That doesn't mean that there is nothing to be done. Psychological and legal solutions do exist.

Copyright Law

Within those jurisdictions that are signatories of the Bern Convention (at least), when somebody creates something, they automatically own the copyright (until (if) they decide to give it away or sell it). Copyright provides certain legal protections.

When it comes to images, a digital watermark can be added. This won't change the appearance of the image, but can aid in proving who created it. It can also aid in locating other websites which use the image.

Unattractive to Thieves

Another option is to make images unattractive to thieves. Either by using a low quality image, or splashing a visible watermark (possibly containing the name of the website) over the image.