Hi All,

I have developed a FMP 8 solution for a client and now my client wants to sell this product on to their clients (with me taking royalties from this...so ok by me!!!)...so im about to put it in to a runtime solution...so the costs are kept down i.e no need to purchase FMP...

Problem i have...some of My clients, clients 'work together'.

My client wants to sell the solution as a 1 user license with an activation code so that once the solution is bought by 1 of their clients they cant just copy it to one of their collegues computers and start using it.

i.e. buy it once and pass it around to others to use free of charge!

How can i get it so a unique activation license is entered but if this were to be passed to 'Another' persons computer they would NOT be able to use it without buying a new activation code?

My thought would be to on 1st run a script enter hardware address in a hardware global field...and then on each startup there after it checks hardware address of computer against hardware global field...

What do you think?

Hope i've explained it ok?!

I use a mixture of the User Name and the disk serial # that I encrypt using David McKee's free encryption plugin. The plugin can return the disk serial #. Link

Ray Cologon also has an add-in (not a plugin in the true sense), that will prevent copying.

Steve

Also, see FMWebSchool, as I think he also offers something called FM Lock. Link

Edited July 3, 200619 yr by Guest

I'm in the same boat. I'm looking at Install Factory. http://www.installfactory.com/

FM Lock looks interesting, but I'm not sure it prevents users from handing off their CD to a friend. It seems to only prevent them from copying an "installed and opened at least once" database.

Edited July 7, 200619 yr by Guest

Though I am a novice, I would advise: whatever the solution you use, preventing a user from being able to install the product on more than one computer is not necessarily a good Idea...

An example (upon many possibilities) If the user purchases one copy and buys a new computer afterwards, he should be able to use it. If he is unable to install it on his new machine, he will either be unsatisfied and never buy the updates or future versions or else, he will call you to get support. In the first case, you lose a customer, and in the second, you need a lot of customer technical support only for accounts management...

What I am planning to do with my product (that I hope I am going to get done someday!) is letting the users copy the filemaker solution as they wish. As long as they do not modify it and sell it as their own, I think it is ok. In fact, it's free publicity!

I would only need to make sure that only those who paid for the product can get customer support.

Those who have not paid for my product will have the choice to be unsatisfied (who cares, they did not pay!) or buy the product.

It is possible to achieve this with the accounts management that come with FileMaker. The only thing you need is to find a way to encrypt customer information into a code, deliver this code to the customer with an account name. Of course, he can copy the software and give his code and username to everyone he wants, but those will never get support, as by then, I will have found a way to determine if the person who tries to get support matches the one whose informations are encrypted in the activation code...

What do you think?

Are the products mentionned here based on this principle? Or do they actually prevent a user from using one copy on more than one computer?

Thanks

Edited July 13, 200619 yr by Guest

I agree. But I still haven't seen a good way "to encrypt customer information into a code, deliver this code to the customer with an account name".

What would you think of that: If he pays by credit card, then you can easyly encrypt his card number... gotta be careful of course, and why not warning him that his credit card number is encrypted in the code? this way, do you think he would take care before sharing his code to anyone? That's an idea... I wonder if it's legal though.

I'm sure it's possible to encrypt customer data, from the data he gives when he purchases... I will have to think about it...

...Maybe it's even more simple: my phone and TV company just asks me my birthdate and Invoice ID to make sure that it's me talking to them when I ask for service. They probably don't even have to mess with code encryption that much.

Boy, you are generous. Users being users will freely install software that they haven't paid for, customer support or no customer support. Besides, if the product is a well-written one it shouldn't require much support.

