DISQUS

Imran · 1 year ago

The file attached is undownloadable. I am quite interested to see this code in action. I think you have to name the name .phps or .txt or something else for people to download the file, and not execute it like a .php file. Thanks.

billda · 1 year ago

Imran,

Thanks for saying something. The file should be good to go now. Let me know if you have any further problems.

- Bill

John Deszell · 9 months ago

Any ideas for an ASP application?

billda · 9 months ago

John I don't know ASP, but if you had access to a PHP host, you could leave
the "server" module unchanged, and you'd only have to rewrite the "client"
bit in ASP and work it into whatever final code you have...the HTTP
responses can still be understood by ASP I believe...

Niek · 9 months ago

I've been in this bussines for 6 years now and I've never met any clients who did not pay(and yes I had some major disagreements with them). It is simply a matter of doing your job well and thoroughly. When you have a disagreement with a client you settle it, like adults, not with some nifty remote killswitch trick. I find this unethical.

Assuming you've probably documented the project scope, the clients needs and you gave regular updates to them about the project on which you received feedback(you communicate clearly and regularly with them). You also will have a legal agreement/sales contact or whatsoever which states scope, deadlines, mutual expectations and prices/payment.

This will avoid any "kill switch" constructions, backdoors and unethical control of clients property(the switch will still be in placeeven when a client has paid his bills). I personally find this bad webdevelopment practice.

billda · 9 months ago

Nick,

I agree - everyone would prefer not to resort to things like this. The unfortunate reality though is that some clients don't pay - I'm glad you haven't personally experienced it.

As I mentioned in the disclaimer in the post, any and all backdoor code should be removed as soon as a client has paid his final bill, and certainly before the site goes live.

Any technical measures are a safety net in case normal methods of recourse break down.

bcamp1973 · 9 months ago

Niek, you're very naive. I've been at this twice as long as you have and guess what, one day you'll understand. No matter how brilliant you think you are at handling a client, sometimes they're just a loser and nothing you do will help. Services are withheld for lack of payment every day. Try stopping payment on your phone bill and see what happens. This is no different.

Niek · 9 months ago

Naive, maybe. I've had bussines conflicts with clients, I've had difficulties with getting my money but I still got paid within a couple of months.

I still maintain the opinion that when you do your stuff right and check your clients financial situation especially when you're talking about large amounts of money. You won't need something as unethical as this. Backdoors are bad programming practice. It's comparable to rootkits or DRM. You can't withdraw ownership from your client. It's a matter of bussiness and people skill. I'm not saying that the chances are zero to encounter lousy clients. You can always ultimately resort to legal action (that is if you have legal proof, which also helps with negotiating payment ;))

eddy was here · 9 months ago

the idea of this killswitch is pretty nifty.
Nice job.

although you'll probably have their ftp info
and can just remove the unpaid for content.

any laws/regulations on digital content that is on a clients server?
that would be interesting to read up on

Michael Little · 9 months ago

I have to admit I have often thought about implementing a "fail safe" policy like this but fortunately never really felt I had a need.

There is of course a number of obvious issues with having this sort of thing in your code:

1. Unless you "kill switch" actually removes some critical part (or all) of the application it could easily be enabled by anyone that was slightly tech-savy.

