<<a href="#" onclick="alert('No one must know this secret!')">>This is a secret link!<</a>>
The result from an obfuscator might be
This obfuscated code replaces the original code in your document and, believe it or not, works entirely properly, as shown in Figure 23-10.
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.
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.
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.