Microsoft uses an encrypted combination of the user name and various pieces of the hardware mashed together (like part of the disk's serial #).

If your product is lower cost then it probably doesn't pay to use a complex algorithm (maybe none at all), but when you start getting into the $100s per copy, it's worth the effort.

Nothing is bullet proof, and I'd bet someone like Comment is clever enough to find a work around, but I know I can defeat all but a really small # of users.

Steve

I think the problem is not WHAT to encrypt, but HOW to decrypt. Ideally, this would work like a digital signature, with the public key stored permanently in the solution, and the activation code being the message to authenticate.

Unfortunately, the calculations involved in this seem very complex. I don't even know what they are, as most sites that explain this stuff solve this part by "download this code and include it in your application" (and it seems like the code itself makes calls to the OS built-in functions).

I am no hacker, but thanks for the compliment anyway. Microsoft is the model to follow - IF you want your clients to love you like they do Microsoft.

AHAHAHHAHHAHAHAHAHA, comment you crack me up - and what about those of us who really do "love" microsoft?

What i was thinking in terms of encryption was the following:

You have a "Product ID" which identifies each piece of your software uniquely. You then use whichever plugin gets the hard drive serial number and send both off encrypted with a simple algorithm - nothing amazing, maybe just mix n match. Basically, it get's sent off to your server, and deconstructs the product ID and harddrive ID - sends back a Serial Number that will allow the solution to work with the Hard Drive in question - and store for future reference both the product ID and the Hard Drive Serial that requested it.

Then, if someone tries to request a serial key off a different hard drive, it simply sends again to the server - cross checks what was registered the previous time (I.e check both HD serial and product code) And if there is a discrepancy you have them call support - otherwise, they probably freak out and abandon what they are trying to do.

I have no love for Microsoft, quite the contrary. And I feel the same about Filemaker. Personally, I think both companies are slobs, and produce bug-ridden, incomplete feature sets.

However, more companies have adopted similar techniques to prevent illegal copying of their code. Users may not appreciate it, but protecting intellectual property rights is a developer's perogative. You can always choose to make users very happy...give your software away for free.

Steve

protecting intellectual property rights is a developer's perogative

I agree. But it is the user's prerogative to change the hard drive or the computer. As s user, I don't feel comfortable depending on the software provider being there when it happens. That's true when the software is bought from a big company, and doubly true when bought from an independent developer.

If you don't feel comfortable that the company is going to be there (large or small), why buy the software to begin with??? And I'd bet that you have plugins written by a small company that you depend on (like Troi). You're being a little hypocritical, aren't you?

I give users a guarantee that they can get all of their data out of my solution in CSV format so they can move it wherever they want.

Steve

Actually, you would lose that bet. And I do resent being called names. As for your first question - I really don't know what to say to that.

Sorry to have hurt your feelings (was not my intention). Are you telling me that you don't use any plugins? That you only buy software from large companies?

Steve

Let's not make this about me, OK? All I am saying that what works for you (and Microsoft) does not necessarily work for everyone, or for every situation.

Obviously, software protection is a balance between efforts and risks. Possibly, if I were to sell a $10,000 solution to someone (I wish...), I might tell them that they will need me when they change their hardware. Possibly, I might lose the deal on the grounds that they can't depend on me not being run over by a bus. Or maybe not, if the next available alternative cost $100,000. It all depends on the particular circumstances.

ADDENDUM:

Unless you know in advance your user's hard disk #, how do you prevent a fresh installation from the installer?

Edited July 13, 200619 yr by Guest

Sorry, Comment but this is about you. You're the one that's making these broad statements.

Steve

What broad statements?

Aravanah said that "preventing a user from being able to install the product on more than one computer is not necessarily a good Idea..."

I said that I agree, but I don't know of a good alternative. That's about the scope of my statements in this thread.

---

if the product is a well-written one it shouldn't require much support.

---

Man! You probably don't have the same kind of customers as I do... you can't imagine how stupid (sorry, should have said 'basic') and numerous the customer's requests are! I sometimes wonder if they had any idea of the use they'd make of the product when they bought it (ok, I exagerate)

And, about your love feelings... what do you mean you feel the same about filemaker? Do you know any other application that can deploy database applications as easily as Filemaker? 'cause I'm interested!

Okay, you people all over-react. You guys are telling me you don't sell $10,000 solutions every other day?

Darno, welcome to the forums, and in terms of your customer issue - you have to make your support line clear. You offer support for all issues relating to inherent fault in the software you have created - should you deem the question not to relate to an inherent fault in your software - you charge for the call - it's pretty straight forward.

In terms of the company being there - If it goes through the protection regeme, it is likely not going anywhere.

Again, my opinion only... Also, no one says that you HAVE to be there, and your server algorithms could be more complex - i.e. allow one change of hard drive every other month - the end user wouldn't know - or simply send alerts to you if this ever happens so you can follow up on it. You dont HAVE to restrict the install itself.

Secondly, as far as i'm concerned this protection is only needed for runtime files - where the user sets their own details etc. Multi user files etc. can be controlled from the FMS end - sell per license base.

Regarding the "being hit by a bus" issue that comment brought up - this is a serious issue that has to be considered, this data is invaluable to organisations - and he's right, you simply cannot afford to be the only one with this password and hope that you can maybe scratch it into the front of the bus on impact - if your business has more than 2 people, the answer is pretty simple - tell them it - they work with you anyway.

And if you haven't made them sign confidentiallity agreements as a standard on employment well... i just don't know what to say.

Unfortunately, I do have customers that are dumber than a brick. And I have dealt with bricks for more than 35 years (while I don't like to admit it, I was one of the first to chisel code in stone). I should point out that my solution is a single-user runtime, which colors how I look at support versus you guys in a multi-user, server corporate environment.

For a really good way of minimizing handholding, see TechSmith's 'Camtasia' product.

Filemaker is just plain sloppy. Do you really believe that they couldn't have completed the Tab Widget so that we could have designated a default tab? Now we're left with the good probability of leaving a tab in the wrong position and not knowing about it until a user complains. How long did it take them to finish the debugger? Now, I guess we could mark this up to them wanting to sell more upgrades, but I choose do think they're incredibly sloppy.

I'll give them their due: Version 8 was overall a terrific improvement. However, leaving PDF's out of runtimes, the poor incomplete implementation of custom menus reinforces my point.

That does not mean that I don't like the software.

Comment: I don't want to start an argument, but you said:

As a user, I don't feel comfortable depending on the software provider being there when it happens. That's true when the software is bought from a big company, and doubly true when bought from an independent developer.

I was just trying to point out that most of us use plugins written by small companies...you may not be comfortable, but you still do it (well maybe not you, but tell me how you get along without dialog and file plugins...I'd love to know)

Steve

So I did. Why is that a broad statement? It's merely an illustration why "preventing a user from being able to install the product on more than one computer is not necessarily a good idea".

It seems to me you are the one who broadened it into "you only buy software from large companies". I never said that. I have applications that have been moved over to a new computer 5 times, and they still work. The point is I didn't need to contact the provider to move them over. There's a difference between buying a chair and marrying the carpenter.

OK, you win...I give.

Steve

Well, as i said, charging for the phone calls is a disensentive for people to call you until they've read the help manual. I can't say much, i've only got 80 users so far - but nevertheless.

In terms of the camtasia product - i use frontcam - does the job.

Never heard of Frontcam...will look into it. Do you know any comparisons?

Steve

Looks a little simplistic compared to Camtasia (also is a lot cheaper). Latest version is 2 years old. Go to www.techsmith.com to see the differences.

Steve

Meh, i had the license for front cam lying around - but your right, this does look good, cheers steve.

~Genx

Here's another way you can go. I think it's the PERFECT solution, but you be the judge.

It's called 'Copyminder'. I use it in my runtime solution and it works extremely well.

The way it works is that it encrypts the .exe file. Then, whenever the user runs the application, Copyminder checks to see if this is a valid installation. If it is, no problem, if it isn't it flags the installation and watches it more closely. Depending on the setting you use, you can have that installation disabled, either temporarily or permanently.

Users should have access to the internet, but it isn't absolutely necessary. Also, while accessing the internet seems like a EULA violation for a FM runtime, it actually isn't since Copyminder does the accessing, and since it dosn't actually pass any data on to the runtime.

The result is that you are perfectly protected in all situations. If someone gives away their copy you will know about it, and the "giver" runs the risk of having their copy disabled by Copyminder. Instead, they should download a new copy of the FM Runtime. When they do, they are required to register, which means you know who they are. And if they give faulty data, you can immediately disable that copy of your runtime.

Also, if the user needs to move their runtime solution to another computer (ie. hard drive crash), that isn't a problem either. Finally, there is no additional coding required on your part.

Their solution is extremely well thoughtout and effective.

Visit www.Copyminder.com. The company that runs it (Microcosm) has been doing software security since the 1980's. They're also very good to work with.

This may be THE most dynamic, flexible yet strongest security solution out there.

Edited July 14, 200619 yr by Guest

Filemaker is a cross-platform application, so anything that is Windows-only is far from perfect.

Comment, while you may consider it unusual, I only sell runtimes that are PC based, as the demand for Macs is non-existent in my market so Copyminder might be just fine.

Steve

Edited July 14, 200619 yr by Guest

It does look interesting, but there's no conversion from pounds to US $$.

Steve

I guess I see a difference between "perfect" and "perfect for Steve".

Comment, you're just plain irritating.

Steve

Just as a general note, my market too has very little use of mac's - hence i don't distribute to them at this point - but mainly because i use a lot of cmd line functions and a couple of third party programs that are windows compatible only - though i am still looking at trying to get this thing out on mac.

Hi Genx:

While I can understand you wanting to move to a Mac, look at WinBatch in the meantime. It will give you a whole new bag of tricks...stuff that would be difficult or impossible to automate with Filemaker or VBScript. Link

Steve

[color:blue]Moderator's Comment:

Comment, you're just plain irritating.

[color:blue]Steve,

Whether or not the above words were posted in jest, I'm afraid they are *really* not appropriate for the Forums.

Please stay on topic. This site is all about FileMaker and not at all about individuals. Personal remarks and observations - particularly those that could be interpreted negatively - have no place here.

[color:#ffffff].

I'll have a look at it Steve.

Cheers

Depending on the nature of the application, you can simply hard code certain client information into the database, making it effectively useable only for that client. I'll be selling a runtime online within the next few months and I intend on having paying clients provide me with a name that will appear on the invoices that are generated from the database. I'll hard code it into the build and zip it up for the client to download.

The downside: a bit of work on my part for every sale / client may have to wait a few hours

The upside: the client can give the system to someone else to look at, but they won't really USE it

The downside, should you ever offer upgrades and or / bug fixes, you are going to have generate a new file for every single one of your clients.

Either way, i honestly suggest you reconsider that at this point - you may be getting yourself into trouble - to much customization per client is to much unpaid effort on your part.

Also, if your extremely desperate to do something this way, you could just give them a program, but also send them a text file that is simply encoded - really simply encoded using char numbers or something - just not human readable.

Then simply get the run time to parse this info in if it's never been parsed before. That way you don't have to compile seperate zip files for every single one of your clients.

Edited July 19, 200619 yr by Guest

I just spent the last few days working on this problem for distribution of my own runtime. Maybe my solution will be of help to others - and then maybe someone will come up with a fault in my logic but here goes.

Issue a fully functional demo file with no hard coded data so anyone can use it as a demo or indeed pass it on to others to use also.

Once installed on their machine, on first use store the date, the time and machine name and set the 'days left to run' field to 30 (or whatever).

On each subsequent use count the appropriate number of days down thereby allowing them the 'dem' period and also check that they have not altered the machine clock/date. If so lock them out..

Before the end of the dem period they have to hand over their money in order to get an activation code off you so that they can continue using your masterpiece .

When they hand over the money they also give you what they think is the 'in-built' demonstration activation code (there really isn't one - in the absence of a 'real' activation code it is just going to run for the dem period then just stop).

What they are giving you is in fact a code that your software has generated on their machine and which encodes the first used date & time to personalise this code to their installation. You then re-encode it some other way and give it back to them.

That way the code you supply them with will only apply to an installation that was first run at a given time and on a given date. It isn't perhaps unique but the chances of someone passing on a code to someone who happens to have run the thing for the first time at exactly the same moment must be low enough not to count.

I also include other details in the code that they give back to me such as version no. of the software and revision no and scramble it all up so it looks all official-like.

So there you have the bare bones of it. I can issue demo discs that anyone can use yet they end up with a personalised code that not anyone can use. I have my money. I also have feedback as to who is using which version and where (if you hard coded each demo disc with a few alts to the code you could even trace them as they moved around)

The only drawback is that if they copied the installed file and gave it to someone then they could use the same code. That is where the machine name comes in.

In the event that someone tries to use the solution on a different machine it issues a warning then reverts to demo mode thereby allowing legitimate users the opportunity to come on to you and get another code and allowing none legitimate users the opportunity to hand over some money.

I realise that this is far from a perfect solution and would not be satisfactory for everybody but it does mean that at least you can put up a fight against piracy without resorting to any third parties.

I would appreciate anyones comments on this because I am well aware that there may be a fatal flaw in all of this and I just haven't seen it yet

Regards

Phil

Edited July 19, 200619 yr by Guest

to much customization per client is to much unpaid effort on your part.

I've got applescripts that do the majority of the work for me, but you are right, sell enough copies and any extra work required per sale becomes onerous.

I still think though, that having a set company name (in a solution that prints such things) is a viable way to prevent unwanted duplication of the solution. It's quite possible to allow them to enter the company name when they set up their preferences for the first time and THEN lock it down.

Edited July 19, 200619 yr by Guest

I would have to agree that this seems to work for me. Heres some of the things that are in my solutions and make theft a problem for other companies, (i know not everyone deals with companies)... and i know most of this is not useful for a clean downloaded file ... but may be useful if your install code tests against some of the unchangeable data.

The solution has user logins and on purchasing the buyer/licensee sets themselves with an admin account and password which only allows them to edit the main preferences. I suggest the director do this as it will give them the control over employees access (keep it simple to administrate as they often hate computers too, and they may end up giving the job and code away to other employees)... i find most directors/CEOs are pretty paranoid about there data so this usually works.

The company name is set and unchangable. The software is licenced to there company for its administration so if they start a new company they should buy a new package in my opinion.

Labels include a return address with the company name (which can't be removed), this means that labels to mailing addresses where people have moved get returned. Which is great for them to keep there mailing list up to date and also causes problems for anyone stealing a mailing list as they can't change the company name on the labels.

This works well but does not stop people exporting the data and mail merging it and this has to be possible as quite a few people need to export to send to mailing houses ... you can always add an admin export script password known only to the administrator as they will probably wish to protect from exporting anyway, but its not perfect as directors don't often like to do this kind of job.

Invoices contain the company name and Tax/Vat registration number this can also be set only once and is unlikely to change (in my experience once people have one reg number and it stays the same).

Invoice numbers increment and are not editable and invoice records can also not be deleted only cancelled which is a problem for any potential thief and is also a deterant for anyone thinking about giving a solution to another as this is often sensitive info and will deter the licensee from this kind of action.

Delete all records is not an option in any part of the database making getting the database empty after its been used a problem.

To be quite honest though most people i work with always want some kind of data imported when they buy a solution and it usually comes from a messy excel spreadsheet or crappy solution which is why they want something new, so i find it hard to not have a 1 on 1. (would be great if i could automate everything...am getting closer every day, week, year)

If you are in that kind of situation you may aswell hardcode some stuff like a waking great company logo at startup ... thats pretty imbarrasing for any corporate thief!

I also find people want to take copies around on laptops so hard coding the system into the thing to make it unmovable is asking for trouble, (although i suppose you could set an expiry date on these kind of moved files).

If a system fails most companies will want their solution up and running again on another machine within a couple of hours, therefore they have to move the backups to another location. Hardcoding the system is not a solution and makes a mockery of any backups.

Would be great if you could set part of the install code from filemaker server as if you moved systems presumably most would reinstall the same filemaker server too (of course filemaker server would have to log a list of codes as any upgrade codes would screw this, oh and if your client opted for upgrades a couple of years down the line with a fresh set of filemaker full versions (not upgrades) you'd be screwed again)... sorry streaming thoughts. ... infact forget this last idea as your thief probably stole filemaker too!!!

Some of these things may be of help some people ...

Stuart

Edited September 1, 200619 yr by Guest

I am using a little software to distribute my Windows Runtime solution. Check this out.

www.exeshield.com

I have been using this software for the past 3 years. During the runtime compilation, strip off the admin access permanently so that people can't copy your software design code. Hope this help dev that need to distribute their software.

Stuart T

Some good ideas.

I also favour clever techniques that limit and/or lock out the solution rather than over-hard-coding ideas that assume that your client (a) wont move address ( upgrade their computers © employ only sensible employees with perfect computer skills and (d) has malicious intentions.

In my solution I also have a single "Admin" access account that's set once on registration. Of course it's not full-access (that's wiped on creation of the runtime) but it's nevertheless as much as I dare grant.

I have also created an access level system using the limiting capability of the Accounts. For example, in Demo mode a specific field is set to Zero, in Registered mode it is set to 1, Enhanced mode it is set to 2 and so on. This way layouts, scripts, and the ability to create, modify or delete record can be limited using the formula

not <> >0.

i.e. user must be registered

not <> >1.

i.e. user must be registered to Enhanced level or whatever you wish to call it.

Registration could be complex and hard coded that it will decrypt the username and company from it. As suggested a nonsense text file would work well. And also mean that unlocking a file means having someone else name plastered over the solution, a further deterent.

I also include several "integrity checks" in the startup and shutdown scripts that include :

Checking that the solution is being opened in a runtime, else quitting.

Checking the solution is running on Mac, else quitting.

Checking the status of Registration and if in doubt i.e. possible tampered, reset to Demo mode.

Presence of Demo mode triggers additonal limits on necessary fields (than those enabled via the Accounts options mentioned above) and annoying messages Solution wide.

I also recommended setting the menu options to editing only or none. That way record creation and deletion can be controlled and monitored via scripts that in turn can have limits set on them when in Demo mode for example...

Here is a database that I have used in the past to create a unique registration number. The attached database creates a 24 digit registration code based upon the client's name and modification date.

Here is how it works....

You create a registration layout (similar to the one in the attached database) with a company name and six registration entry fields. These six entry fields will be where the customer enters their registration code. You will have to create a script that will check what they enter with the registration code that the attached database creates.

When your program is copied to the hard drive and executed for the first time, a script (that you need to write) creates a single record in the registration database. The customer then types in their company name and makes a note of the modification date that you display on the layout. The customer sends you the company name and the modification date.

You then type in their information to generate their code and you send the code to them. And since this code is created by the same calculation that is in their copy of the database/product, the code that you send will match the code that was generated on their end. After you send them the code, they will then type it into six fields. Once the six fields match the hidden six fields that contain the registration numbers, a calculation field is set to "Registered".

Then, the next time they start the program, a script checks to see if this calculation field is set to "Registered". You would then also need to set an expiration date for the script to check. If the product hasn't been registered within 14 days of the registration modification date, then the program will quit. You should set this expiration date to be a global variable - and use a script to set the value versus a calculation - otherwise they could just create a new registration page which would push the expiration date out further.

The attached database is "your copy" that you use to create a unique registration code, using the company name and modification date that the customer provided.

The calculation field takes the modification date and company name and substitutes various strings for each letter/number in both. It then produces a string of 4-digit codes that you can use for your registration code.

The code is dependent upon the user typing in their company name, as that is how the code is generated. If you are worried about someone copying your database and giving it to a friend, the formula uses the modification date on the registration layout in the formula, and that produces a different first four characters for the code. You could also incorporate the modification time, or serial number based upon a date or day of the year, etc. in case you are worried that someone will copy it on the same day.

In this example, Apple Computer has registered three different times, with three different dates. Each of the registration codes are now different, as the first four characters are driven from the registration date.

And, you can change this formula around to create different codes - just be sure to copy the same formula to your product/database before shipping it to your client.

Tony D.

registration_code.fp7.zip

I don't get how it works?

What you have uploaded is a good version of what I have seen elsewhere and even commercially. More importantly, it is not a painful plug-in and is easily to impliment.

I both like and dislike the idea of coding the de-coding parts in to the solution. I like it because it is a one-off effort, i.e. many, many codes work for just one set of scripts but then the flaw could be if someone actually figures out HOW the code is being translated and/or validated. Obviously the more complicated the code is and the more steps that are required the better. But still there is the inherent danger that a good hacker will get your file and be able to find the decryption routine.

There is also the "problem" of using the computers serial number, or MAC address, or even IP address. It allows for the hacker to easily begin to track the activation code sequence.

I strongly like the idea of client and developer interaction, in a similar way that responding to one or two emails can be required for activation of a forum account. I think this aspect warrants further development, perhaps involving the transmission of a small "activation" file from client to developer that the developer returns that enables something in the main solution.

I still have not got my head around joining the two problems of activation and how to solve them in one secure step;

1) How do you turn a demo solution in to a full one securely?

2) How do you transmit the ability to activate the solution to the client, but render that activation inoperable to anyone else?

My head hurts.

I still have not got my head around joining the two problems of activation and how to solve them in one secure step;

1) How do you turn a demo solution in to a full one securely?

2) How do you transmit the ability to activate the solution to the client, but render that activation inoperable to anyone else?

And there the problem lies

I think the security forum should be split up... or at least when discussing security each of these should have an equal footing and be discussed seperately or addressed as seperate and equally valid issue.

1. Securing the data extraction and invalid script triggering of a solutions by an unauthorised person (hacker)

2. Securing the data from access by users any level of access from gaining access to data above their level.

3. Securing the solution from illegal distribution and modification both in terms of licences and intellectual property.

1 = attack

2 = user

3 = developer

(of course a user may be an attacker)

just my thoughts.

I agree - although a two-way split should be quite sufficient, I think:

1. Protecting the users' data;

2. Protecting the developer's intellectual property.