Trial software and registering

[Frank D. Engel, Jr.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

When the app starts up, store the current time and date.  Then the next 
time the app starts up, compare the current time and date with the one 
you stored.  If the current time and date is before the stored one, 
chances are someone is trying to trick the software.

On Mar 18, 2005, at 8:29 PM, Cubist at aol.com wrote:

> 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...
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
- -----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCPtpq7aqtWrR9cZoRAt6tAJ43gaX/QPMqHR7jGBZMCOZRWMR98ACfZh3G
tgt9tflT9C11Wn+d+0HgXSA=
=7k7g
-----END PGP SIGNATURE-----



___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com