Is intellectual property protection a myth?
In a word, yes, sort of, at least in a technically acruate sense.
Last week I had a conversation with a developer who told be that his company would never develop an HTML5 app because his intellectual property was far too valuable to share with anyone who wanted it.
Of course, upon further discussion, like most of the developers that have said this to me over the years, what he was really concerned with is software piracy, but lets talk about the former first.
Developers, like the one I was talking to above, insist that their distributed applications be compiled so that their source code is “secured”.
Ok, 1999 called to say it misses you ! 
I was working at Microsoft when we released the beta versions of .NET. Included in the SDK was a decompiler. Developers around the world went nuts because all their source code would be stolen !
The truth of the matter is that source code is retrievable from compiled applications on all popular computing platforms. Just a bit of crafty googling will find you de-compilers for C#, Java, Visual Basic, C/C++ and a plethora of other languages.
These will turn your executable binaries into source code. Which tool you use would depend on the type of file you are decompiling which can be determined by headers in the files themselves.
The common response is that the code is not the same as the original source code, and that is true, it may be harder to read (or it may be easier) but either way the “intellectual property” would be exposed.
And there are other ways to get source code for an app too.
You will also find disassemblers that turn an executable binary file into assembly code. They basically convert the executable machine instructions into platform specific Assembly code instructions. If assembly code is not your thing you could them run a source translator to convert the Assembly into another language like “C”.
Of course this still doesn’t deliver the exact source code written by the developer. The resulting source code may not even be recompilable without modification, but again, the “Intellectual Property” has been retrieved.
There are very clever tools like the Holodeck Debugger that allow a skilled hacker type to view in real time what instructions are being executed by the operating system. (Holodeck is an AMAZING tool for good guy developers too !)
It’s possible to implement an encrypted operating system (file system, memory, runtime, ect.) that could decrypt programs in isolation for execution, but characteristics of such an operating system would make it unsuitable for general consumer use.
So, when we talk about intellectual property protection in our applications it’s important to understand that what we are really talking about is just increasing the difficulty level involved in stealing our code or using it in meaningful ways that oppose our desires.
.NET and Java developers who felt the need solved this problem by using pre-compilation obfuscators. The obfuscation process converted the source code to a product that, while syntactically valid, made no sense to the human viewer.
When decompiled the hacker has access to only the OBFUSCATED source code. The intellectual property was still in there, but for all intents and purposes, still secret. The process of reverse engineering code delivered after this obfuscation / compilation was too time consuming to be of interest. This makes the intellectual property secret in a practical sense, it not a purely technical one. Some obfuscators even produces source code that would feail recompilation attempts.
Likewise, people have been securing the logic and the content of the web for a long time. Obfuscators exist for HTML, CSS, and JavaScript. If you’re a web developer you have certainly cracked open a page or a downloaded a JavaScript file and seen huge strings of hex digits. Those were probably a method of obfuscation.
For example, the following simple JavaScript program:
var a="Hello World!";
function MsgBox(msg)
{
alert(msg+"\n"+a);
}
MsgBox("OK");
When obfuscated becomes this.
var _0xf979=["\x48\x65\x6C\x6C\x6F\x20\x57\x6F\x72\x6C\x64\x21","\x0A",
"\x4F\x4B"];var a=_0xf979[0];function MsgBox(_0xa221x3)
{alert(_0xa221x3+_0xf979[1]+a);} ;
MsgBox(_0xf979[2]);
Using the application will expose what it does but viewing the source code does dot expose HOW it does it.
There are really two things that people are interested in defending against. One is people using their software for free, the other is people stealing their source code which is to say the algorithms that are specific to their applications.
If you’re build an app using web standards (HTML5/JavaScript/CSS) you need to decide how much “protection” is enough to satisfy your concerns.
Of course the most secure method is to keep the parts of your logic that need to be secret on the server. You can modify your application’s architecture so that some functionality is only available when an internet connection is present.
You can use obfuscated client side assets to confuse prying eyes from easily hacking the APIs. Of course, if an even higher level of security is necessary, you can further restrict access to the APIs by using SSL and a per request token based authentication mechanism.
Similarly, once you have done the above you can use similar methods to assure that the user of your app is authorized to use it by periodically requiring an authentication handshake. (Mozilla apps will provide an API to help the developer do exactly this using Persona and the MozApps receipt system.
Many organizations have discovered that these concerns are never realized when their apps become public but above are a few ideas that you can use to make stealing your code more difficult. Remember, there is no such thing an an app that can’t be reverse engineered. But you can make them work for it !
