Skip to main content

The Act We Act

Posted by editor on May 29, 2008 at 6:19 AM PDT


Banishing the applet warning

The lowly Java applet is seemingly poised to make a comeback, thanks to the radically overhauled plug-in in Java SE 6 Update 10 and its many improvements (quick start, doesn't crash the browser, applets tear off and become Web Start apps, etc.), along with the growing interest in Rich Internet Applications. For some, that means it's 1996 all over again, as we go running to find our old copies of Laura Lemay's Teach Yourself Java in 21 Days and figure out the parameters for the <applet&gt tag again... or wait, do I do an <object&gt or an <embed&gt or something now? Dang, it's been a while.

And of course, once you get your applet up and running, you come up against the security restrictions meant to protect against malicious applets. No filesystem access, no network access to any host other than the one the applet came from, etc. You can get around this by signing your applet, but then the user will have to explicitly grant access permissions, which typically means tech support gets calls from people who are terrified and confused by the security dialog. Someone somewhere sighs, and asks, "are you sure we can't just do this with DHTML and CSS?"

Josh Marinacci notes that the security back door has been opened just a little bit in 6u10, as he explains in Java Doodle: crossdomain.xml Support:

Signing is great when you need access to more than what is allowed inside the sandbox, but it has two problems: the user will receive an ugly warning dialog about the applet, and the applet will have full access to the user's computer. Full access is overkill when all you want to do is talk to a webservice on another server. Surely there is some middle ground between the sandbox and full access? Well now there is.

If the server hosting a webservice has special xml file on it then the applet plugin will allow connections to that server. This special file is called a crossdomain.xml file and it must be present on the exact subdomain hosting the webservice.

To show it off, Josh offers an applet hosted on his home server that pulls photos from Flickr. Full details of the needed XML, plus a graceful degredation strategy, are provided in the blog, which he says is "the first in a series I'm going to call Java Doodles, highlighting the new features in JavaSE 6 update 10, now in beta."

Hey, Josh, I thought you were already doing a "doodles" series with JavaFX? Oh well, same basic idea, right?


Also in today's Weblogs, Kirill

Comments

"If the server hosting a webservice has special xml file on it then the applet plugin will allow connections to that server. This special file is called a crossdomain.xml file and it must be present on the exact subdomain hosting the webservice. "

I'd call that a massive security risk. It allows any mallicious website to circumvent applet security by creating such a file and putting it on their system (not even the client's system). Inject a mallicious applet into another (innocent) server's html (would require a hole in that server of course), and you can do a lot of things on that client that that client isn't aware of.

Yet another reason not to use Java 1.6. They do keep piling up...

There's also still the Flash-works-well-on-Mac-and-Java-doesn't problem.

As already mentioned elsewhere, if Sun doesn't:
  • get rid of the tray icon (and the ridiculous "Come visit us at Java.com" balloon);
  • simplifies the installation, ditching the OpenOffice ad, and ;
  • makes the installation package as easy to find as the Flash plugin (ie, "you need Java to run this applet, click here")
I seriously doubt that applets will make a comeback. And really, this is the last chance we've got. Screw up now and give up forever.

While I'm a bit puzzled about that file, my understanding is that it's a standard de facto in the Flash world, and it has just been adopted by Java 6. I mean, it could have been widely used to break systems in the Flash world, but we don't have notice of that.