Timothy Sipples wrote: <post begins> I don't see any cause for alarm on servers, including on z/OS. To the extent the applet runtime environment is modified for security reasons I expect the server implementations to get updated for behavioral consistency, but it's no emergency in my view. Unless you make it a habit of affirmatively downloading Java programs from unknown sources and running it with limited or no external controls on the Java runtime. In which case you're already in trouble, particularly if you're using an operating system and Java implementation that the author of the malicious program anticipated and tested. <post ends>
to which my response is mixed. It is certainly true that nothing can be done to protect those who have "little or no external controls on the Java runtime" in place. It is also true that "alarm" is not in itself a constructive response to any problem. Still, the tenor of this post is almost dismissive; and that is, I think, inappropriate. What is needed is an intermediate-level response, one that falls between alarm and business as usual. It is also worth noting explicitly that Java is not intrinsically more problematic than other vehicles. It is the ubiquity of Java that makes this exploit so serious. Java was designed and initially implemented in a better, albeit naif time. The notion that systems must be designed and implemented defensively, that malicious attempts to corrupt or destroy them will be frequent, was not yet understood (and has not yet been fully assimilated). I have recently been discussing this issue with my very young students, using a book by Rufus Isaacs, Differential games, to do so. Isaacs, long ago at the RAND Corporation,. pioneered the notion that the best way for aircraft A to avoid midair collisions with aircraft B is for A to proceed from the assumption that B is trying to ram him. Isaacs then went on to develop a mathematical theory of games of pursuit and evasion that is more than just suggestive for problems of this kind. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
