How do I hide my applets?

[Velika Srbija]

In order to access my applets from my jsp I had to store them outside of the WEB-INF directory. But, it is easy to get the listing of such directory and therefore copy all applet classes. Is there any way I could hide my applet classes?

[Norm Radder]

Wrap them in the HideEmAll class. Nothing can be found once in there.

[Ulf Dittmer]

Applets are run on the client, so that's where the classes must go. And once they're there, they can be stored locally and decompiled. You can make that harder by obfuscating the code, but you can't prevent it from happen. That's just a fact of life with applets.

[Velika Srbija]

Norm Radder:

What do you mean by "Wrap them in the HideEmAll class"? Give me some guidelines.

Ulf Dittmer:

As stated in the docs, this should work in order not to cache applets on the client's comp:
<jsp aram name="cache_option" value="No" />

I've checked it. It doesn't always work!

[Ulf Dittmer]

A caching option set by a web page may be honored by a web browser or Java plugin, or it may not be (and according to a quick Google search this option may no longer be used in current plugin versions), but that's irrelevant to the point in question: You can't prevent the applet code from getting into someone's malevolent hands, because that's where they need to be if that person can run it.

What Norm said was a joke; he should have used a to indicate that.
[ September 30, 2005: Message edited by: Ulf Dittmer ]

[Velika Srbija]

Obfuscating might not be a good enough solutin, because my applet consist of 4 very simple classes with applet-servlet communicating.

[Norm Radder]

I method of hiding applet code I've thought I'd like to try sometime is to use a ClassLoader in the applet. The class file would be read by the applet as a byte stream and loaded into the JVM ClassLoader loadClass() method to create a class. That moves the hack problem up one level.
The next level would be to encode the class file.
The next level would be to have a cgi that encodes the class on each request and passes the key and the class file back.
The next level would be to have the cgi return the html and applet with the decode key as a param and have a time limit between the request for the html and the request for the class file.
None can prevent a good programmer from reading and decompiling your code.

[Ulf Dittmer]

Obfuscating might not be a good enough solutin, because my applet consist of 4 very simple classes with applet-servlet communicating.

If the classes are simple, what is the need to hide the code?

If you're communicating to a servlet anyway, then move all the methods you want to protect to the servlet, so that the applet consists solely of a GUI, which shouldn't be in need of protection. If it's the method of communication you want to protect, use authentication.

Using ClassLoaders, like Norm suggests, ups the ante to a point where an attacker would need to be rather determined to get at the code, but requires the applet to be signed, and thus the signature to be accepted by the users. That may or may not be a feasible route in your case.

[Velika Srbija]

My classes are simply indeed, but there are some math formulaes that I don't want to share. In order to gain very fast calculations (results) I don't want those formulaes stored in the servet method. What shall I do?

[Ulf Dittmer]

Since you have applet-to-servlet communication in place anyway, you can use that to retrieve the formulas a strings when you initialize the applet. Then you can use a library like JEP to evaluate the formulas. That is of course quite a bit slower than evaluating them directly, but it does offer another layer of protection, though, once again, it can be defeated.

[Velika Srbija]

Thanks. That will be good enough.