

Ask HN: Feelings on building a backdoor killswitch in your program? - robbiea

What is everyone's opinion on this? Do you build a backdoor into an application that you build that you can kill an application remotely even when all hosting access has been restricted?&#60;p&#62;You would use this in case a client doesn't pay the retainer, or owes you money. I've used it once and it worked to get my money, but only for one specific client that I had a feeling wasn't going to pay.
======
kls
There are specific legal implication to how this is done. For one abandon the
idea of a back door, and instead look at it in terms of licensing.

Once you do this a few thing change, first have a contract that states that
the software is on licenses to the client until final payment is received, the
final delivery of software at that point will be a patch or code-base with the
removal of licensing code. At which point the ownership of the software
copyright transfers to the client.

Now once you have done this you can approach disabling the software one of
three ways, all of which should be automatic with no human intervention. The
terms of how the software will be disabled should be spelled out in the
licensing agreement.

Path #1) set a date time bomb, either store a encrypted value in a DB table or
a file, at a certain point past the date the software time bombs and
uninstalls itself.

Path #2) Build out a licensing server, which manages licenses, this server
needs to be on your hardware and under your control. At some interval have the
software make a request to this server, and if you have terminated their
licensing, again the program aborts and uninstalls itself. You will have to
deal with the fact that for various reasons it may not be able to communicate
with your licensing server. So you will want to give the program some time
before making the decision that lack of communication means that they have
blocked access to the licensing server. Say maybe a weeks worth of failed
requests, you should also build into the licensing server, an alert, so that
if it has not received a request for a certain period it alerts you to the
issue, so you can notify the client that the requests are being blocked. Do
not build the software so that it requires response from the licensing server
to operate. It is too fragile of a solution and you will have a pissed off
client eventually.

Path #3) find a commercial licensing solution that meets your needs. I have
thought about building a SaaS web and mobile app licensing service just like
the one I described above. I am sure someone has build something similar.

The point being, you have to make it a licensing arrangement, and you have to
build out a solution that does not require you accessing their system, it has
to either be done via a licensing mechanism or via a call out to a licensing
mechanism. A company can rightful bar your access into their systems, even
their public website. If it requires you initiating access to their system to
turn the system off, you are in a bad legal area. You have to put it in the
software in the first place and notify them of the terms of the license.
Further for me personally I would notify them of no compliance to the terms of
the license well in advance of the termination.

Now with all that being said, it's far easier to just be selective in who you
work for, if you suspect that they are not going to pay then walk away. I just
did that a few months ago.

I started getting a lot of questions about progress and then changes to the
agreed upon payments based on their being uncomfortable. It's the age old
story, they add features and then are not comfortable with the progress as
laid out by the original feature set. I ended up sticking it out longer than I
should have because I did not, nor do I still believe their was malicious
intent, rather I took a client that was not educated about software
development and who refused to listen to my advice about adding features. When
they started holding back payment I walked away (it's actually a longer story
than that, my bank account was hacked at the same time too so I was in a money
crunch, but that is a story for another day). you see their lack of comfort
was putting the financial risk of the project on my shoulders, something that
I never signed up for. When you realize that you are in this situation the
only correct choice to make is to walk away. Whether intentional or out of
lack of understanding the result is the same, you are funding someone else
development with your dollar but your upside is limited as such it's a bad
proposition, you would not sign up for it at the beginning of the project so
why would you stay with the project when the terms have changed to something
that you would not initially sign up for? It is the first time in a long time
that it has happened to me, and it could have been easily avoided by me being
more selective.

------
samlev
As tempting as it might be, no. I would never do this. Not only is there an
issue about professional trust, but it's a vulnerability that you're
deliberately building into a system.

I know that it's hard, but if you suspect that a client isn't going to pay
you, don't do the job. There's no point in 1) doing the project and hoping (if
they don't pay, then you're not only not getting that money, but you're losing
time that you could have spent looking for more reliable clients), or 2)
wasting time building in vulnerabilities _and then charging the client for the
privilege_.

If you realise after you start a project that a client may not pay, talk to
them about it (in writing/email), and either cut off the project then (once
again, no point throwing more time at a bad client), or take them to court
(even just small claims court).

~~~
Tim-Boss
^ Absolutely this. You'll entirely risk losing your professional reputation,
how much work do you think you'll continue to get if people realise that
you're not only building in a vulnerability but also willing to use it if the
situation isn't 100% to you're liking!

Once you get the impression your invoice will go unpaid either take legal
action like most 'civilised' people, or just take it on the chin and walk away
(warning other developers off if you like...)!

------
ereckers
This seems to come up often here and the correct answer inevitably gravitates
towards "don't do it". I would agree. I just wouldn't feel comfortable sending
along software/application with a kill switch in it. Could you imagine what
you could be accused of if someone were to find it? Also, you'd be opening up
yourself to a huge liability if the project were of any type of size or
capable of generating any type of income. Let's say you are on a big job with
reputable people and a sane payment schedule or you're doing a website for
someone's lawn mowing service in which you can hold on to the code, either
way, there's no conceivable reason to add a kill switch.

Now, if you insist on serving that type of clientele, and providing them a
product without payment, then have fun with that. Spending any more time than
necessary devising schemes on how you're going to get lowlifes to pay you is
just the time of time suck that's going to keep you settling for that type of
client.

