Should I include a selfdestruct-method to my applications?

Question

I recently had a negative experience, where client bailed from the bill, but my middle-man already uploaded our software and design to the clients server. Client turned out be a known criminal, and of course he changed all possible passwords of the server.

However, I can still access the admin-panel of the CMS. Sadly it turns out, that my software is very secure.. Tried to SQL-injection, fake the image-upload etc etc. However, I cannot hack my own software.. Anyways, I preparing to sue this person, so that is not the problem.. I'm just thinking now, that maybe there should be some backend selfdestruct-method. So, if similar case occur, I have the option to kill the software.

My own idea is to hide some function in the core files. Encode it with base64, so it wouldn't be obvious. So something like this:

eval(base64_decode('ZWNobyAnSGVsbG8gd29ybGQhJzs=')); // echo 'Hello world!';

And basically make a small script, that takes all the software's files, chmod's them to be sure and then deletes them.
My newer versions of the CMS, all have filemanagers that I could use for easier hacking. But what if the access to the admin-panel is limited.

To be very clear, this is meant only for the development-stage software's, in my personal server or the clients server (last part being the ethically questionable.) So if my client should steal my software.. This wont be included inside a commercial-software.
And to be even more clear, we are talking about those rare freelance jobs. I think its fairly logical, that contract-work doesn't need such methods. So we are talking about those jumprisk-clients, only in development mode -- when the project is ready, then obviously this would be a very very unethical backdoor to have inside your software.

1. Ethically is this a good idea? (Keeping in mind, that obviously I will remove it, when project has been 100% and everything is paid for)
2. Have you guys ever had to hack your own software, because of similar issues with the client(s)?
3. Any recommendations on this idea, code and method wise?
4. What may be the possible drawbacks or repercussions of selfdestruct-scripts?

My conclusion on this

Is a little bit sad, that all answers were targeted on the contracted cases. It was my fault really, that I didn't make it more clear in my question.. just thought, that it is fairly clear, that there is no point in the kill-switch.. when you are protected by the contract.
However, if you are doing a contract work.. then this should be stated in the contract -- this makes it legal, even inside the clients own server. However, having kill-switches inside my own personal server is really nobodies business (this is what I really wanted to know.)

I decided to make the kill-switch script for my CMS. Mainly, because it seems an interesting challenge. But also, that I could use this for my non-contracted works where the client is a friend of a friend of a friend.. I probably wont use this on the clients server, but..for the cases, where the client or some middlemen have access to my server .. And my software gets stolen, or "moved without my knowledge", then I don't get paid and they cut the access to the software.

I have read trough alot of topics here, where they recommend to send a warning and then take down the page. Well, I saw a problem in it, as when Im dealing with a person.. who will just copy it to somewhere else (maybe re-brand it and sell it) and tells me, that it has been taken down. And also, I wouldn't "turn the site off", but delete it. Though, I guess its still illegal to access my clients server and to delete it. Or at-least, access it trough backend and not from the FTP. For this I thank all of you, who answered.

Answer 1

I'm not a lawyer. It sounds like you already have one for the purposes of suing your client; while you have him or her on retainer I would recommend getting their advice on this.

There are some other questions on this site that deal with "kill switches" and other ways to disable software for which the developer has not received compensation. It is usually considered a bad idea to simply build one in to "turnkey" software (where you will develop it and then transfer full rights to the client), without the contract having stipulated this possibility.

First off, if your contract does not specifically state that you can disable the software for non-payment, or that the client does not have any rights to the software until payment is received in full, then you cannot flip any "kill switch" without being in breach of contract. Absent any words to the contrary, "possession is nine-tenths of the law", so it's his software once he is given possession, and to destroy it would be akin to dynamiting a new office building you'd built for him if he didn't pay for it.

The second point follows; any contract you offer to any client should have a clause to the effect of: "Intellectual property transfers on satisfaction of contract". That means that even if you have given him a copy of the software to use, until he's paid you in full, he doesn't own it. This WOULD give you the right to disable his or any copy of the software for any reason until full payment has been received, because it's still yours and you can do as you please. Now, he's breached the contract, and you haven't, so the case is MUCH easier for your lawyer to present, and meanwhile your client doesn't get any benefit from his ill-gotten goods.

The analogy to a building contractor holds: once a building under construction is able to be secured against unlawful entry, it is, and the contractor will generally keep all copies of all keys to the premises until the work is complete and signed off on, and payment received in full. Even after the keys are handed over, if payment falls through he can attach a lien on the property and in the extreme have it repossessed. The same holds true here; you may give the client a key to get into the software, but you hold the "master" key, and he doesn't get administrative access until you're paid in full. If he can get in now, and doesn't pay you, you can just "change the locks" and lock him out of the software.

However, you have given your client the "master" key to the software, and he's gone and changed all the locks so now YOU can't get in. That's not the way it should work. You can still claim damages, but in the meantime your crooked client can use the software, copy it elsewhere (that's a big thing that can't happen to a contractor; if he takes his building back he doesn't have to worry that you've made an exact free copy on another lot), etc etc. Basically, your only remedy is to enforce payment in full, because you cannot guarantee that you have reclaimed all copies of the software. You probably wouldn't be happy getting your software back even if you could guarantee he had no further copies; it's likely custom work you can't just turn around and sell to someone else.

Understand that regardless of your rights to the software, his data belongs to him. You cannot touch it. You can stop his access to the software that you built, but if you destroy his data, that's like burning his possessions after repoing the building you built him that he didn't pay for. You have no right whatsoever to that data, and must either leave it in place on his computer intact, or if the data cannot be accessed in a reasonable manner without your software, you must remove it from the entanglement with your software and give it to him in a useable format (such as a human-consumable database, or printed or electronic copies).

Answer 2

In concept you are right. Your execution is all wrong.

You need to provide him trial licences that expires. Upon full payment give him the Final "forever" licence. All upfront and honest.

Answer 3

No. If your clients found out you would be lynched. It's not at all secure. Someone, some how will find out how to trigger it and then suddenly you have the task of contacting all your clients to tell them about it and why they have to do an emergency patch.

If you do hack it you are also opening yourself up to criminal proceedings. I assume you have proof you still own the site? That you have the right to access it? The cost to his business could be "astronomical"

There are acceptable alternatives. Put a watermark on the site, so every page displays a message. On payment you can remove the watermark.

Answer 4

This seems like a phenomenally bad idea that could potentially land you in jail.

1. It's unethical. Bad behavior of your client doesn't make it right for you to hack their system.
2. It's illegal. This has happened before, with bad outcomes for the offending parties.
3. It's pointless. What would you possibly do with this backdoor that wouldn't get you in trouble? Would you blackmail the client?
4. It's dumb. Even if you could do this without getting caught, the potential risks far outweigh any possible gain.

Answer 5

