NYCPHP Meetup

[Jim Hendricks]

In a PHP environment where your code is exposed,  your probably right on 
the risk.  The error is not truely an error, but an error of your own 
made to look convincing.  I've effectively used this method since I have 
free lanced, but not in a PHP environment.  The largest part of the risk 
as I see it is the discovery that the error was intentional.  Without 
access to the code, this risk is quite low.  With access to the code, 
the risk is as high as the technical skills of your client, or their 
willingness to pay to have a technical person review your code.

The timeout idea would only be useful if it is written into the 
contract, and is sufficiently spread throughout the code and based on 
encrypted/obfuscated data.  Otherwise it's a cake walk to remove from 
the code.

Jim

Keith Casey wrote:

>Jim Hendricks wrote:
>  
>
>>Errors.  Simply introduce code which 
>>once a set date is hit, cause the application to throw an error in a key 
>>area of the application.  When the customer calls to have it fixed, you 
>>say not until I receive payment for the app development, and advance 
>>payment for the estimated time to correct the "error".  Actual error 
>>correction was to remove this payment trap.
>>    
>>
>
>This is probably just semantics, but I think this is risky.
>
>It's one thing to have an "auto-expiration" but it's totally different 
>about leaving critical "errors" in the system, let alone adding them.
>
>I will go with the auto-expiration from here on out though.  ;)
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20051222/cdb301e5/attachment.html>