Mike McNally wrote: | Seems to me that putting together an ActiveX control that "sneaks" its | way through the firewall risk policy wouldn't be hard. Unless the | applet scanner actually simulates execution of the control under a | variety of input conditions (and we know that's not likely) (but prove | me wrong, please) there's not much it can do other than poke around and | check what other DLL's the thing wants to access. It might be a bit | harder to be sneaky in Java, but I certainly wouldn't bet I could look | at an applet and guarantee its safety to any threshold (if I could, why | not just do that in the browser?). Browsers are big, complex bits of technology. If you built an applet verifier that ran on a firewall, it could be substantially smaller than the 6mb of Netscape3.0 (SunOS). Smaller code is easier to verify, and less likely to contain bugs. In addition, you could be more confident that your policy goals are met in controlling what applets enter the perimiter that the firewall deliniates. Deploying new browsers to every desktop can be challenging. If you have a java-gw, there is a lesser need for new browsers everywhere in response to bugs. Also, you may be able to get the source to a verifier, but not to the browser. Doing a good job in real time would be very tough. We need signed capacity requirements, and an organization that will stand by its certifications of security. I have at least one client who would pay for certified ok applets. (Not certified origin, certified non-malicious, for various values of non-malicious). Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume