Javascript library: to obfuscate or not to obfuscate - that is the question [closed]

Question

I need to write a GUI related javascript library. It will give my website a bit of an edge (in terms of functionality I can offer) - up until my competitors play with it long enough to figure out how to write it by themselves (or finally hack the downloaded script). I can accept the fact that it will be emulated over time - thats par for the course (its part of business). I just want to have a few months breathing space where people go "Wow - how the f*** did they do that?" - which gives me a few months of free publicity and some momentum to move onto other things.

To be clear, I am not even concerned about hard core hackers who will still hack the source - thats a losing battle not worth fighting (and in any case I accept that my code is not "so precious"). However, what I cannot bear, is the idea of effectively, simply handing over all the hard work that would have gone into the library to my competitors, by using plain javascript that anyone can download and use. If someone is going to use what I have worked on, then I sure as hell don't want to simply hand it over to them - I want them to work hard at decoding it. If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order) - So, I'm not claiming that no one could have written this (which would be a preposterous claim in any case) - but rather, what I am saying is that no one (up to now) has made the functionality I am talking about, available to this particular industry - and I (thinking as an entrepreneur rather than a geek/coder), want to milk it for all its worth, while it lasts i.e until it (inevitably) gets hacked.

It is an established fact that not one website in the industry I am "attacking" has this functionality, so the value of such a library is undeniable and is not up for discussion (i.e. thats not what I'm asking here).

What I am seeking to find out are the pros and cons of obfuscating a javascript library, so that I can come to a final decision.

Two of my biggest concerns are debugging, and subtle errors that may be introduced by the obfuscator.

I would like to know:

1. How can I manage those risks (being able to debug faulty code, ensuring/minimizing against obfuscation errors)

2. Are there any good quality industry standard obfuscators you can recommend (preferably something you use yourself).

3. What are your experiences of using obfuscated code in a production environment?

Waadt

This post deserves a golf clap. <golfclap/> – Serrated

See #29899 – Excepting

@Jonathan, you're usage of the <goldclap/> tag is worth a <golfclap/>. – Reeves

@Waadt - you should read some of Paul Graham's essays, it'll give you a good appreciation of the mechanics of startups. – Cellophane

You are confusing reverse engineering for hacking and appear to not understand the value of a trade secret as a form of protected intellectual property. – Denadenae

How valuable is this? Think of a number. Now, think of half that number. Do you think it'd be possible to find a Javascript programmer who for that amount (half the value of your code) to un-munge it? If so, why wouldn't you expect exactly that to happen? – Pleiades

Answer 1

If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order).

So really, you're trying to solve a business issue with technical measures.

Anybody worth his salt as a Javascript programmer should be able to recreate whatever you do pretty easily by just looking at the product itself, no code needed. It's not like you're inventing some new magical thing never seen before, you're just putting pieces together in a new way, as you admit yourself. It's just Javascript.

Even if you obfuscate the script, it'll still run as-is, competitors could just take it and run with it. A few customizations shouldn't be too hard even with obfuscated code.

In your niche business, you'll probably notice pretty quickly if somebody "stole" your script. If that happens, it's a legal issue. If your competitors want to be in the clear legally, they'll have to rewrite the script from scratch anyway, which will automatically buy you some time.

If your competitors are not technically able to copy your product without outright stealing the code, it won't make a difference whether the code is in the clear or obfuscated.

Maribelmaribelle

+1 Ok, now we are getting warm. Someone is FINALLY reading my question and UNDERSTANDING where I'm coming from – Waadt

@Waadt Being in the right place at the right time with the right idea and the right execution is a lot more important than possessing some secret sauce which needs to be kept hidden at all cost. Just look at Twitter, it's trivial to clone without looking at any code, yet that's where the party's at. – Maribelmaribelle

"So really, you're trying to solve a business issue with technical measures." ... Isn't that the whole point of technology (from a business point of view) ? ;) "Being in the right place at the right time with the right idea and the right execution is a lot more important ..." - Ne'er a truer word been said. The point you make about Twitter is spot on, and does put things "a little into perspective". BTW, I dont have any "secret sauce" - and certainly my business is not relying on just the GUI ;). This is to be just another extra weapon in my toolkit (in the "arms race"). – Waadt

