Security, AJAX, and Java

Back from OSCON, it was a very good, enlightening trip. I have a stack of things I want to learn and experiment with now. I went to Simon Phipps and Tom Marble's talk about Sun's open source strategy, where for the most part they focused on Java. Tom talked about getting Java into GPL distributions of Linux like Debian and Ubuntu – quite a success story and a great example of a distributed, multi-company team working together to solve a real problem. Simon talked about open sourcing Java – where Sun is, where we hope to get to and by when. He said that there are a lot of constituents, some who want to see Java open sourced in August, and others who are looking at, say, 2008 :). He said he expects it to happen in incremental phases, with the majority of Java being open sourced by this time next year.

Speaking of Java, I just read this article about security teams uncovering a major JavaScript security hole that allows a script in a browser to scan your network without restraint, from finding and modifying your router configuration to discovering internal network resources and sending commands to them. This is on the heels of a nasty Yahoo! Mail worm that took advantage of AJAX.

Now, I love what AJAX can do for improving the quality of web-based applications. But I feel a bit heretical here to suggest that perhaps there is value in the Java sandbox model, and the fact that with Java you can control which providers are granted access to your system. It is not to say that the Java security model can not be compromised or improved, I suspect it probably can. I am just saying that with JavaScript and AJAX you really have no control at all – you can either enable JavaScript, or not, and that's about it. Disable JavaScript, and a whole suite of very compelling applications, such as Google Maps, are disabled. Enable it, and you expose yourself and your company to serious security risks.

When I talk to people about running Java on in the browser, the common complaints I hear about are the extra step of having to install the plugin, issues around version management, the overhead of having to obtain a certificate from a CA, getting your apps signed, and getting users to press OK when presented with a signed applet. I'm sure there are others and if I asked I'd get a whole litany. I think Java Web Start solves some of these issues, but I think we can continue to improve upon this.

The other complaint of course is that the Java programming language is not for everyone, particularly those used to the fast turnaround and simplicity of dynamic languages like Perl and Ruby. But I am seeing a very interesting trend of using Java as the runtime environment for scripting languages like JavaScript and Ruby.. It would seem to me if you could take advantage of the Java runtime's security, ubiquity, and rich set of APIs, while being able to pick and choose the right language for the job, you get the best of both worlds.

So, we can spend who knows how long trying to solve the security issues of JavaScript and AJAX. But maybe, just maybe, we should take another look at running Java in the desktop and the browser... Now that Java's being open sourced, perhaps this is something we can all work on together, so that our users can have both power and security