Java: Online marvel or menace?
Internet browsers like Mosaic, Netscape Navigator, Microsoft Internet Explorer and the earlier Gopher were more like the former than the latter. They retrieved files, which they rendered and displayed in one of the formats they understood, such as ASCII text plus HTML tags, and possibly also GIF graphic formats. Otherwise, they invoked a "helper app" to render and display other formats.
If the item was a program, accessing it meant it would be run remotely--possibly passing some parameters along--and the output would return to the user as an HTMT-formatted file.
This method severely limited what a Web developer could have its site do, and what a user could do on the Web. Then along came Java, a programming language based on C++ that had been invented by folks at Sun without any particular use in mind.
According to Sun's "What's Java?" document (at http://java.sun.com--not surprisingly, the best place to start looking for Java-related information), it is "a simple, robust, object-oriented, platform-independent, multi-threaded, dynamic general-purpose programming environment. It's best for creating applets and applications for the Internet, intranets and any other complex, distributed network."
In terms of the Web, Java comes in small applications, also known as "applets." To run them, you need a program capable of executing Java applets, such as a "Java-enabled browser" like Sun's own HotJava, some versions of Netscape's Navigator, and presumably sooner or later, Microsoft's Internet Explorer.
When you encounter a Java item on a Web site:
* Your browser checks to see if you've already got a current copy of the apples downloaded;
* it retrieves the apples if you don't already have it;
* it retrieves any associated data or parameters;
* it executes the apples, using the data.
There are many legitimate motivations for something like Java. Often a graphic or sound the creator wants to deliver can be "expressed" as a much shorter (and therefore faster-downloading) stream of bits consisting of a program and a little bit of data. One example might be a bunch of screen-high letters.
Another motivation for Java is that helper apps may not be available for the data type you have in mind. Or users might not have the necessary applications on hand for the data, so they simply get them, automatically, "on demand." Java used this way reduces the load on the remote Web server. It makes interacting with the user much simpler--or allows things to be done easily that couldn't otherwise be done. Finally, Java means you can have 'platform-independent" programs instead of different versions for Windows, Mac, Unix, etc. That's the good news.
The part that should make users and network managers nervous is that you're being asked to download programs from the outside world and run them on your computer. In theory, applets can't do anything untoward, be cause they're kept from doing so by a combination of the nature of Java, the security management system and how things are configured. That's the theory.
But how trusting are you? How confident do you feel in the programming skills of outside, unknown people--the folks who created the Java parts of your browser, or who wrote a given apples? How much do you trust these people not to put in nasty code that trashes your files, or snoops through them and E-mails back interesting pieces?
Are you comfortable enough to let these programs run on the same computer whose disk houses your important work files (or personal files)? Not me.
If you're a senior corporate technical manager, are you comfortable letting your users run Java-capable browsers and trust they'll avoid unapproved Java applets ... or will remember to disable Java? I wouldn't.
I'd consider running Java on a computer that didn't have anything I cared about. But even then, I'd be paranoid.
My concern is not whether Java applets and the Java program that runs them are secure. I am concerned about whether the technology is mature in terms of rigorous testing and user understanding.
We've seen enough bugs, holes and flaws reported in Java, and in Netscape's implementation of Java, over the past months that this worry is legitimate. Many of these were reported in the RISKS online journal, or incomp.security.* Newsgroups. (One easy way to find them is by searching AltaVist<http:www.altavista.digital.com> using keywords such as +newsgroups:comp.risks +Java +security.)
Teams of researchers have found design flaws that would allow apples writers to bypass Java's security restrictions, which in turn means that an apples could read and write files on your hard disk, and execute code with far too much systems permission. For instance, David Hopwood, a UK-based Java researcher, reported ways to get around Java's security facilities (see <http:/ /ferret.lmh.ox.ac.uk/~david/java/bugs>).
For examples of "hostile applets," see <http://www.math.gatech.edu/~mladue/HostileApplets.html>. Java's hardly the only dangerous security hole in Internet access. At one point Microsoft Exchange apparently would extract any binaries in your incoming mail and plop them right on your desktop without any virus checking or other approval. Netscape's security had its own share of bugs reported, and the sad reality is that far too many breaches succeed because administrators failed to reset vendor-default passwords or close well-known security holes.
Heck, it's not clear we can trust the programs we buy from established vendors (and even these are turning out, at times, to have viruses on the actual shipped CD-ROMs). But Java is one of the few that raise the specter of random programs entering our computers from the outside world and wreaking havoc.
Disabling Java is the only current way to disallow some of these attacks. (See http:/ /ferret.lmh.ox.ac.uk/~david/javalbugs/for more information.) If I were you, I'd turn it off, except on a non-networked PC or two that didn't have any credit card numbers or important information on their disks.
To be fair, Java has helped show what a true client-server interaction can be, using the Internet or within your corporate intranet, in the best of cases. Even if, as many of us hope and expect, Java itself goes down in flames, it has set the stage for true distributed and client-side processing. Go to the bookstore to see how much interest there is: the shelves hold dozens of Java-related products and over 130 Java-related books.
Meanwhile, I'm ready for a cup of tea--hold the Java, please, for another six months or so.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Technology Information; Putting the Internet to Work|
|Date:||Sep 1, 1996|
|Previous Article:||An (almost) unwired world.|
|Next Article:||Standards for CTI: hard choices ahead.|
|Gang of Five Team on Java Programming Certification.|
|Seize the mouse.|
|Wireless Java: Developing with Java 2, Micro Edition.|