@Waadt Then make sure to keep your weapons clean and not shoot yourself in the foot by obfuscating scripts in ways that'll leave you scratching your own head two months down the road. ;) – Maribelmaribelle

Where as I agree totally that there is no need to hide for reasons of copying, I believe there is a need for reasons of security. Good coders does not necessarily make good crackers, it requires slightly different mindset. You can never predict what these people will try to do. And yes, if they are good, they can probably un-obfuscate, but why make it simple for them? If it is easy and non intrusive to add to you build process then do it. – Holiness

@Ron Security through obscurity? What security exactly do you intent to gain by obfuscating code? Sure, it may slow down a serious attacker a bit, but it does not in any way add real security to anything. Secure code is secure by being sound, not by being obfuscated. – Maribelmaribelle

Answer 2

While you can go down the long, perilous road of obfuscators, you generally don't see them used on real, production applications for the simple reason that they don't really do much. You'll notice that Google apps, which is really a whole heap of proprietary and very valuable JavaScript when you get down to it, is only really minimized and not obfuscated, though the way minimizers work now, they are as good as obfuscated. You really need to know what you're doing to extract the meaning from them, but the determined ones will succeed.

The other problem is that obfuscated code must work, and if it works, people can just rip it wholesale, not understanding much of it, and use it as they see fit in that form. Sure, they can't modify it directly, but it isn't hard to layer on some patches that re-implement parts they don't like without having to get in too deep. That is simply the nature of JavaScript.

The reason Google and the like aren't suffering from a rash of cut-and-paste competitors is because the JavaScript is only part of the package. In order to have any degree of control over how and where these things are used, a large component needs to be server-based. The good news is you can leverage things like Node.js to make it fairly easy to split client and server code without having to re-implement parts in a completely different language.

What you might want to investigate is not so much obfuscating, but splitting up your application into parts that can be loaded on-demand from some kind of service, and as these parts can be highly inter-dependent and mostly non-functional without this core server, you can have a larger degree of control over when and where this library is used.

You can see elements of this in how Google is moving to a meta-library which simply serves as a loader for their other libraries. This is a step towards unifying the load calls for Google Apps, Google AdSense, Google Maps, Google Adwords and so forth.

If you wanted to be a little clever, you can be like Google Maps and add a poison pill your JavaScript libraries as they are served dynamically so that they only operate in a particular subdomain. This requires generating them on an as-needed basis, and while it can always be removed with sufficient expertise, it prevents wholesale copy-paste usage of your JavaScript files. To insert a clever call that validates document.href is not hard, and to find all these instances in an aggressively minimized file would be especially infuriating and probably not worth the effort.

Helbona

+1 very useful and informative. Could you tell me a little bit more about this "poison pill" approach (I like, I like) - specifically, the bit of validating document.href. That + minify could be a working solution – Waadt

Have a function that, through some misdirection, comes to verify that document.location.host is as expected. Obviously having the text "document.location.host == 'customer.com'" will be easy to find and remove, but you can achieve the same thing with some tactical obfuscation, e.g. a variable that refers to document, and some function that extracts location.host from it using a convoluted eval-based statement. If you implement several such checks in a variety of different ways and spike them into the library at several obvious and non-obvious locations, it will be hard for to remove them all. – Helbona

It is obviously easy to generate a script that will only "work" at the location it is loaded from if you manufacture it on the fly, and that's something easily done using something as simple as PHP. /js/library.js could actually be generated by /js/library.js.php if you configure your web server accordingly. If your library is sufficiently large and minified, finding the verification procedure will prove tricky without a lot of technical skill, and you've built in a significant barrier. Just make sure you verify your referral headers so they don't hyperlink your scripts! – Helbona

@tadman, Why did you say Google Maps used the poison pill approach? Did they really actually monitor the host and do rejections based on that? – Fennell

Using the Google Maps JavaScript on a domain which they don't recognize triggers an error and prevents it from loading. You need to have a valid API key for it to properly engage, even though these keys are available for free. It enables Google to limit how their code is used. – Helbona

Answer 3

Javascript obfuscation facts:

