In contrast when the web site includes Java material I grant that program only
There are clearly two distinct ideas of security here, each with merit. I find fault with both however.
The ActiveX controls model presumes that program authors that you trust will provide programs that do you no harm and further that you will have no need of programs from those that you do not trust. ActiveX controls can do things for me that Java applets cannot such as create new files and modify old ones.
In contrast the Java applet is limited as described above, and cannot do some useful things for me. On the other hand I need not trust the programmer, nor even know the programmer.
The ActiveX controls user must hope that trusted programs will do only what he wants while Java Applet need not be trusted. There is clearly use for both ideas.
One shortcoming with ActiveX controls is that while the code may be signed there is no provision for the author signing a description of what that code does. I must trust the signed code to take no harmful actions without consulting me.
If some programmer sends signed code that does damage something, I cannot be sure of finding him and I cannot even be sure of finding evidence to determine which signature I should cease trusting.
Java has had some security failures in its implementation which were fixed fairly quickly with minimal impact on legitimate applets. The rate of finding such failures has abated.
An ActiveX controls programmer is free to send data from my machine anywhere on the Internet. I am unlikely to discover this or discover who did it. Some software vendors may consider it ethical to ascertain what applications are installed on my machine. I have no way to know that this is going on. Builders of the browser that I use are in an ideal place to do the same thing but I need trust few browser writers.
Some electronic money proposals would have me install a tamper proof card in my machine to hold a secret key that would let me authorize payments or even produce electronic checks. An ActiveX control would be able to abuse that card to produce checks to whomever with my signature and deliver those checks. They would not need to steal the secret on the card. I would not know which program did the deed and whom to cease trusting. ActiveX controls are not the only threat in this regard, but ActiveX may bring software from a larger set of programmers than any other technology.
The substantial cost with ActiveX controls is deciding who to trust and dealing with the wrong decisions. The substantial cost of Java is the applet’s inability to do some useful things for me.
You can have the best of the two worlds but not without involving the user with more security concepts. Java seems ideally suited to solving this problem with its secure object references which can be made to behave as capabilities. Java currently delegates security decisions to the Security Manager which is a module that the Browser writer and perhaps the sophisticated user can replace. A different security manager can allow file access. Unfortunately the security manager is not provided with context necessary to distinguish good acts from bad. The security manager is situated to distinguish classes of actions rather than to allow actions on distinguished classes of objects. On my machine I am not concerned whether an applet can write files but which files it can write. Electric Communities has produced the language E which is a pure capability language, as is Joule, but it happens to run on the Java platform. These ideas descended from the language Joule
May 2015: Microsoft plans to cease supporting ActiveX. They describe the history of Microsoft browser security measures.