Authentication/Authorisation system
-
Ok, the ever thorny question. Les start out with this:
We all agree that ANY and ALL authentication and authorisation systems are breakable, and anything in HISE (either in the core of the product or in some developers javascript code) is breakable.
Now the first contentious statement;
Even if an authentication/authorisation system is breakable it ISNT therefore pointless to add one in.
Here's my experience. I've released Kontakt instruments for a long time, if they have no authorisation system in them then someone buys the instrument - and immediately uploads it on to a warez site. For a moderately advertised and marketed product this usually happens in about 10 days of launch and the number of sales for the product "fall off a cliff". however...
If the product has even a simplistic authentication system included(that is trivial to break for any "competent" pirate) then this "10 days to warez" doesnt happen, what you get instead is more like "100 days to warez", so it takes the intervention of a "proper" warez pirate to do some "simple" cracking, and those guys have a queue of stuff they are stealing and any (small developer, lower profile) product wont be on top of the list. When the product shows up on the warez site after 100 days then again sales suffer. But here's the point - MOST products get MOST sales in the first 3 months (90 days) so getting pirated is still bad, but not as bad.
So why all this explanation? Well Kontakt has no mechanism for storing keys/email addresses/whatever IN the saved instrument - you have to save them in an easily readable/hackable external file(well there is a way but its clunky..and not so reliable).
So what would be nice in HISE is a simple API call to hold some value INTERNALLY to the compiled VSTi/app etc. and then leave all that validation fluff to the developer.
-
I second every statement you made about copy protection. IMHO the golden path between security and annoying your customers is a simple license key system which prevents casual piracy to prevent the most stupid people without any cracking skills to upload it on torrents. From then on it gets hard and quickly turns into a cat and mice game you can't win so your time is better spent creating new products or improve the old ones or go play soccer.
Adding this to the scripting API is not necessary because HISE already has a license key system which follows exactly this scheme (a license key with machine ID identification and user / email). It is basically finished, but not tested in a real world scenario.
I need a little more time to figure out the new business model / license scheme, but this will have casual piracy prevention covered. Contact me over PM if you want more information.
-
Christoph,
Thanks, all good news - as usual. I dont need this stuff yet so I can hang off until I do or until you document what you have.