Please don't ask programmers, ask a lawyer. I would imagine at the least you would want to include a clause in your contract saying you have a right to do what your question contemplates doing. (Doesn't the "irreparable harm" clause of some contracts let you get a court order to shut down the software immediately until the court has a chance to sort it out?) I think a court order would be lot safer for you than a code bomb (which could be considered criminal, if a court found you didn't own the software it could be destruction of property, in the U.S. it might possibly fall under the breaking digital encryption sections of the Digital Millennium Act, etc. I could imagine winning damages in civil court and still being convicted in criminal court).

The rules will vary depending on where you and your client live and operate, so I really think you would want a lawyer.

Answer 6

Ethically is this a good idea?

Absolutely not. Not only does it make you look unprofessional to honest, upstanding clients, but I feel that it's also detrimental to the profession as a whole. Software engineers do have a responsibilities to their client or employer, including delivering software that is of the highest quality. Should there be a dispute over payment or contracts, there are appropriate channels. Reducing the quality of your software is not an appropriate channel.

Have you guys ever had to hack your own software, because of similar issues with the client(s)?

Never, although I have never done contract or freelance work. I've always been an employee of a larger organization (which, in some cases, was working under a contract). To me, the thought is unthinkable. I would rather deliver software that I'm proud to have my name attributed to and get cheated by a small percentage of customers than reduce the quality of my software as well as my ethical responsibilities to the users of the system.

Any recommendations on this idea, code and method wise?

Don't do it.

What may be the possible drawbacks or repercussions of selfdestruct-scripts?

Besides the obvious ethical issues, I'd be worried about legal problems. I'm not sure if sabotaging your own work is legal, and even if it is, using such an exploit might not be.

Answer 7

Just implement a licensing module with time limited licenses that will disable the software on expiry. This is a well known practice in software industry and your clients should not object to it, as you will remove the limitation afterwards.

This might also come in handy, when you want to limit features and offer different versions of your product.

Kill switches just have way too many risks and are not worth it.

Answer 8

A secret self-destruct feature is a horrendous idea. Yes, you'll be clever and may have the opportunity to stick it to an awful client in the future, but its way more trouble than its worth.

1. You still won't get paid for work you've done. Yes the other person won't use your code; but you'll still suffer lack of payment. You think some criminal will decide to pay the person who's already brought down their site once remotely? They'll find some new chump to make their site for free.

2. Utilizing the self-destruct sequence, makes you liable for your own legal problems. Depending on jurisdictions, you could easily be seen as hacking/destroying their data (when they were about to pay and had plenty of extenuating circumstances for why they didn't pay earlier). Even if you aren't convicted/successfully sued, you still may mount hefty legal fees and have much more trouble than its worth.

3. What if some good paying client browses your code later (or has a CS friend who just browsed it to do a minor tweak), sees the function with weird base64 part, is like what's this, tries executing it, and accidentally deletes the web app (and does it while you're on vacation so it takes a while to fix)? Or posts a bunch of public reviews about you everywhere stating you are unethical and leave backdoors in your work? Sure you may remove it from the finished product after they pay, but with VCS they may browse older source or not want you on their server after they paid (and that would be an awkward conversation; yes I need an account again, cause I haven't removed the secret self-destruct backdoor).

4. What if the criminal backups their data? You delete their webserver with a secret backdoor, the site is offline for a day or two while they (or a friend) finds the offending function backdoor function and its back online.

In the future, get people to sign a simple contract, pay you in stages, and don't let code leave the development server and computer that only you control until you've been paid. (If they need it to be live before all the work is finished; make sure they've at roughly paid for the fraction of code that's becoming live). If they want to see the work as its under development, have them give you a few IP addresses which you'll open your firewall for your develolopment server (and maybe with a clever CNAME to the effect of unpaid_work_in_development.example.com). Give no guarantees of uptime of your dev server, and if you are getting way more traffic than you should be (e.g., you find they are redirect lots of people to your site) just close off the firewall until they pay. If they need to contribute content to your webserver, make them either email you with the content suggestions, or create an dropbox shared folder for them that only has permissions to write to the small subset of files (under VCS control outside of dropbox) that they can meaningfully contribute to (e.g., html templates).

Answer 9

You've asked the wrong question. The thing to work on and improve is not to add some sort of remote kill switch (adding a vulnerability that you or someone else can use), but to fix your real problem, which was a poor way of arranging for payment and delivery. Sounds like you needed a better escrow system (or whatever such a concept is called where you live).

Don't waste your time on a kill-switch, figure out where you screwed up in the business deal part of it.

Answer 10

I think I would devise some kind of licensing mechanism. This could be based on any number of commercial or home brewed ideas and could cause the software to stop working after the license has expired. At the point the system is accepted by the client and they have paid you can provide a full license that does not expire.

This approach also needs approval from a lawyer in your territory but has the advantage that you do not need to remote disable the software and you can stipulate that this is part of the system before hand. However it seems very sad to me that you are dealing with people who refuse to pay in the first place.

Answer 11

Isn’t this called DRM? As long as you remove the “bomb” upon receiving payment I see no legal problem with it. Just make sure you have a patch readily available to cover your ass and show that you didn’t have malicious intent.

It reminds me of the ‘poison pill’ provision in some companies’ articles of incorporation which are activated in the event of a hostile takeover.

To wit, the mentality expressed by some of the other posters here reminds me of why some programmers get stepped on all the time. If more people put such bombs in their code I think programmers might get paid more promptly... I would have absolutely no problem if this were the norm. People love to steal other people’s hard work. Period. And if Apple, et al. can DRM the hell out of their stuff, then I think freelance programmers can too...

Answer 12

On a practical note, surely the client would check their logs, find the kill request, restore the code from a backup, remove the kill switch and re-deploy.

Answer 13

The details of your question make it clear that this would be an absolutely horrible idea. The first client to discover such a kill switch (possibly after you use it and they recover from a backup) would publish the kill switch and the fact that you had included it in code you delivered to them. Your reputation would then be completely destroyed.

And before you say "well, they'd be a deadbeat, how will they destroy my reputation?" Consider a scenario like this: The customer is in good standing, but one of their employees takes a copy of the code. They fire that employee, he looks at the code, figures out the kill switch, and uses it. Guess who gets the blame? (Hint: It's you.)