When you copy some js files that include their license checking code to your server and them serve it to your clients, your clients need to block qeys.io, not you.
You can instruct clients to do that of course, but it's rather easy for one of them to forget and the copyright holder is noticed.
Still, blocking qeys.io by default on your system sounds like a good idea :)
That's totally it, thanks for pointing that out!
Additionally, defaulting to shutting down the app when it can't reach your servers breaks all sorts of offline features an app may have.
I would strongly suggest to default to doing nothing when the script can't contact your servers. Alternatively you let me configure an HTTP endpoint that will be pinged when it can't reach you so at least I am aware the service is disrupted.
The small piece of code is designed to only invalidate and deny access when a valid response is returned from our servers.
That means that if our service is unreachable you won't be notified about invalid use, of course, but the app assumes the positive and allows everyone access until a valid "denied" response.
Did you experience the contrary, or was this simply not clear from what you read? In that case, I'll try and add that to the FAQ section.
In a very bad scenario where our service is slow, the worst thing that happens is a user being able to use the web app for a couple of seconds before it is denied access.
I understand now that you mean in case the website is an unauthorized copy the end user will be able to use it for a few seconds before it is disabled.
In that case I retract my previous comments, but I would suggest changing the wording in the FAQ here to be more clear. :)
Issues like what you've described -- whether real or perceived -- are the root cause of many code smells.
You can display a small hint on the UI ("It seems that there's a problem with your connection"), but only an idiot would block users from interacting with the app on grounds of "being offline".
I can't be alone in thinking that these prices are insanely low when considering the market. If you're selling to working programmers, $9.99 a month is a frivolity. I pay more than that for Netflix. For a business expense? Your $24.99 plan should be the entry point.
You should have a higher tier. A much higher tier, in fact, like $350. You're targeting agencies and studios at this point. It's still under the ~$500 that requires approval, but there are absolutely businesses out there that will just sign up for the highest tier they can process, because it's a status thing or "they may need it". You won't get many signups at this price, but even one will replace 35 signups at your current lowest tier. Heck, more, because higher-priced customers will churn less and require less support.
Consider dropping your free tier and just relying on your free trial. You're targeting businesses and working programmers. They have money, so a lack of money won't be the reason they choose not to use your product, only product/customer fit.
Anecdotally, a place I previously worked at raised all of its prices and tweaked the available plans (with some A/B testing involved) and internally it was incredibly controversial and made a lot of people unhappy as we were implementing it. When the testing period was over and all was said and done, few people complained about the price hikes and far more people either just accepted it or went for an upgrade.
I think it's very easy for a startup to completely underestimate the value it provides and assume that nobody would pay more if they had to. But maybe that's just a bias because you don't tend to hear about the companies that failed for charging too much. (Not that I would suggest you blindly follow this advice!)
EDIT: The part of the snippet in question:
window.addEventListener('load', function(a){
document.cookie.indexOf('validated=')<0&&v();
});However, any client side protection can be bypassed, especially if your adversary has write access to the code you're trying to protect.
Maybe as an additional protection, qeys should, say, 1 in 7 [0] times, send a request regardless of whether the cookie present.
> the thief
> the code they just stole
Uh. I know this is extremely widespread to call it so, but copyright infringement isn't "theft" or "stealing".
Also, your privacy policy makes no mention of what data is included with validation requests, and what you do with that information. GDPR is still very fresh, and if my app is passing every URL data to a third party, that sounds like it could be a problem.
I'll include a section in the privacy policy on what's sent in the request, which is just the application UUID and the licence key. Our service then uses the origin of the request to determine the domain.
And the complete URL of the originating page, as the parent commenter mentioned.
What am i missing here?
"The small piece of code is designed to only invalidate and deny access when a valid response is returned from our servers." seems pretty easy to circumvent but... i guess you could make your app stop working if it fails to get a response within x days or whatever, but you'd have to use a compiled language to make that even remotely difficult to not circumvent too.
> Besides, we strongly recommend to let our JavaScript file blend in with the rest of your application's JavaScript. Webpack, compress and uglify the best you can, to make the code responsible for validation as difficult as possible to find and break.
Ok, so this is a solution to detect (some of) the sites that use your JavaScript code without approval, not a solution to prevent them from doing it (since it can be easily blocked once you know to look for it).
Seriously though, this seems like an convoluted way for small businesses to resolve trust issues with their clients.
I mean, if you really want to do this, why not make it incredibly simple and just ping a server with the domain names the web app is being requested from. Do it all silently and then let the IP owner decide what to do about it. Why shut the site down and risk embarrassing, and potential trust destroying, situations arise from false positives?
Is this a problem that happens often?
On a serious note, it has happened to me a handful of times in many years. Not often, but enough times to want to be notified when it happens again.
Then you can put a use clause in your service agreement and bill your customers according to their use. They've signed that any additional use incurs a cost, but they don't think you know.
I guess a service worker has the advantage of not having to dig through potentially obfuscated Javascript code. But it's not like that would be hard to do, given that Chrome's debugging tools record a stack trace for every XMLHttpRequest.
> we strongly recommend to let our JavaScript file blend in with the rest of your application [..] to make the code responsible for validation as difficult as possible to find and break
This smells much more to security by obscurity than an actual licensing solution.