2. Implementing the "kill switch" to prevent it being enabled again could potentially leave a big security hole (there's ways around this of course).

2. If your client ever found out about the "malicious" code (whether it was used or not) it would cause massive problems.

Melbourne web design · 9 months ago

Agreed with the comments about this being unethical behaviour. If a client doesn't pay, it's probably due to bad project management, if it's not, then it's a matter for the law.

down · 9 months ago

So if your server is down for some reason, all your clients's websites are down as well, asking for payment? way the go :)

billda · 9 months ago

If you'll read in "Part One" of the tutorial, you'll notice that the code is configured such that if it does not receive a response from your server, it will default to allowing the web app to run. It has to specifically receive the "halt" signal in order to disable the app. Thus, downtime on your end does not cause downtime on the client's end.

Again I'd like to reiterate - the killswitch is a safety net in case negotiations with the client break down. You should remove it as soon as you've been paid.

trs21219 · 9 months ago

i dont personally agree with a killswitch but i understand why. what i do is i only host the site on my servers until the payment is in full. then i move it over.

on another note. the code should default to allowing the site to run if it takes too long to contact your site or the site is not available.

Dave · 9 months ago

So far I've had two instances where I had problems with the client paying me. Not because I didn't do my job well enough, not because I didn't deliver in time, but simply because said client changed his mind and demanded me to 'obey' him, or I wouldn't get my money. I have a similar piece of code (somewhat obfuscated in a file that appears and is in fact part of the rest of the website) that achieves this remote kill switch also. I normally never implement it, but for these two instances I added the code after the problems occurred, and I felt like I was going to loose the money *and* the work already delivered.

I hate to go this far, and luckily I never actually had to disable any website (the threat alone worked), but to me in these 'worst case scenarios' it makes me a feel a bit better knowing that they can't just change their FTP info and call it a day, without ever paying me.

That said, you might want to change the warning message to display a more general warning. Even though you only save this as a last resort, it would be much better if possible visitors don't see this warning of the client having to pay you (which could ruin their business), but instead show a more general, please contact support or the like message.

Oh, and it would also help to not let the code talk with your server at *every* load. Maybe do it like wordpress does it's version checks; only 2 times a day (and in wordpress' case, only the admin panel does the checks).

Thanks for the post!

-Dave

Damon · 9 months ago

(1) PHP is uncompiled. (2) the code, such as it is, would disable the site in the event that YOUR server is unreachable. Not cool, not ethical and not terribly clever, either. How about a simple DDOS attack. Much more fun to engineer, anyway. :)

Van · 9 months ago

Interesting article. In order to protect yourself you may want to look into the legal issues more closely. At the very least I would suggest modifying your EULA or services agreement. to state that for licensing purposes software will validate itself against a license server to ensure that license is valid. In the event that license is not valid software may cease to function.

Enes · 8 months ago

hahaha... that's really genius man :D
thanks for that

Rafyta · 8 months ago

@Van: That's SO slick!

Paul · 8 months ago

if the site has flash on the homepage, and top of every subpage, then you can simply have it load a swf from your server. If the swf isn't there, then nothing happens at all. If you have a client problem you can make the swf be whatever you want. It could be a link to your site, it could have a warning message, it could be just a few pixels for the client to notice.

adam · 8 months ago

I tried it, but it did not work.
The site continued to run!

seye kuyinu · 4 months ago

I think this is nice! For those who disagree with this. I believe this is just a tutorail meant to highlight some of the uses of XML RPC. And of course there are different types of clients AND THERE ARE DIFFERENT TYPES OF SERVICES THAT CAN BE RENDERED WHICH COULD MAKE THIS INVALUABLE!

Name · 2 months ago

I'm looking for a simular thing, only... I'd like to reverse it. The client 'activates' the application and than is able to use it. (The activation code is only send when the payment is done)

BTW it's pretty easy to have this 'kill switch' disabled... Just a minimal techie changes:

if (!$client->query('activation.checkapp', $appname)) {
if($client->getResponse() ) {
die("Application Disabled. Please pay your web developer.");
}
}

Into:

/*
if (!$client->query('activation.checkapp', $appname)) {
if($client->getResponse() ) {
die("Application Disabled. Please pay your web developer.");
}
}
*/

And the code for 'disabling' is changed into 'comment' and thus not executed...

Also changing the if (...) into if (false) and again it has no affect...

dedcenter · 2 months ago

Thanks! As a freelance web developer I've been looking for something like this for some time.

I've had personal experience of client's withholding payment for the full spectrum of possible reasons! In my opinion it is nice to have a kill switch option, but understand those that are worried by its ethical implications.

I've posted my approach at http://ajaxkillswitch.com

It demonstrates a VERY simple technique that takes advantage of jQuery's recently added cross-domain Ajax request functionality.

The advantage to the JavaScript Ajax kill switch is that it is independent of the server-side implementation. This makes it useful for even standard HTML websites.

Combination of the two methods (server and client-side) could be doubly effective ;)

Michael · 1 month ago

Hello, this seems usefull, but what about if the client gives de code source on his side to a developer that removes from the system the client code? Then our switch will loose the effect?
Thank you.