[ultramundane8]

So let's say that the customer always pays on time and the developer did build this sort of time bomb. (And let's assume no technical knowledge on the part of the customer. Therefore, the time bomb is never discovered.)

Are you saying that the relationship was negatively affected?

I would claim that the developer could mistrust the customer without elsewhere mistreating them.

[jessaustin]

Intentionally increasing the attack surface of the product you deliver is not ethical. It's unlikely any developer in the situation you describe has tested the time bomb functionality well enough to exclude the possibility that an attacker could exploit it, either before or after the payment date or the cancellation patch. An aspect of the Hippocratic Oath applies here.

The case described in TFA seems better, since the developer retained possession of legitimate control mechanisms, and used those in technically legitimate ways. (That is, updating the content and functionality served at a URL is a legitimate activity that occurs regularly.) In effect he's more of an unpaid service provider than an unpaid IT contractor in this case. No one would expect their phone to keep working without paying the phone bill, and until he turns over control of the site he should be expected to use that control. It's not like he's using a backdoor here.

[npsimons]

There are way, way, way too many ways for this to go wrong. What if you are indisposed (in the hospital, dead, etc) when it comes time to apply the patch? What if an attacker finds the security hole and exploits it before you apply the patch? And don't tell me this isn't a security hole (eg, a backdoor), because it could easily be or become one. Knowingly delivering compromised software is flat out unethical and borders on vigilantism and/or fraud. I don't condone one party failing to hold up their end of the deal when the other party has, and I don't think that "defacing" a website that someone doesn't legally own (they haven't paid for it) is wrong, but putting time bombs in software should never be done.

[koenigdavidmj]

This seems much the same as a DRM mechanism on a single-player game that requires a live network connection to phone home to the server. In either case, you have software refusing to function unless its creator gives approval. The only difference is that this is known to the player of the game.

[ultramundane8]

My post was a little more geared towards disputing that the work relationship is doomed if the customer and developer can't trust each other.

I had no intention of endorsing a time bomb approach, but just continued on that theme theoretically.

I thought I had expressed that through the sequence of my statements (assuming a possible case then showing that it is at odds with the trust assertion), but will try to be clearer in the future.

I definitely think there are some good replies to the actual practice of installing a time bomb, especially from pragmatism.

[greaterweb]

My point is such that a "time bomb" of sorts would not be necessitated if the developer makes sufficient efforts to protect him/herself with good business practices.

That same client who pays on time and upholds his end of the agreement is left at risk through no fault of his own. Just doesn't seem fair in my opinion.

Will a dispute happen even with well authored contracts and business plans? Absolutely, but properly scoping the work, delivering to a schedule and keeping open communication with the client will greatly minimize that risk.

[codegeek]

"let's assume no technical knowledge on the part of the customer. Therefore, the time bomb is never discovered"

That is a big assumption to make. Just because the customer is not technical does not necessarily mean that time bomb could not be discovered at some point in future. Probability might be low but you can never be 100% sure.