Thus spake Perry: |> solman@MIT.EDU writes: |> > I disagree for the simple reason that Java and Hotjava are not being |> > treated as trusted code in their applications. Applets are tightly |> > contrained in what they can do, |> You are incorrect. Applets are DESIGNED to be tightly constrained in |> what they do. You want to bet your career that there are no bugs in |> the implementation of this design? The thing keeping you from opening |> sockets or doing file-io is a very thin scrim. Are you *certain* that |> it is bug free? I'm not. What's with the facetious questions? Only an idiot would guarantee a piece of software to be error free. I am highly confident that there is very little probability of a raider applet doing significant damage. That's as much as I can say of any of of any of the systems I use... and its saying alot given that the thing is executing code it pulls off the net. Is there still room for cleaner code? Definitely, and I think we'll see some of it as Java goes Beta and then production. |> I like systems that are more fail-safe. About half a dozen |> simultaneous bugs would be needed to break some of my more secure |> firewalls, for example. Java does *not* provide security in depth. I think that the high level architecture of Java provides as much security as such a product can possibly provide. By the time Java becomes widely distributed (it is still in Alpha3), I expect it to have features that deny access to any applet not signed by somebody in a list the user creates, a sort of web of trust. On top of this layer, Java already offers rudimentary firewalls. The combination of these layers should be quite effective. Of course, Netscape will probably find a way to screw their implementation up :) JWS