• No one can offer a 100% crack free javascript obfuscation. This means that with time and knowledge every obfuscation can be "undone".
• Minify != obfuscation: When you minify your objective is: reduce code size. Minified code looks completly different and its much more complex to read (hint:jsbeautifier.com). Obfucation has a completly different objective: to protect the code. The transformations used try to protect Obfuscated code from debugging and eavesdropping. Obfuscation can even produce a even bigger version of the original code which is completely contrary to the objectives of minification.
• Obfuscation != encryption - This one is obvious but its common mistake people make.
• Obfuscation should make debugging much much harder, its one of it objectives. So if it is done correctly you can expect to loose a lot of time trying to debug obfuscated code.That said, if it is done correctly the introduction of new errors is a rare issue and you can easily find if it is an obfuscation error by temporarily replacing the code with non obfuscated code.
• Obfuscation is NOT a waste of time - Its a tool. If used correctly you can make others waste lots of time ;)

Javascript obfuscation fiction: ( I will skip this section ;) )

Answer to Q2 - Sugested obfuscation tools:

• For an extensive list of javascript obfuscator: malwareguru.org. My personal choice is jscrambler.com.

Answer to Q3 - experiences of using obfuscated code

• To date no new bugs introduced by obfuscation
• Much better client retention. They must come to the source to get the source;)
• Occasional false positives reported by some anti-virus tools. Can be tested before deploying any new code using a tool like Virustotal.com

Recrimination

So you are saying in other languages there is actually 100% obfuscation? – Fennell

Answer 4

Standard answer to obfuscation questions: Is using an obfuscator enough to secure my JavaScript code?

IMO, it's a waste of time. If the competitors can understand your code in the clear (assuming it's anything over a few thousand lines...), they should have no trouble deobfuscating it.

How can I manage those risks (being able to debug faulty code, ensuring/minimizing against obfuscation errors)

Obfuscation will cause more bugs, you can manage them by spending the time to debug them. It's up to the person who wrote the obfuscation (be it you or someone else), ultimately it will just waste lots of time.

What are your experiences of using obfuscated code in a production environment?

1. Being completely bypassed by side channel attacks, replay attacks, etc.
2. Bugs.

Centuple

Answer 5

Google's Closure Complier obfuscates your code after you finish writing it. That is, write your code, run it through the compiler, and publish the optimized (and obfuscated) js.

You do need to be careful if your using external js that interfaces with the lib though because it changes the names of your objects so you can't tell what is what.

Affront

If obfuscation is only a side effect of optimization, it will probably be trivial to deobfuscate. – Percolator

How is deobfuscation trivial? All your variable names are converted to 1 or 2 character cryptic names that cannot be converted back into something understandable by a human. – Denadenae

Basic obfuscation is enough to prevent most prying eyes. – Reeves

Answer 6

Automatic full-code obfuscation is so far only available in the Closure Compiler's Advanced mode.

Code compiled with Closure Advanced mode is almost impossible to reverse-engineer, even passing through a beautifier, as the entire code base (includinhg the library) is obfuscated. It is also 25% small on average.

JavaScript code that is merely minified (YUI Compressor, Uglify etc.) is easy to reverse-engineer after passing through a beautifier.

If you use a JavaScript library, consider Dojo Toolkit which is compatible (after minor modifications) with the Closure Compiler's Advanced mode compilation.

http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

Voltammeter

Answer 7

You could adopt an open-source business model and license your scripts with the GPL or Creative Commons BY-NC-ND or similar

Heroworship

That will not protect from disclosure of trade secrets, which I believe is the ops intent. – Denadenae

The op stated that the secrets are going to to get out anyway. The trick is to not lose the fame and fortune of developing a great solution. Make is part of the license that the name of the company and link be included with all usage in an unobscured way. I guess the point here might be, there is a legal solution to this problem because the technology solutions so far have always failed. – Antiquary

Never keep your business logic that is sensitive in Javascript ( in browser).In those cases may be you can use languages like php to process those parts alone at backend. – Hitherward

Answer 8

