When you compile and distribute a client you are automatically protecting yourself from someone seeing and modifying your code. Can this be achieved on a Javascript client?
-
Copying and viewing the code (the compiler's output, of course) is trivial. Understanding it may be slightly harder, but compilation alone only gets you this far. Also, the code has to be decrypted for the engine to run it.– user7043Commented Mar 3, 2012 at 20:01
-
9This is called security through obscurity, which isn't real security, hence no.– RaynosCommented Mar 3, 2012 at 20:06
-
If you look at it, Flash is just about as powerful for web the way javascript is indefensible. But the former originated as a private standard and later was more of open standard. This is usually a pattern that single company originated standards solves such problems before they become dominant in market, and for open standards this is usually an after thought. There is nothing that stops your from creating JavaCrypt which will be all javascript but will be binary and encrypted. I guess the only thing is it is too late!– Dipan MehtaCommented Mar 4, 2012 at 5:12
-
Geez, can't this be closed as: Duplicate, Not Productive, Flamebait, Do a Google search 1st, etc, etc, etc?– PaulCommented Mar 4, 2012 at 14:41
-
1@Paul, yes. You do this by clicking the "close" link under the question. Also, for Google searches show the actual search finding the answer you think of.– user1249Commented Mar 4, 2012 at 16:16
Add a comment
|
5 Answers
No JS obfuscator is worth the money and sweat to use them.
JavaScript can always be reversed, and no matter what the obfuscator's method is, you will able to run through the obfuscated code and study it in any modern browser. Except if the obfuscator would also package code meant to make your life harder to prevent the use of debug tools, but it would just be eventually circumvented and rendered useless as well.
If you really need secrecy for your code, then don't use JavaScript and rely on other technologies. If you approach the problem the other way around, and you already built the new coolest JS-based web-app and want it to be hidden: give it up.
So, I'd say no, you can't really protect it, and don't bother spending cash on paid obfuscators (if you want to waste time, feel free to use the free ones out there, though they're barely worth your time too). Just use a good minifier / compressor / compiler to reduce the pay load. It will already make it harder to read, but not longer to run as will a lot of obfuscators. And it's still less readable to make it slightly more annoying to read and discourage some.
For good minifiers / compressors / compilers, read my answer (and the rest of the thread) to: What do you Use to Compress JavaScript Libraries?
Also, when distributing a client, you're not really protecting yourself that much either. Disassemblers exist and knowledgeable software engineers who know how to use them are legion. Don't rely on obfuscation / obscurity for security, and don't consider a client a trade secret.
If you really meant to encrypt the JavaScript code, that would imply that something needs to decrypt it before executing the code, meaning you'd need to either have a browser plugin installed on all clients or to have your page contained a JS-based decryptor, essentially giving the tool to anyone who'd like to decrypt the code. Additionally, the browser would see the decrypted version at runtime anyways.
-
I'd add.... Nothing you will ever do it going to be worth protecting. Just because it's hard and unique to you doesn't mean a bunch of other people have already done it.– PaulCommented Mar 4, 2012 at 14:43
-
@Paul: I assume you meant "haven't already done it". Or that they might in the future anyways. True, although idealistic. It can be understandable for companies to want to protect intellectual property (by way of copyright law) and to even protect trade secrets. I'm not in favor of it (and strongly opposed to software patents and patent systems in general), and think that hiding said secrets is just slowing down the whole research evolutionary process and the commercial ecosystem, BUT I can still understand the financial reason for some, especially when it's all they have.– haylemCommented Mar 4, 2012 at 14:48
-
@Paul: but that doesn't take away the fact that trying to do it for client-side JavaScript is a waste of energy, effort and brains. It's a losing battle, and not even one that's worth fighting.– haylemCommented Mar 4, 2012 at 15:30
Regarding client-side javascript code, which is what we usually see on the web, is unusable when put through an encryption scheme as the web browser needs to read the code so it can be interpreted by the browser. Usable javascript code is always trivial to view and get a copy of.
You could obfuscate the code, making it harder to understand, with a minifier such as the yui-compressor. Though its purpose is to compress the code so that the cost of bandwidth can be cut down or if you are concerned for having it load fast enough for your users.
Does this mean it is easy to "copy"? It depends on what your javascript code does. Most of the javascript code that is difficult to reproduce is tied to something it expects from a web server such as JSON/XML/HTML data. Web applications are difficult to copy because they depend on code-behind from different data sources.
By the way, don't worry, others will try to steal your site...
Anecdotally I used to work at a e-commerce store that has a very nifty designer web application. The customers can design the product the way they want it and the controls on the website rely heavily on javascript. A lot of people have tried to copy the site and seemingly fail for which we only could secretly scoff about (and feel a teeny bit proud about ourselves):
We found through a Google Alert that a shady chinese site completely ripped the site for their own (not even replacing the logo). Apparently they tried to set up their own store. The problem was that they didn't have the graphical assets that our backend provided. Thus they clearly haven't had any use other than to show off on "hey, look what we can do".
For years we've seen several freelancer.com ads where we were referred to which didn't seem to pan out, probably due to the ridiculously proposed budgets, short time schedules and poor description of what they want to do with it. For some reason the people who put these ads up have no idea how incredibly complex the business behind the website really is.
Sometimes people are really lazy: One time we've got a call from a company who wanted to know who designed our website. Apparently some design agency was using us as reference and the problem is that we did it all in-house.
This shows that even if you have a javascript web app, it is still difficult to copy it and make a business out of it because you have everything else under the hood to worry about. In our case we had most of the product structure and graphical assets done in the back end, not to mention the production pipeline to produce the actual products that also needs to be in place. So it's all not just web development.
"Protected"? No. "Inconvenient"? Yes. (Just as with binary.)
At a certain level, no popular operating systems (yet) can prevent a sufficiently motivated actor from recovering the in-memory representation of your program and reverse-engineering it. So the "protection" is only relative to the value of your code to another.
If you accept that it is a matter of degrees, then the question becomes "Is it possible to make JavaScript quite inconvenient to understand?"
It is:
- Trivial to make JavaScript somewhat difficult to undersand using a minimizer
- Fairly easy to make JavaScript rather difficult to understand using an obfuscator
- Theoretically possible to make JavaScript quite difficult to understand using your own obfuscation protocol (i.e., encrypted payloads, program execution based on deceptive side-effects and intentional use of language edge-cases)
answered Mar 3, 2012 at 20:29
You can but it would be pointless. The browser has to eventually see unencrypted javascript otherwise it cant run it. It would then be trivial to find what the browser is currently running.
If you need lots of security on your client side code then your doing something wrong. You should be doing your complex logic and validating inputs on the server side.
On a side note, its also worth mentioning that its also trivial in most languages to get from compiled code to human readable code. There are techniques to make it harder but none of them is perfect.
answered Mar 3, 2012 at 21:01
-
I disagree with "If you need lots of security on your client side code then your doing something wrong". JavaScript-heavy apps are becoming more and more commonplace, and it's reasonable to not want your JS source code to be easily accessible to anybody using the app. Commented Mar 3, 2012 at 23:06
-
2@nicholaides - Am curious. Why is it reasonable to not want your code to be accessible? How useful is it to someone who doesn't have the server-side code to go with it?– jmort253Commented Mar 3, 2012 at 23:13
..because they can implement your app on their own server, and use your back-end resources to power their site. Many client-side apps store an appKey that gives them access to the backend. That's how the server knows it's an authorized client.
Worse, I don't want them to be able to modify my client-app, such that they can clone my site, and fool users into logging into my site, while also submitting the user's password to their own database as a harvesting mechanism.
Also, imagine I offer a free web app/service .. another site downloads the client-app, and modifies it such that they charge for access, handling billing/payment collection on their own server, but otherwise relying upon the API services on my server to provide the backend to their webApp offering (that I created).
At least with the code minified, it is unlikely that they can easily edit the client-app to charge people money, or clone my site and harvest passwords, etc.
-
2this doesn't seem to offer anything substantial over points made and explained in 4 prior answers– gnatCommented May 28, 2014 at 17:16
-
1