Ask HN: How do you protect your Javascript-powered WebApps?
5 comments
It is not really a problem.
If someone saves out your source code, then they can. You can put a copyright notice on it.
If they use it on their web site without permission, they're violating copyright. However, that isn't why it's not a problem.
All of your:
* Version history (except for public versions) * Unit tests, test plans, test data, test results * Bug trackers * Developers notes; QA engineers notes * Code maintenance manuals * Developers brains; QA engineers brains etc.
Are private, and someone leeching your content cannot obtain them.
Not to mention the fact that, if there are any server-side components, they'd need to reimplement them.
The time it would take them to understand your code, reproduce all the missing parts, they could just as well develop it themselves.
In fact, if they hired engineers with the calibre required to do that, the engineers would probably WANT to implement it themselves, not rip yours off.
Do not consider that the .js files are all of your development information. They aren't.
Additionally, the version that they leech is always going to be "behind" the one you're developing, right?
So in the time they take to figure out how your code works and how to integrate it with their own back-end systems, you'll have released a better (At least hopefully better) version. So they're permanently behind you, with an inferior product.
If someone saves out your source code, then they can. You can put a copyright notice on it.
If they use it on their web site without permission, they're violating copyright. However, that isn't why it's not a problem.
All of your:
* Version history (except for public versions) * Unit tests, test plans, test data, test results * Bug trackers * Developers notes; QA engineers notes * Code maintenance manuals * Developers brains; QA engineers brains etc.
Are private, and someone leeching your content cannot obtain them.
Not to mention the fact that, if there are any server-side components, they'd need to reimplement them.
The time it would take them to understand your code, reproduce all the missing parts, they could just as well develop it themselves.
In fact, if they hired engineers with the calibre required to do that, the engineers would probably WANT to implement it themselves, not rip yours off.
Do not consider that the .js files are all of your development information. They aren't.
Additionally, the version that they leech is always going to be "behind" the one you're developing, right?
So in the time they take to figure out how your code works and how to integrate it with their own back-end systems, you'll have released a better (At least hopefully better) version. So they're permanently behind you, with an inferior product.
Also, while obfuscation can't protect you from a determined programmer (and shouldn't be done for its own sake), minification or compilation like Google's Closure compiler does will remove a lot of the information anyone looking to steal your work would like to have.
I totally agree with MarkR42 and was thinking the same thing when I had your question, OP.
My main conclusion became server side processing is the black box at least in my case where the value add is through the REST APIs the javascript works with to present the right data to the user.
My main conclusion became server side processing is the black box at least in my case where the value add is through the REST APIs the javascript works with to present the right data to the user.
Thank you for the insightful comment :)
Just wanted to add to the insightful comment, so what if another person uses a function in that .js code to solve their problem, your ideas stay yours.
Also you can close down your IP into the server programming environment and call that from your .js
I personally think that the proper balance between close ideas and open solutions is what spurred the web world beyond any other programming environment.
If it's a web app and it makes API requests it might be pretty hard to make cross-domain web requests. So if your app is naturally complicated enough this isn't an issue.
If it's like a javascript web game without much of a server component, you could try to hide a lot of the execution of the code within in a closure. dynamically loading the code with a script would add to this obfuscation.
in the end you are probably fine.
one final bit of obfuscation that i have always wanted to try was to load the JS via a web-socket on a worker process. that should even hide a lot of the js file being loaded.
if you needed to go farther some people have even done some degree of encryption. again all of this is probably way more than you need. I've never worried about this. if someone has the time to steal your code and work with it you should probably hire them or go have coffee with them and ask for feedback.
it's a great honor for someone to read and interact with your code.
If it's like a javascript web game without much of a server component, you could try to hide a lot of the execution of the code within in a closure. dynamically loading the code with a script would add to this obfuscation.
in the end you are probably fine.
one final bit of obfuscation that i have always wanted to try was to load the JS via a web-socket on a worker process. that should even hide a lot of the js file being loaded.
if you needed to go farther some people have even done some degree of encryption. again all of this is probably way more than you need. I've never worried about this. if someone has the time to steal your code and work with it you should probably hire them or go have coffee with them and ask for feedback.
it's a great honor for someone to read and interact with your code.
>Obviously, you can't stop the user from saving the source-code, but I was thinking maybe you can perform some "validation" or "tests" within the JS to see if the editor is live from the intended URL.
Anyone trying to steal your code would simply remove those tests. As MarkR42 said, your main protection is that your production code, by itself, just isn't worth that much.
Anyone trying to steal your code would simply remove those tests. As MarkR42 said, your main protection is that your production code, by itself, just isn't worth that much.
Yep, thanks matey!
Has anyone actually found really good javascript source that they actually liked and would rip off?
I'm sure it exists but 90% of it is a mess and it would be easier to reimplement. The other 10% is beautiful but only works if you have all the proper server side code.
I'm sure it exists but 90% of it is a mess and it would be easier to reimplement. The other 10% is beautiful but only works if you have all the proper server side code.
I think it would be done fairly frequently with HTML5 games or stand alone tools like he was talking about. If it had zero back end then it would cost nothing for someone to just rip and host on their own site. People do it with flash games all of the time. Throw ads on the page and get some better SEO and you're golden.
If you're concerned about code theft, you can always just use a minimizer. That usually obfuscates your code beyond readability.
Obviously, you can't stop the user from saving the source-code, but I was thinking maybe you can perform some "validation" or "tests" within the JS to see if the editor is live from the intended URL. But, I'm not sure, how would you do it, if you had a full-fledged JS powered application? Your thoughts?
Thanks