While obfuscation in general is a bad thing, IMHO, with Javascript, the story is a little different. The idea is not to obfuscate the Javascript itself but to produce shorter code length (bandwidth is expensive, and that first-time users may just be pissed off waiting for your Javascript to load the first time). Initially called minification (with programs such as minify), it has evolved quite a bit and now a full compiler is available, such as YUI compiler and Google Closure Compiler. Such compiler performs static checking (which is a good thing, but only if you follow the rules of the compiler), minification (replace that long variable name with 'ab' for example), and many other optimization techniques. At the end, what you got is the best of both worlds, coding in non-compiled code, and deploying compiled (, minified, and obfuscated) code. Unfortunately, you would of course need to test it more extensively as well.

Mazman

Answer 9

The truth is obfuscator or not, any programmer worth his salt could reproduce whatever it is you did in about as much time as it took you. If they stole what you did you could sue them. So bottom line from the business point of view is that you have, from the moment you publish, roughly the same amount of time it took you to implement your design until a competitor catches up. Period. That's all the head start you get. The rest is you innovating faster than your competitors and marketing it at least as well as they do.

Belew

Answer 10

Write your web site in flash, or better yet in Silverlight. This will give your company unmatched GUI, that your competitors will be salivating about. But compiled nature of flash/dotnet will not allow them easily pick into your code. It's a win/win situation for you ;)

Money

Flash = security holes. HTML5 is replacing Flash anyways. Silverlight/Flash may not be a possibility depending on who OP needs to serve to. – Percolator

HTML5 is not replacing Flash and Flash is less insecure than JavaScript since its client side script is compiled to unalterable bytecode. – Denadenae

I loathe to think that anyone considers plugin based solutions a win in any scenario. – Antiquary

@austin cheney, HTML5 is a standard and everyone is forced to adopt it. It has all the features of Flash and more. Apple already dropped Flash. @Gabriel, thank you, I couldn't say it better. – Percolator

@Longpoke There are features in Flash that aren't in HTML5, for example DRM (which is quite important to some). Don't pretend otherwise. Also, "forced to adopt"? I wish somebody would have told Microsoft before they released IE6. Nobody is being forced to adopt anything. Note that I do share the general anti-Flash sentiment, just keep it realistic, please. – Maribelmaribelle

@Longpoke HTML5 is not yet a standard and nobody is forced to adopt it. If you believe a standard is equivocal to forced adoption then I do not believe you understand what a standard is, and definitely not understand passive standard bodies such as the W3C. Technology standards are not legal mandates. There is no evidence to suggest that HTML5 is replacing Flash. This merely suggests that you have an irrational preferential bias favoring HTML5. – Denadenae

@austin cheney Because it begs the question: "to whom is your product a service". Not all users can or will install the plugins required to use the technologies you suggest. While they may be perfectly legitimate solutions for a new primed Windows PC the same is not likely to be the case on Linux/Mac/Or even legacy hardware Windows systems. If the OP wants to create a cross platform solution that utilizes all the bounty of the web he has to, by definition, avoid pigeon holed solution like Silverlight or Flash. – Antiquary

Not all users can or will install the plugins required to use the technologies you suggest. Most commonly used plugins come with the browser, so that is a nonissue. In the scenario you provided the OP would also have to avoid use of HTML5, SVG, and any other emerging technology. That is a tangent since many plugins support a diversity of operating systems. The only point at which your argument becomes relevant is with consider for proprietary systems that are inherently and deliberately closed, such as IPhone, and that is a price users of such closed systems must be willing to accept. – Denadenae

@Maribelmaribelle @austin cheney: All browsers will adopt HTML5 to some extent when it becomes standardized. I never said to use any HTML5 to obfuscate, because obviously, it wont obfuscate any better than HTML4....... I highly doubt they'll leave out canvas, video, and audio.... There is no irrational bias in favoring HTML5, the only thing irrational is that people still use Flash. I don't horrible tack on poorly integrated poor security technologies in my browser. Serving a JavaScript library in Flash or Silverlight is what's irrational. – Percolator

Furthermore, Flash and Silverlight wont make it any harder (besides needing a tool to interpret the bytecode instead of text editor) for a real reverse engineer to break the code. The same tricks that can be done in bytecode can be done in javascript, especially via eval. Not to mention with bytecode, you can't to magic like you can in real assembly languages, bytecode forces you to make it somewhat more easy to read. And please don't suggest making the user download a binary... "This will give your company unmatched GUI" Is this true? I can't remember ever seeing a good Flash design. – Percolator