From: Ray Cromwell <rjc@clark.net>
Date: Sat, 18 Nov 1995 02:54:29 +0800
To: fc@all.net (Dr. Frederick B. Cohen)
Subject: Re: Java & Netscape security  [NOISE]
In-Reply-To: <9511170006.AA17075@all.net>
Message-ID: <199511171827.NAA26980@clark.net>
MIME-Version: 1.0
Content-Type: text/plain


> 	When Postscript allows writing to files, most Web browsers
> become insecure - including Netscape, including HotJava.  If the only
> commonly available postscript programs are insecure, the products have
> hooks designed to allow postscript to be used automatically to interpret
> programs from over the net, and servers commonly provide information in
> postscript format, the enabling technology (i.e., Netscape and Hot Java)
> is responsible for the vulnerability.

   [This is my last response on this subject.] This is a non-sequitur.
Providing hooks for third-party add ons does not make Netscape
responsible for damage done by third party products. If you believe
this is true, find me a legal precedent for it. It doesn't make sense
on a purely intellectual level. If you produces a product that has the
ability to be ugpraded, and someone upgrades it with dangerous
third party products, how can you control that? The only way to assure
against it is to not allow upgrades of functionality except by 
your own company. This throws the whole idea of reusable software,
device independence, and building "platforms" right out the window.
It's the kind of logic that seeks to make bars responsible for
drunk drivers. Indeed, Microsoft and Apple should be held responsible
for dangerous "applications" that their computers can execute.

   I don't know anyone who has a postscript viewer configured in Netscape
and I suspect the vast majority of people using Netscape don't even
have the knowledge to do it. Your comments are not significant and
the threat is minor. If you had actually exposed a threat to the
JavaVM/Classloader model, which might be installed on a sizable
portion of browser machines, you might have a point. But since
your postingas have made it clear that you haven't read or understood
the Java papers (besides the white paper), nor have you looked at
the actual implementation, your comments are essentially meaningless.
You seem fixated on what is, a semantic argument about what "safe"
or "secure" means.  (e.g. your comments on MD5)  You expect these
words to have a binary meaning. Either something is safe/secure or it isn't.

The world is a lot more fuzzy than that.

-Ray