Topic: Secure Counter for Lisp (pay per click)

[Peter2]

I'm trying to find basic ideas for a - simple and secure - "pay per click" solution, based on Lisp.
(Yes, maybe "simple and secure" are no a combination, but an antagonism  ).

Each call of a lisp-file should increase the counter: 51, 52, 53, ...

Idea 1:
use an INI - read file - add +1 - write file
-> problem: everyone can modify the file

Idea 2:
use the INI, but decrypt the content
-> problem: everyone can remove the file (intentional or unintentional)

Idea 3:
use INI plus REG with GUID in synchronization plus decryption
-> problem: ??

At the moment this seem to be a reasonable(?) solution for "simple and secure", but if there are better ideas or better solutions I will be happy to read you comments.

[Bhull1985]

Hrm....think I've seen this done via registry modifications. That way people can't as easily modify them. Could probably find these by a search similar to "registry trial lisp code"

Additionally, couldn't you just set a global variable/use the vl-bb-set (and vl-bb-ref) to establish a counter variable, and with that established put your code into a loop. If the counter > the number of "trials" you wish to allow, then exit the loop and inform user?
If the counter < number of trials, enter main program loop.
Naturally, increment counter variable after successful run of program as opposed to upon each load/call to the program. (that way you're not jipping unexperienced users, but of course is up to you)

Hopefully one of these methods will work for you, although they seem intermediate I'm surprised you haven't mentioned them, so perhaps this isn't what you're looking for.

Only one way to find out!

[ChrisCarlson]

What's the end goal for this? Why would you waste time developing simple to break security features when that time could be spent refining the lisp and utilizing the Exchange?

[Peter2]

The goal of it is to get the number of "clicks" (= calls of a program), to store it locally and to get it every month to create a "pay-per-use invoice". This is why the value must be stored.

...to break security features ....

Sorry, I don't understand. I don't want to break security features ...??

[Bhull1985]

I think he meant that it'd be possible for someone to go into the code and edit out the counter part, perhaps?

[Peter2]

I think he meant that it'd be possible for someone to go into the code and edit out the counter part, perhaps?

Yes, of course this could be possible - to hack it and remove the counter-code and the licence-code. This is why I'm aware that "secure" is not "secure", only "not (too) simple to hack".

[Bhull1985]

what about compiling the code beforehand?

[mjfarrell]

and why on earth, pay-per click?  I think this is a poor path to choose

[Peter2]

what about compiling the code beforehand?

You mean the code of my lisp? Yes, of course it will be compiled to VLX.

and why on earth, pay-per click?  I think this is a poor path to choose

Why?

[ronjonp]

and why on earth, pay-per click?  I think this is a poor path to choose

X2 ...

[dgorsman]

Might just be a terminology issue.  There's several professional packages which have a pay-per-use system, where the user purchases a "bucket of tokens" with each use drawing a certain number of tokens.

While there are a number problems to be addressed it makes for a good thought problem.

[Peter2]

...X2 ...

? ? ?

[ronjonp]

...X2 ...

? ? ?

I would not use a pay per click service .. can't describe why .. just wouldn't.
Does not really matter though, it's just my opinion. Carry on 

[VovKa]

Idea 3:
use INI plus REG with GUID in synchronization plus decryption
-> problem: ??

http://technet.microsoft.com/en-us/sysinternals/bb896645

[Peter2]

...it's just my opinion. Carry on 

It's OK, thanks. But I don't know what "X2" means ...

http://technet.microsoft.com/en-us/sysinternals/bb896645

Yes, also http://www.nirsoft.net/utils/reg_file_from_application.html
But in combination with decryption it could be one more barricade for the 'just-to-be-curious-about'-hacker.

Better solutions are still welcome!