Security considerations when using the INSERT method
Encrypted images
Encrypted images are the most secure because if there is an error
on the page due to a user trying to circumvent protection then the
image more than likely will not display. Also encrypted images cannot
be retrieved from cache and re-used.
General page content
With any encrypted image on a web page all media and text displayed
on that web page is also protected from copy and capture. While that
content is not as secure as the encrypted image, the method of using
a small CopySafe Web image on any page to protect generic content
is referred to as the CopySafe Web Insert technique.
CopySafe Web Insert
While a CopySafe Web Insert page is displayed in the user’s browsers
it is most secure, that is until a user tries to foil protection.
However there are measures that can be taken to eliminate the following
threats: o Use of User-agent masking add-ons to impersonate a different
web browser type
- Trying to capture page content before the CopySafe plugin is activated
- Trying to disable CopySafe after the page has loaded
Use of User-agent masking add-ons to impersonate a different web
browser type
Note: that this only affects security where the CopySafe Web Insert
method has been used. There are many add-ons available for Firefox
and one of them enables a user to set a different User-Agent to that
of the browser being used. For example a user could set Firefox to
pose as Internet Explorer and if the IE plugin is installed, then
they may not be redirected but while on the page without a plugin
active they may be able to capture and save.
Extra detection functions have since been added to csi.js to prevent
this phenomenon but it requires some extra care… you must make sure
that the head tag includes an ID tag otherwise you will get a JavaScript
error and all protection will fail. On the top of your page the following
tag should read…
<head id="csHtml">
Note that the "csHtml" is case sensitive, and that care is to be taken
with <!DOCTYPE> statements because it may negate the ID . If
a DOCTYPE statement is to be used try this one:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Trying to capture page content before the CopySafe plugin is activated
Note: that this only affects security where the CopySafe Web Insert
method. The same layer functions as described below cater for this
phenomenon.
Trying to disable CopySafe after the page has loaded
Note: that this only affects security where the CopySafe Web Insert
method has been used and the visitor is using a Mozilla web browser,
ie: Firefox/Netscape/Chrome clones. By allowing a page to load and
then going into Tools > Add-ons, the plugin can be disabled leaving
the page media and text exposed.
Extra detection functions have since been included and templates (insert
examples) are provided for use where you want to use the CopySafe
Web Insert method. Any media that is not a CopySafe Web encrypted
image can be displayed in a layer that only displays when triggered
by the plugin (when properly loaded). Additional script functions
detect the users mouse and keyboard strokes, and any actions that
can be used to access browser settings will trigger the layer to disappear.
Some problems may be encountered with browser clones (inferior copycat
browsers derived from Internet Explorer or Firefox resources). Google
Chrome for example is notorious for complaining about everything including
JavaScript to CSS and may crash when the layer detects change of focus.
Luckily Chrome is not a suspect where add-on nobbling is concerned
and if you need to support this very much over-rated browser (only
by Google of course) then you may want to add code to exclude Chrome
from focus/blur detection.
Exploits provided by popular web browsers
Well known web browsers like IE, Chrome and Firefox have always tried
to be as popular with the public as possible by providing everything
that they want, including the means to exploit the web and download/save
anything displayed on web pages. Consequently, any plugin solution
dependent on "popular" web browsers will never be properly
secure. Over the years people wanting to protect web content have
endured from lack of proper plugin support to quirks intended simply
to evade detection and even disable protection solutions.
Today all web browsers provide an Add-on Manager that can enable and
disable any browser plugin and the latest hurdle for us all if having
to enable each plugin every time a page loads. Your web site visitors
will more than likely not know about such things and if they are using
IE11 or later they will be left up the creek without a paddle because
since IE11 Microsoft decided that it was all too difficult and simply
banned the use of ActiveX plugins in the browser space.
Best solution for a secure web browser
From your CSI settings file you can select which types of web browser
can access your protected pages. So if your network uses IE10 and
you like the extra protection applied to IE then you can allow IE
only. Or if you are tired of Chrome's lack of support for most things,
then you can remove it from the list of approved browsers.
But if you really want to secure your web pages, then you can set
your CSI to only allow the ArtistScope Web
Browser. |
|