Protecting Your Code

If you are concerned with people stealing your scripts for use on their own sites, then you probably should not be implementing in JavaScript. Because of JavaScript s nature as an interpreted language included directly in (X)HTML documents, your users have unfettered access to your source code, at least in the current Web paradigm. While you might be able to hide code from na ve users by placing it in externally linked .js files, doing so will certainly not deter someone intent upon examining or borrowing your code. Just because the JavaScript is not included inline in the page does not mean that it is inaccessible. It is very easy to load an external .js library into a debugger, retrieve it from your browser s cache, or download it using your browser using a direct URL.

A partial solution to protecting your JavaScript code is offered by code obfuscators . Obfuscators read in JavaScript (or a Web page) and output a functionally equivalent version of the code that is scrambled (presumably) beyond recognition. Obfuscators are often included with crunchers, but there are numerous stand-alone obfuscators available on the Web. Be careful though: good obfuscation often comes at the expense of good crunching . Really hard-to-decipher code might even be bigger than the original code! To illustrate the idea, we use an obfuscator on the following snippet of HTML and JavaScript:

 <<a href="#" onclick="alert('No one must know this secret!')">>This is a  secret link!<</a>> 

The result from an obfuscator might be

 <<script type="text/javascript">>var  enkripsi="B'isdgEnobmhbjE'mdsuOnnodltrujonv uihrrdbsduDUihrhr'rdbsdumhojB.'D"; teks="";  teksasli="";var panjang;panjang=enkripsi.length;for (i=0;i<<panjang;i++)  teks+tring.fromCharCode(enkripsi.charCodet(i)1)  teksasliunescape(teks);document.write(teksasli);<</script>> 

This obfuscated code replaces the original code in your document and, believe it or not, works entirely properly, as shown in Figure 23-10.

Figure 23-10: Obfuscated code is functionally equivalent to the original.

There are a few downsides with using obfuscated code. The first is that often the obfuscation increases the size of the code substantially, so obscurity comes at the price of download speed. Second, although code obfuscation might seem like an attractive route, you should be aware that reversing obfuscation is always possible. A dedicated and clever adversary will eventually be able to undo the obfuscation to obtain the original code (or a more tidy functional equivalent) no matter what scrambling techniques you might apply. Still, obfuscation can be a useful tool when you need to hide functionality from na ve or unmotivated snoopers. It certainly is better than relying on external .js files alone.

Note  

Many developers refer to obfuscation as encryption. While doing so is likely to make a cryptographer cringe, the term is in widespread use. It is often helpful to use encryption instead of obfuscation when searching the Web for these kinds of tools.

Note  

Microsoft Script Engine 5+ comes with a feature that allows you to encrypt your scripts. Encrypted scripts can be automatically decrypted and used by Internet Explorer 5+. However, this technology is available only for Internet Explorer, so using it is not a recommendable practice.

Paranoid developers might wish to move functionality that must be protected at all costs into a more appropriate technology, perhaps a plug-in, ActiveX control, or Java applet. However, doing so doesn t really solve the problem either, because both binaries and bytecode are successfully reverse-engineered on a regular basis. It does, however, put the code out of reach for the vast majority of potential thieves .