4 ms·
No to be harsh, but this is largely useless. The biggest issues with in-app licensing is (1) Binding licensing to the machine (or the user!) (2) Making sure
by huhtenberg 7y ago
No to be harsh, but this is largely useless.
The biggest issues with in-app licensing is
(1) Binding licensing to the machine (or the user!)
(2) Making sure that your licensing check can't be NOP'ed by a l33r haxxor within 5 minutes of the release.
Tangential to that is (3) which is an ability to tolerate minor changed to the machine and OS reinstalls without invalidating the license.
(1) and (3) aren't hard to solve, just need to decide which machine/OS properties a license should be to "latched on". Popular choices are MACs, HDD serials (from the ATA IDENTIFY block), SMBIOS IDs, MachineGuid on Windows, etc. Better yet, it's not a bad idea to bind to a _set_ of machine properties and then tolerate a change of _some_.
(2) is a domain of its own. Basically that's an anti-reverse-engineering task. It's not terribly hard to roll out something on your own, but you do need to know what typical hacks look like. From exe patching to process training / API hooking, there is a substantial learning curve, but it's a quite interesting one.
That is the biggest part of any "license key verification" is not the actual "license key verification", but rather all the nuances that make sure it actually works as designed and doesn't affect users' experience in normal-use cases.
- looping__lui 7y agoNot sure whether I would agree that (1) and (3) aren’t hard. I recommend checking out LimeLM with the blogs and the (very informative!) forum. Weirdly enough I would rank “make sure that the Antivirus software solutions do not go randomly crazy on your software protection” rather high (despite certificates and whitelisting). So I would wholeheartedly agree with your summary statement :-)
- rsp1984 7y agoTrue, but note that in many cases the goal is not absolute security but rather making it as inconvenient as possible for someone to circumvent the licensing. In some cases the licensing security is even weak by design, e.g. Windows 95 or the early AutoCAD. This is desirable when the size of the userbase itself is of value (which is actually true for a lot of software!).
- huhtenberg 7y agoCases like W95 and Photoshop are exceptional edge cases that worked for them as a part of a very aggressive marketing push with a very long-term market domination goal. It doesn't apply to ISV products that need to feed their devs right now. If you add licensing enforcement into your program, making it trivially breakable is just... dumb. At the very least it will pollute the heck out of native search results with all the hacked versions, because THAT will in fact be the more relevant search for a lot of people. Secondly, people won't bother actually buying a license if a hacked version works. It's a very persistent urban legend that allowing easy hacks is good for adoption, but it's a legend indeed. Making products less easily hackable results in massive increase in sales.
- danenania 7y agoIt depends a lot on where your revenue comes from. If it comes from large businesses, realistically they aren’t likely to pirate since it’s a legal risk to them and a hassle compared to just buying the thing. In that case, some token DRM could be enough.
- bscphil 7y ago> If it comes from large businesses, realistically they aren’t likely to pirate since it’s a legal risk to them In that case, wouldn't a "free for personal use" license be sufficient? I know some software Oracle's VirtualBox, for example, implement something like this and it must work for them because they come down hard on supposed violators.
- danenania 7y agoYes, that could work, though I think if you make it too easy for people to use it for free, then many will do so just as the path of least resistance, at least until you make an issue of it. Just putting some kind of minor barrier in the way is enough to make paying the easier option, and it doesn't require any monitoring or enforcement.
- nexuist 7y agoI really believe this is why SaaS is such a dominating business model now. Software licensing failed because it is technically impossible, and no amount of clever tricks will save you from determined groups / individuals. If it runs on your machine, you will be able to get it to run again without the licensing requirements. We saw large companies get pwned time and time again. On the other hand, there is no way you can see what a SaaS backend is doing and replicate that locally. Sure, you can rip off the frontend, but that's just a thin client over the API anyways. The API is the proprietary product, and much easier to secure. Even if a blackhat breaks into your SaaS repository and leaks your source code (which is generally a freak event, especially among businesses that take cybersec seriously) - what are your customers supposed to do with that? I wouldn't expect your average AirTable customer to be able to understand how to launch and maintain an AirTable instance. It's just a better idea to serve your product over the Web. If you sell native applications, you can't expect to make as much money as SaaS equivalents.
- jfkebwjsbx 7y agoThis is not true for business applications and many customer ones. Enterprises cannot risk legal problems. And home customers will buy licenses if price is fair.