The JVM security model is based on a sandbox, where the granularity of the authentication could be controlled. I can trust an Applet for things such as printers, but block it from disk access.

The person to whom I replied criticized the ActiveX component signing model for being too much of a hassle for the average user. If you agree, do you not also agree that setting up trusted applet policies is even more of a hassle?

 Active-X, OTOH, is an all or nothing proposition: Either you block it, or you give it access to everything - no choice in between.

Not quite. ActiveX components run with the browser's account permissions. You
can always run the browser under a restricted account, thereby letting the OS
set up the sandbox. In fact, account permissions are typically much more
configurable than applet policies.

I suppose one can make the case that Java failed based on performance and features. But one can also make the case that ActiveX failed because of it's flawed security model.

I disagree completely. ActiveX is a code packaging and delivery technology. Its only responsibility in terms of security is to provide secure transit, which is exactly what it does with component signing. Java-style sandboxing is brain-damaged because (a) the OS already provides permission-based security, and (b) the whole point is to take advantage of client resources. No wonder Sun eventually provided ways to poke holes in the sandbox.

In most cases you cite, these programs are not really confined to the Active-X framework (with the possible exception of shockwave). Yes some of them are participants in Active-X, but almost everyone of them are really just executable programs that you downloaded or installed just like any other native program.

Hardly. All of the things I mentioned run embedded within the browser or any other application supporting COM/OLE containment. "Regular" executable programs don't do that.

Don't believe me? Then go check the installation directories for these programs - likely scattered in the Progra~1 and system32 directory. Now tell me how many of these programs are confined to the "Windows\\Downloaded Program Files". I see Shockwave and you'll probably see a few others. Of the list you cite, how many are confined to this directory - and hence qualify as Active-X success stories?

I reject the notion that ActiveX components must be installed in any particular place to qualify. That's not what makes them ActiveX components - it's the ability to run embedded within ActiveX containers.

The long list of viruses that can transport themselves using ActiveX, and the long list of security holes that ActiveX is known to leave people open to is reason enough to not write home about its security model.

I'd like to see that "long list". I bet you'll find that very few viruses - if any at all - take advantage of any flaw related to ActiveX. All the recent big ones are simply Trojan-horse executables delivered via e-mail, exploiting nothing more than the ease with which popular e-mail clients allow users to launch attachments.

Corresponding lists for Java are much, much smaller. Yet Java is more widely deployed in browsers than ActiveX!

I doubt it, since Microsoft's JVM is an ActiveX component, as is the browser itself. If you use IE, you use dozens of ActiveX components even if you browse nothing but plain text.

That alone stands as darned good evidence that ActiveX is substantially worse than Java.

Sun took the time and effort to create trusted applets. That stands as darned good evidence that Java's original sandbox model was deeply flawed.

[...] concrete evidence strongly suggests that ActiveX is unhealthy for
your computer.

It may suggest that, but only to people who don't understand the technology. ActiveX is basically two things: native code delivery and embedded execution. In terms of native code delivery, blaming ActiveX for viruses is like blaming the postal service for letters carrying bombs or anthrax. Every argument you can make against ActiveX's native code delivery applies equally well to FTP and HTTP downloads. In fact, signing makes ActiveX safer than the alternatives. As for embedded execution, there's obviously a need; otherwise, Netscape plug-ins would never have been developed. And if you accept that there's a need, you must also accept that ActiveX components are in every way superior to plug-ins - they support component signing, they are way easier to use, and they can be used by other applications.