One very interesting use case for obfuscation is tracing the origin of illicit copies. Assuming that obfuscation is a relatively cheap operation the original author can supply each client with differently obfuscated versions of the application, if an illicit copy is found the author can compare with supplied versions and trace back the source of the piracy.
That's a form of steganography, inspired and in variation of the "traitor tracing" cryptographic schemes. I have no idea if it's common1, or even if it's a good idea, but I've seen it applied in practice under the following parameters:
- Highly competitive nationwide market with just two vendors,
- About 50 deployments covered the market,
- Average development time for both applications was a couple of years (more or less),
- Average obfuscation time for our application was a couple of hours,
- Lifespan for both applications was expected to be about ten years.
The rationale was of course security through obscurity initially, and it evolved at the aforementioned scheme at some point2. Both vendors had access to each other's binary code, legally, and I think it's obvious that decompilation attempts from both were expected. Obfuscation did nothing in terms of security, in the long run. Both vendors had highly motivated and talented teams, working in an extremely profitable and niche market, in the end our products were more similar than not, and any competitive advantage was gained through other, less obscure means.
I can't really expand, because (a) it was very early in my career and I didn't get a clear overview of the design decisions or the results of the tracing scheme (if any) and (b) some of my involvement with the project was under a NDA.
Another valid use case for obfuscation could be when you are somehow legally obliged to submit your code to a third party:
If your firm does IP work for technology companies, or is involved in cases involving software source code, you may be obliged to submit your client’s source code to the USPTO, a court or third party.
Since source code is considered a trade secret, most regulatory agencies use a "50%" rule. Source code submitted is obscured so that it cannot be used as-is.
IANAL, and the link is more relevant to hard copies of code rather than actual working code, so this might be completely irrelevant.
Now, as Javascript is the canonical example for obfuscation, there's one side-effect that's not commonly considered, and that's hiding malicious code in obfuscated Javascript. Although there are definite advantages in minifying3 Javascript, I don't see any point in actual obfuscation and I'm happy Douglas Crockford agrees with me:
Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages, it is just more obviously true with JavaScript because it is delivered in source form. The privacy benefit provided by obfuscation is an illusion. If you don’t want people to see your programs, unplug your server.
As for obfuscation for "job security", that's a behaviour that should never pass code review, and if identified it shouldn't be tolerated. I wouldn't go as far as firing the culprit at first, but repeat offenders definitely deserve a good spanking, at least.
In conclusion, obfuscation is a typical example of security through obscurity, it's only obvious merit is as a deterrent and nothing more. There might be creative use cases4 I don't know of, but in general the benefits are minimal, at best.
1 After writing this I found out this answer which basically describes the same scheme, so it might be more common that I thought.
2 Although steganography is still security through obscurity.
3 Minification ~ removing whitespace and shortening tokens, not intentionally obscuring.
4 Does the International Obfuscated C Code Contest count?
Best Answer
The best security against information being wrongfully used is to avoid sending the information over a public communications network.
If that is not an option, you have to consider who and what you are trying to protect against.
If you want to be safe from third-parties snooping the traffic between your website and your customers, then don't bother with obfuscating the webpages, but use a secure connection instead.
If you don't want your users to access some information that is needed by the browser for displaying the page or generating the next request, then encryption won't help you (the browser needs to be able to decrypt the information anyway) and obfuscation might at best slow someone down but it won't stop them obtaining the information.
For really sensitive information, you could store it locally on the server and only give out a (one time) unique ID for accessing the information on the next request.
As a sidenote, using obfuscation might make people more interested in knowing what you are trying to hide.