Trial software and registering

[Cubist at aol.com]

sez dsc at swcp.com:
>On Mar 18, 2005, at 11:07 AM, Alex Tweedly wrote:
>>> I
>>> check the creation date of the latest file as my check file for the
>>> current date and compare that against the timeout date.
>>>
>> Why is that not "vulnerable  to turning back the system clock" ?
>> If I set my system clock to a year ago, then each time I access the 
>> web, I'll create my cookie files with dates in 2004.
>
>Perhaps, that would not be vulnerable to _temporarily_ turning back the
>system clock.  It might be reasonable to check for dates lots of places
>and then assume that the current real date is the latest of those or 
>later.  One can't prove that a demo is valid, but it the assumption 
>holds then one can prove that it has expired.
   Better idea: Presuming your app uses the "standalone splash screen w/ the 
executable being a document" model, give the executable a custom property 
which *starts out* at a value of *zero*, the first time it's run. Include this 
code in the executable's stack script:

on preOpenStack
  PreOpenStuff
  ...
  CheckingTime
  ...
  OtherPreOpenStuff
end PreOpenStuff

on CheckingTime
  put the TotalTimeUsed of this stack into Fred
  add 1 to Fred
  if Fred > 600 then # or whatever number you like
    answer "I'm sorry, but this demo is expired."
    quit
    # or however you want to handle it
  end if
  set the TotalTimeUsed of this stack to Fred
  send "CheckingTime" to me in 60 seconds
end CheckingTime

   This way, the TotalTimeUsed property is an explicit record of the number 
of minutes this app has been used, so *it doesn't matter* what the user does 
with his system clock. Of course, if you copy the stack, you copy the custom 
property with it, which means copies will start out with whatever amount of 
already-used time on their "clock". This is not necessarily a good thing. Perhaps 
it might be appropriate for the preOpenStack handler to gather a bit of data on 
the hardware configuration of the machine it's running on, compare that to a 
buit of data it (the stack) has stored, and "reset the clock" if the hardware 
configuration is changed? If so, the "clock" will of course "reset" any time 
one of the relevant hardware-thingies gets upgraded... but how often does that 
happen?
   Another option: Use a textfile instead of a custom property. Check for the 
existence of the textfile; if it ain't there, you're on a 'virgin' machine, 
and start the clock running from zero. I'd suggest that you use the app's 
Preferences file for this purpose -- less heartburn all around. Have the app keep 
track of the minutes it's been in use, and have it adjust the use-number in the 
prefs file when it shuts down. If you're worries about people deliberately 
crashing the app to avoid this step, you can have it write to the Prefs file 
once every 5-10 minutes or so while in use.
   Yes, under this scheme it's likely that when the "official" time limit (10 
hours, 15 days, whatever) rolls around, the user may have used the app for 
*longer* than the "official" allotment of time -- consider what happens if the 
"clock" is incremented every 60 seconds, and the user quits 50 seconds after 
the latest such increment. My response: So what? *Who cares* if the user gets 
more than your arbitrary 10 hours' (or whatever length of time) use out of your 
app? The point of timing out your app is that the user can't continue using it 
*indefinitely*, and this scheme certainly does that.
   Hope this helps...