For script writers, the two main privacy issues are preventing scripts from being stolen, and preventing scripts from being wrecked. The task is harder for JavaScript than it is for Java or other kinds of program because the script source and the executable program are one and the same.
For standalone scripts, neither issue is a problem, unless someone else has access to your computer or your account. If those scripts are used as CGI programs behind a web server, then there is also no problem, unless the web server itself has a security problem. See the 'Privacy for Web Masters' section for an exception.
For server-side JavaScript, the scripts are stored and executed with the web server, so provided that server is secure, no web user can access them. HTML files sent to the user are stripped of any server-side JavaScript in the web server before delivery.
For client-side JavaScript, the situation is much worse. There is no way to systematically protect JavaScript code except by entering into a security arrangement with the user. There are a few partial solutions.
Client-side JavaScript has virtually no protection on the Web. You might as well give up, and accept that the work you do is there to be stolen and modified as any web user sees fit. It is non-trivial (except for experts) to break-in to a web site and damage your original HTML and .js files, so at least that which your web server delivers to users remains in good order, even if they do something with it afterwards. If such a break-in concerns you, use a tried-and tested Unix host such as Linux for your web site and test its security with the SATAN tool: http://www.fish.com/satan/.
Once the JavaScript is in the Web browser, there are only a few things that can be done to protect it. In particular, this code does not protect anything:
<HTML><HEAD>
<SCRIPT SRC="secret.js"></SCRIPT>
</HEAD></HTML>
The JavaScript in the file 'secret.js' may not appear when the user chooses to 'View Source' for this document, but its URL is obvious. The user only needs to type the full URL for the file into the browser, retrieve the file, and then do 'View Source' again. Internet Explorer 4.0 scripts are the same, because they have a URL as well.
For a user on the Web who views publicly available HTML, there are few foolproof tactics for protecting or hiding client-side JavaScript. The nearest thing is to embed your JavaScript in a Java applet, using the Netscape LiveConnect features of Java. That is a lot of work for non-trivial JavaScript. See Chapter 8 for details of how to do this.
An easier but less effective tactic is to protect your scripts by making the job of copying them less palatable, rather than impossible.
For those inclined to steal your source, there are some simple barriers that will make the job harder, and encourage the culprit to give up. The most common tricks that make scripts difficult to read are:
<SCRIPT> sections. The script stealer has to create a formatting program to fix this, or do it by hand. If your JavaScript code is CGI generated, it is easy to apply a filter to the output which turns all return characters into spaces.http://reality.sgi.com/ioccc/.// before
function calculate_interest(principal, percent_rate, yearly_calculations, term)
{
var factor = 1 + percent_rate/yearly_calculations/100; // one lot of interest
return principal * Math.pow(factor, yearly_calculations * term);
}// after
function a01(a02,a03,a04,a05){var a06=1+a03/a04;return a02*Math.pow(a06,a04*a05);}
The new function works the same but its meaning is now a near mystery. JMyth is one such tool for JavaScript—http://www.geocities.com/SiliconValley/Vista/5233/jmyth.htm.
Unfortunately, such tools have severe limitations. Firstly, as the example shows, built-in objects, methods and properties can't be renamed. These are often a large part of the code, and can give away the code's intent. Secondly, the translation is almost guaranteed to produce non-working code if eval(), setTimeout() or setInterval() are used, since their string arguments are actually code in disguise. Translators are usually too dumb to detect these more complex cases, so the arguments refer to original names, not translated ones. There are other similar problems which translators can't easily detect as well. Finally, if the document is a frame, referring to functions or variables in another frame, the translator has the further job of coordinating all the changes across documents.
Leaving aside these limitations, you may still find such a tool useful.
If you put a copyright statement in comments at the top of your code and ask that it should not be used by others, or at least, if it is, then it is attributed back to you, people might just do it. If the information is "published" (exposed on the Web is an example) then you automatically have some copyright rights in countries that respect the Berne convention (most countries), provided you identify yourself as the author.
In the end, worrying about theft is probably not productive. The main problem is identifying when your script has been taken and used elsewhere, and by whom - almost impossible to enforce or police on the Web. Most client-side JavaScript code is small and uninspired, and uses well-known techniques that aren't new in any case.
When a user requests a URL from a web server, the downloaded file may pass through many systems that make up the network before reaching the user. All those systems have the opportunity to read the data as it goes past. Browsers include support for a network protocol called the Secure Sockets Layer (SSL). If support for this is turned on, then all data sent between the browser and any web servers with the same support will be hidden from intermediate systems.
However, once the user has the data, such as a .js file, they may do anything with it without using secure means, such as forwarding it using e-mail.