On 03/28/2014 07:39 AM, John McKown wrote: > This has been an interesting discussion. I understand why vendors "lock" > software to specific machines and dates. Especially in the non-corporate > world. But I had another evil thought. I wonder how many z/OS system exist > which are not connected to the Internet. Not accessible to the Internet, > but can access the Internet, to do things such as software delivery such as > IBM's SMPE can do. > Evil idea: > 1) Have an execution key which encodes the valid CPUID and run date > interval (upper and lower date). > 2) If the key is good, just run - but tell the user if the key is going to > expire within 30 days, via a "nice" WTO. > 3) if the CPUID validates, but the date is expired: > 3.1) IP connect to support site to log key expiration and then run > normally. Don't tell the user anything. > 3.2) if you can't connect to the support site & the key expiration is less > than 31 days, issue a strong warning via a WTO. > 3.3) if you can't connect to the support site & the key expiration is > greater than 30 days, refuse to run. > 4) if the CPUID is invalid & the program _can_ IP connect to the vendor > site. > 4.1) Use GeoIP to validate the incoming IP's country of origin. > 4.1.1) If in a "good" country, allow software to run. Vendor documents and > sues user's company. > 4.1.2) if in a "bad" country, execute "nasty user" code (see below) > 5) if the CPUID is invalid & the program cannot IP connect to the vendor > site, execute "nasty user" code. > > Nasty user code: Write some code which burns some CPU, the amount to burn > would need to be something that the nasty user would expect. Then go > through a fairly long chain of branches (to complicate branch tracing), and > finally abend with an S0C4-4 trying to overlay low core. If the user is > indeed a "thief", then what is the likelihood that they will have an expert > which could resolve this problem? And they can't call your support because > that would give them away. > > Evil quotient: too little; just right; too extreme. > I seem to recall a case where the vendor wanted to change contract terms at renewal in a way that was unacceptable to our corporate management and it took several months of negotiations past the formal expiration of license between our lawyers and theirs before a renewal agreement was finally reached. We had been a customer for at least a decade, had other products from the vendor, and it was clear it was in both party's interest that some agreement would eventually be reached; but we lived on temporary keys for several months. Any sort of automated validation system would have to be flexible enough to allow for unusual cases like this.
-- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
