Q: What advice would you give to technology managers who are concerned about Java security?
Phipps: I'd tell them first to start deprogramming what they've heard about Java in the press.
Last year some graduate students at Princeton University did research on Java and concluded that there
were apparent problems. As a result, Java got some bad press. If you read their reports, however, you'll
see they're measuring Java against standards that apply only to an academic nirvana and not the real
world. In the real world, Java's security is the best there is to date.
Q: So you're saying Java is secure?
Phipps: Anyone who tells you that your system can be entirely secure is a liar. In evaluating
Java you have to weigh the business benefits versus the business risks. And you have to focus on three
areas.
Q: Which are?
Phipps: Authentication, verification, and local policy. Suppose a lump of binary stuff from the
gods has fallen into my lap. I need to know where that code came from before I use it--that's the
authentication. Verification tells me that the code won't do anything nasty to my system if I accept it.
The third factor allows my organization to set up parameters for use, such as "don't allow storage on local
disk" and the like. Java 1.1 has a security management feature that enables you to do that. With Java,
security is built in from the ground up. Security is part of Java; with Microsoft, security is a retrofit.
Q: How does this differ from Microsoft's Authenticode?
Phipps: Microsoft's controls are old fashioned. They view our theoretical binary lump as a
single entity. You either say yes or no to the entire entity, and once you accept it you can never
get rid of it. Java 1.1 allows you to do a much more fine-grained approach to authentication. You can
evaluate each different class of file within that lump and accept or reject those files on an incremental
basis. Then, with Java you can also verify if that lump is going to work and verify that each class
file is safe. With ActiveX, Microsoft doesn't even attempt to do this. With Microsoft's Authenticode
you're trusting the relationship--you trust what comes to you and you trust who created it. You need
more than that. Java extends that trust with verification and local policy. Java's approach is to make
more than the relationship secure. It's to make the user secure in his or her own right.
Q: So with Java you know where the binary lump came from and can verify whether you can run it
safely on your own computer?
Phipps: And, with the local policy controls that are built into Java you can set parameters
as to how that code can be used. As an example, you may not want it to touch your hard disk. Java puts
the controls in your hands and allows you to set them yourself. Java gives you the flexibility and the
controls you need to manage your own security.