Java Jive: "I Said a Sip, Not the Whole Cup!"
by Scott Clark
Imagine how a programmer feels when they see their hard work displayed on someone else's Web page, without permission or credit.
Creating a Java applet may take a skilled programmer days, weeks, even months. After the applet has been deployed on the Web, imagine how a programmer feels when they see their hard work displayed on someone else's Web page, without permission or credit.
The theft of applets on the Web is a serious issue to many people. The methods are many: applets can be snagged from a Web browser's cache, or they can be simply linked to the thief's site, using the thief's own parameters. Some clever hackers simply reverse engineer the class file, and rebuild the applet. There's even a new utility program out that reverse engineers .class files into a readable source code.
If you have an applet on the Web, and don't believe anyone else is using it, just go to AltaVista and type in "applet:myapplet.class," (substituting your applet's class name for myapplet.class, of course). More likely than not, you'll see that your applet is being used on sites of which you had no knowledge. For a lot of folks, that's just a great compliment. For professional programmers, however, it's a crime. In this article, Web Developer® will show you one way which you can use to prevent applet theft from happening, and tell you the facts about Java applet theft.
One thing must always be kept in mind when it comes to security on the Internet-hackers enjoy breaking it! Most of the time, the actual information or software that hackers work so hard to get to isn't really the motivation. It's the mere act of breaking your security that motivates a lot of hackers.
Although corporate hackers are out there, when you are talking about Web pages and Java applets, more often than not, the hackers are other Web developers, and the majority of them have Web pages, which is where you'll find your "stolen" applet.
What can be done to stop the majority of these thefts? Well, we have to use what we have available, and we know we can call on getDocumentBase() for help. This method comes from the Class Applet, in the package java.applet. The method getDocumentBase() tells you where the HTML page was served from. Using getDocumentBase(), one can determine the page's origin, and if we call these methods from within the applet, we can prevent it from working if it's not coming from the correct server. Here's a simple applet showing how it works:
import java.net.*;
import java.applet.*;
public class stopthief extends Applet {
public void init() {
String stolen;
Stringowner =
getDocumentBase().getHost();
if (owner.equals("www.yourdomain.com")) {
// this is where you would insert
// your stuff for legit users
} else {
System.exit(1);
// this is where you'll kill or
// otherwise alter the applet for
// thieves
}
}
}
What this does is to cause a security exception at System.exit(1) if the applet is not coming from your site. This is just an example, as you could cause it to do almost anything, but this way, it just won't work for thieves. One negative aspect of this method is that you'll have to change and recompile the applet if you change servers. And just how secure is this method? Secure enough to thwart most applet thieves, but not enough to stop professionals, or even those with a lot of determination. How can they still make the applets function? Anyone familiar with a hex editor can tell you. There's no magic involved...just a little search and replace. So why implement the method at all then? Because it'll stop about ninety percent of those that would hack your applet, and the other ten percent will find a way to hack it anyway.
If you're not afraid to enter the world of CGI (and why would you be...you're already into programming enough to read this column), then you can create a CGI script that is called by the applet, and if the CGI doesn't pass the correct information to the applet, the applet will not function. Is it simple? Not particularly, but it is effective-more so than our previous example.
It is also beyond the scope of this one column to go into construction of the CGI script, applet to CGI communications, as well as the theft protection itself on top of all that. Basically what you do is to make your applet require a "key" which is computed on the fly by both the applet and the CGI script. The key can be encrypted using whatever method you choose, and that method can be used by both applet and CGI script. That way, if the server that serves the applet doesn't also have the CGI script, then the applet won't run. This key can be based on the client's IP, or you can set it up so that both applet and CGI base the key on a text file located on the same server. These are just examples, as I'm sure many of you have other methods in mind.
Some Java programmers feel strongly about applet theft...strongly enough to feverishly work to stop it. However, some feel that the theft protection itself can be more of a hindrance than a help.
"I sure hope Java software distributors don't have to tramp along the same stupid road to nowhere [as software companies who previously implemented copy protection in their software], trying to protect their ridiculously priced $799 programs, futilely repeating history because they won't take a moment to understand the common sense sociology behind software piracy..." said Robert Lynch recently in the comp.lang.java.programmer newsgroup. Robert feels that only when software companies realized that they needed to provide valuable services (such as printed manuals and good technical support along with a fair price), did software piracy decrease.
Unfortunately, software piracy does still continue, far beyond the most common piracy-that of two users exchanging their favorite software. According to the Business Software Alliance, $12.8 billion dollars are lost annually, worldwide, because of piracy, and Java programs didn't even enter into that figure. While some will still argue that Java applets and applications are not software, per se, the majority of Java programmers will tell you that their Java applets are not only software, they can be very expensive pieces of software to produce. Although talk of applet piracy is often brushed aside as paranoid talk, the issue will have to come to the forefront of discussion before the industry accepts Java as a viable programming language, Web or no Web.
In future columns, I hope to touch upon subjects that will help you become a more productive Java programmer. I'm asking for tips, methods, routines, opinions, and news items to make this column exactly what you need. You are the Java experts...so share some of that knowledge with the rest of our readers. Send your input to sclark@webdeveloper.com. Until next time...
Reprinted from Web Developer® magazine, Vol. 3 No.2 Mar/Apr 1997 (c) 1997 internet.com Corporation. All rights reserved.
Web Developer® Site Feedback
Web Developer®
Copyright © 2000 internet.com Corporation. All rights reserved.
