Ajax Kill Switch

Update! Ajax Kill Switch Version 2 is now available.

So why would you ever require a website kill switch?

To put it bluntly, many small freelance website design businesses lose a lot of revenue due to non-payment. This is mainly due to a common personality trait – being too nice.

Similarly, companies developing novel services using valuable client-side code have very few measures of protection for those exposed elements of their application(s).

Having experimented with both scenarios, I was ripped off one too many times. I'm sure many freelance web designers and developers out there have depressingly similar stories.

The problem is that all public facing components of the modern website (HTML, CSS, JavaScript and images) are all easily stolen. The process requires only basic technical know-how.

If the flair in your design involves pure code, you are particularly vulnerable. In fact, the separation of content from design (HTML from CSS), directly benefits website thievery. It is often the case that the neatest code is easiest to steal.

The same is true of JavaScript design enhancements, a trend which is only going to increase in popularity due to the prevalence of JavaScript frameworks such as jQuery and MooTools.

Unfortunately, this makes supplying draft websites to clients a tricky proposition. You are simply trusting them not to use the demo site as a free template on which to build.

Eventually you will come across a client with the following mindset — ‘Why pay the web developer? They've just provided the code! It is unlikely that they will have the resources to stop us quietly taking it and then cutting all future contact. Yoink!’

While we cannot prevent website thievery, we can make it a lot harder…

The kill switch will take the form of cross-domain JavaScript ‘fetch-and-execute’ via jQuery.getScript();

The idea is not to prevent the code theft. Instead we shall make it very hard to use the stolen resources, similar to the idea of installing paint bombs in transported money.

The kill switch will be visible in the source, albeit served as obfuscated JavaScript.

The proposed technique is based on the following assumptions.

The client is unlikely to delve into the site's JavaScript.
If they were inclined to do so, they are unlikely to understand it.
Since we'll be serving obfuscated/compressed code, the kill switch will be hard to spot.
The client is unlikely to suspect the kill switch's presence in the first place.

If the client realises, removing the kill switch will take time and effort, costing them money.

jQuery is used here therefore the jQuery files will require inclusion. However, all that is required is the means to make a cross-domain request and subsequently execute the returned JavaScript.

The Dojo Toolkit offers a similar implementation. This functionality is often based on the JSONP technique. This removes the need for a proxy technique or other complex methods.

With jQuery taking care of the JSON implementation details, the code becomes very simple.


// Run Kill Switch Routine
//-------------------------
function k(killSwitchID) {
	$.getScript('http://yourdomain.com/' + killSwitchID + '.js');

}

Activating the kill switch is simple,

Choose a client or website ID, for example ‘myID’.
Create the JavaScript file to be requested on your server, in this case myID.js
Call the function from within your own JavaScript, referencing your chosen ID.

k(myID);

The method is non-intrusive. The end-user will not notice any difference. If the JavaScript file requested by the kill switch is not found the website will display without incident.

I personally keep this as a simple function to cut-and-paste wherever needed. The reason the function is called ‘k’ is to keep it inline with the ‘look’ of JavaScript code after the obfuscation/compression process. It makes it harder to spot.

Kill switch functionality may be enhanced in many ways, with date and time checks for example.


// Run Kill Switch Routine (between 9 - 9.30am)
//----------------------------------------------
function k(killSwitchID) {
	var time = new Date();

	if((time.getHours() == 9) && (time.getMinutes() < 30)) {
		$.getScript('http://yourdomain.com/' + killSwitchID + '.js');

	}

}

We don't want the kill switch to be active immediately. Instead, it is a good idea to delay it, giving the client some time to view the draft website legitimately.

To accomplish this, define an expiry date in the draft website's JavaScript. The final (paid for) website will be supplied with no such expiry mechanism and no kill switch.

So, what options do we now have?

Anything that you can accomplish with JavaScript (and by extension - CSS) can be done with the JavaScript loaded by the kill switch.

It doesn't necessarily have to ‘kill’ the web page. There are plenty of interesting (and fun!) options available to you.

The JavaScript-based kill switch is also particularly useful for complex JavaScript driven web applications. A new JavaScript kill switch ID could be included with every new version. This would allow previous (stolen) versions of the code to be disabled with the previously referenced kill switch JavaScript file.

With every new version of the application, the thief would have to unobfuscate the JavaScript, search for the kill switch and disable it. Every time a new feature was added, they would be working with confusing, uncommented code that was constantly problematic due to the kill switch causing issues.

The JavaScript kill switch execution file (on your server) needs to be linked with a direct path.

This ensures that if the client does indeed take the website onto a different server, it will still request the kill switch JavaScript file from our server.

These requests, in significant numbers, could result in a server performance hit. They would also be using your bandwidth. There are methods of reducing this.

Killswitch according to time of day.

Limit kill switch requests by specifying the times in which it makes the requests.

It would also stretch the effects out over the course of the day if the website in question had an international audience.

Killswitch according to random number generation.

This technique simply prevents a request for our kill switch JavaScript file being made on every page load.

A tiny amount of JavaScript is included in the local source code. This will have negligible effects on load times and bandwidth.

JavaScript execution file will be an additional download, presumably after the page has loaded. This could be accomplished with the jQuery ready(fn) (or similar) functionality.

Make the code (CSS, JavaScript) difficult to reverse engineer!

Mix the function in with other JavaScript code.
Obfuscate everything (CSS, JavaScript). The YUI Compressor is perfect for this purpose.
Inline the JavaScript, if the client is likely to just copy the HTML and only a small amount of JavaScript is used.
If you use a JavaScript library (jQuery etc.), consider placing the kill switch function at the end of its long and obfuscated source code.

Local File Check

Check for a JavaScript file in the root directory. This removes the need for a cross-domain request. This method also removes any stress from your servers if the client does move the site onto their own server.

Server-side Kill Switch

This solution, for example. Unfortunately this would not be effective if the client only stole a website's generated HTML. However, in the case where the PHP is supplied as well, this could be a useful option.

Deliberate Hotlinking

Use fixed addresses for all loaded files (images etc.), then use .htaccess rules to deny access to future hotlinkers. This will allow you to replace their images with one of your choice if they do not change the image links.

Full Encryption Services

There are a few out there, for example HTML Guardian or this solution based on JavaScript encryption. A full website encryption process is offered.

The standard performance implications are likely to apply here. Complications are also likely to arise, compatibility is already enough of a headache.

I realise that a kill switch is a somewhat drastic approach and would love to be able to assume that all clients are going to pay their bills.

However, realistically and in todays economic climate, it has become very important to make sure that potential pay is maximised.

Should the kill switch code be discovered, it would be VERY embarrassing. It is a significant breach of trust.

The code for the kill switch is very simple. The main issue comes in its legality.

It is potentially irresponsible to implement within your own website and any choice to do so is entirely at your own risk.

Try good business methods first. I am (evidently!) no expert here, so I'll redirect to better qualified freelance guides and articles instead.

If you plan to use the kill switch to enforce regular charges, it is important that a license validation mechanism is mentioned in the contract.

Something like — ‘For licensing purposes the software will validate itself against a license server. In the event that a license is not valid, software may cease to function’.

Seek legal advice if in any doubt!

About Us

Optic Swerve develop simple, intuitive web applications.

Our projects fuel the various technical articles archived on Menacing Cloud

To be notified of future articles,

We have learnt a lot from the open nature of the web development community. This is our attempt to give something back.

AJAX Kill Switch