The Robotduck guide to protecting your shockwave movie.



There are a number of ways that your shockwave movie (your dcr file) can be copied, or appear to be embedded within another web site. This often happens with web games, as other games sites want to use your content as a means to driving visitors to their advertisments.

If your shockwave movie and the page that displays it don't have any form of protection, the owners of other web sites can simply copy the file and host it themselves. This means that you lose control of your movie (for example, you can't update or modify their copied version of the game), and more importantly, it is illegal unless you have specifically given permission. Luckily this is fairly simple to protect against in shockwave, by checking "the moviepath" - a variable in director which always contains the actual path that the movie is running from. If the movie is running in a browser, and the moviepath does not start with "http://www.your-domain.com" (or "http://your-domain.com") then you can safely assume that it's been copied to another location.

What is more problematic however - and actually more common - is for rogue sites to leave your dcr on your server, and instead use specially written html in their own web page to 'embed' your movie within their page. This makes it appear as though they are hosting it, and they entirely bypass your own html - simply referencing the url of your shockwave movie directly in their page source. This means you still get the bandwidth hit while they use your content to drive visitors to their ad banners placed around your game.

Some techniques suggest checking the external "src" parameter to prevent against this, which (as explained later) does not provide complete protection. The theory is explained here for completeness though, before moving on to more comprehensive methods of protection. Shockwave allows you to check the values of parameters within the object/embed tags of the html that is used to embed your movie. Since the rogue site will be referencing your movie from their domain, the assumption is that they will have to use a fully qualified URL in their html source, like this:

<param name="src" value="http://www.your-domain.com/yourmovie.dcr">
Therefore a basic method of preventing against this form of 'leeching' is to use the "externalParamValue" function to check the "src" param. If it starts with "http://" then the movie must be running as a 'leeched' version, because on your own site, you need only use relative URLs, like this:

<param name="src" value="yourmovie.dcr">
HOWEVER, this method is not foolproof. It is possible for a rogue site to embed your file within their html without needing to specify the absolute URL, by making use of the html <BASE> tag

. The 'base' tag allows the html author to globally specify an alternative path for relative URLs used in the page. Therefore they can use this to specify the path to your movie as the 'base' for the document, which allows them to use a relative url as their 'src' parameter. Whilst shockwave can read the values of the object/embed parameters, it has no way to read any of the rest of the html of the page in which it is embedded (nor a way of discovering the url of that page), therefore you cannot detect the use of this technique within shockwave alone - so the method of checking the 'src' param as described above is ineffective against anyone using this 'base tag' approach.

The only way to fully protect against leeching is to use some server-side scripting. This requires that you embed your movie within a php page (or other scripting language of your choice), rather than a plain html page. The server script then supplies your movie with a specially encrypted code which is generated on-the-fly, and which cannot conceivably be generated by anyone else.

The security code needs to be time-sensitive. That is, it should contain an encrypted string containing the time, and the time contained within it should be checked back with your server. If the code is too old, it means the code was probably copied from your html source by a webmaster attempting to leech your movie, and was simply hard-coded into their page. The time-sensitivity is therefore an important part of the protection!

When the game loads and receives this code via a shockwave parameter, it should send the code back to a script on your server, which can decrypt the time contained in your encrypted string. It compares the time, and if it's within a given threshold (say, one day), it gives the game the 'OK' to play. If not, the game doesn't play (and optionally redirects to your homepage!).

This is the only way to fully protect your game. Checking the moviepath is useless (does not protect against embedding). Checking the 'src' param is also useless (can be spoofed to appear to be local). If your game does not check in with a security script like this, then it CAN be embedded/stolen.

This method works on the principle that the site wishing to embed/copy your game will not have the source code of your php page, and therefore not be able to produce correct codes to embed as the Shockwave param. If they copy the current code that they see in the source of your page, it will only be valid until the time (encrypted in the code) falls beyond the 'time threshold' as defined in your script.

The particularly cunning webmaster intent on embedding your shockwave movie could have one further trick though. It would be feasibly possible for him to add some script to his own page, which requests your page from your server, extracts the code string, and then dynamically embeds that in his own page. This means each time a visitor views the game on the rogue site, the rogue site reads your original game page to fetch a valid code, but then embeds the code within their own page.

The solution to protect against this is to also embed the IP of the remote machine that requested the page, and compare with the remote IP of the machine which requests the confirmation of the code. I haven't yet seen this technique attempted by any rogue sites 'in the wild' yet. Nonetheless, it would be possible to do without this extra level of protection.

Once you've implemented this, rogue web-site owners looking to use your content without permission have their options severly restricted. All they can do now is either link to your page normally (which is usually desirable), or frame it, or pop it open in a new window. These latter two can sometimes be desirable, or sometimes be undesirable depending on your own needs or preference as to how your movie should be viewed. There are methods of ensuring your page is not framed or popped-opn though, should you want to, described below.

--------------------------------------------------------------------------

Protecting against framing

Other sites can frame your page inside their page, allowing them to display adverts around your game. To prevent this, include this JavaScript on your game page. It will 'break' the frame, and make your page fill the browser window.

<script language="JavaScript">
<!--
if ( top.location != document.location ) {
    top.location.replace(document.location);
}
// -->
</script>
--------------------------------------------------------------------------

Protecting against 'pop-opening'

Sites can pop-open your game page in a small non-resizable browser window from a link on their site, which you may not want. You can use this JavaScript on your game page to prevent it. It will close the pop-up window and instead open your game in the parent window.

<script language="JavaScript">
<!--
if (window.opener) {
    window.opener.location.replace(document.location);
    window.close();
}
// -->
</script>
--------------------------------------------------------------------------

All these techniques can be seen in action, along with links to download source code, here:
Example protected dcr movie with source code


Ben (duck_at_robotduck.com)

Robotduck 2006