

Remote Kill Switch - Make Sure You Get Paid - karipatila
http://www.billda.com/php-remote-kill-switch

======
RiderOfGiraffes
IANAL:

Be warned, although this may be morally justified, and very tempting, it may
also be illegal. A similar situation might be that you could feel morally
justified in putting a trap in your house while you are away, but it is
illegal to do so.

~~~
hga
Yeah, in most areas the law dislikes "self-help" as it is termed
(<http://en.wikipedia.org/wiki/Self-help_%28law%29>).

There's US case law on this particular area; I vaguely remember that it's not
totally opposed to the idea but in general it is.

------
captk
Bill here - I wrote the article linked above and designed this kill switch.

It's been helpful to me several times when I've had trouble collecting from
clients, but I only use it as a last resort. There's a pretty good comment
thread on the post debating the ethics of the matter.

Also Acid_bath - I recognize what you're saying about validating over HTTP. It
would not be acceptable for all my clients' sites to go down if my validation
server goes down. That's why my code is configured to only disable a site if
it is able to explicitly retrieve a KILL signal. No response from my server is
interpreted as a lack of KILL signal, thus the site stays up.

------
seven
Sorry, but this reads to me like: 'If you hire me, I will backdoor my code! Do
not trust me!'

~~~
acid_bath
Not that I'd do this, but I can at least see the appeal. Just about everyone
who wasn't a "big name" that I've contracted for has dicked me in some way.
Demanding more work before payment, or dropping off the face of the earth, or
"suddenly realized" that 100 hours of work at $100/hr is going to be $10,000,
etc.

I realize both parties are taking a risk that the other won't deliver, but
once a project is done the situation is heavily in the favor of the person who
hires the contractor. At that point the employer has everything they want and
the contractor has nothing (or maybe some up-front cost). A method for being
able to "un-deliver" or "repo" an un-paid-for product would have been useful
to me many times. But un-like a car or house, I can't just take it back.

That being said I'd be paranoid that something would accidentally trigger the
validation mechanism. Any time it validates over HTTP there's a chance the
server won't make a connection for various reasons, and then you look like an
ass.

~~~
seven
"Not that I'd do this, but I can at least see the appeal." I think everybody
does. Me too, but still this is sending out the wrong message and could fire
back.

If the client is not able to provide me with a certain level of trust, I will
not work for her. In case the situation is fishy... like me having this
strange feeling that the client is not as trustworthy as she seems, I invoice
early and often. It is way more easy to bill five times for 2k, then to ask
for 10k at once.

Quoting myself from another thread: When I have a new customer, I tell her
that I will send an invoice after a few (10-20) hours of work. She will learn
very early what results I can produce in those few hours and whether she likes
working with me. I learn very early about her the willingness to pay. I then
do my invoicing based on the results of that first test.

Usually I invoice my customers once per month. Some only, if they 'used' 50+
hours. It is all about trust. One customer wants an detailed explanation for
every hour in the invoice, so I invoice often. Makes it way more easy for me
to get my money. Another customer is very relaxed and just pays what I tell
him. I invoice him twice a year.

You are very right about being paranoid that the trigger could misbehave
somehow. Code contains bugs. Less code less bugs.

