There has been some public discussion in comp.risks on signed binaries. ActiveX technology allows client software such as mail agents/browsers/etc. to run foreign code fragments. Unlike Java, there is no typesafety information attached to these fragments, which leads to many security problems.
ActiveX addresses security issues by relying on digital signatures to establish origin and leaving it to the user to make a trust decision based on certifiers. They have an API for creating, checking and manipulating signed code, though it is not clear how well their scheme handles revocation of credentials.
Recently, some German hackers showed how to steal money from Quicken users through ActiveX extensions. Here's the discussion that ensued on comp.risks:
My conclusion is that ActiveX technology is good for sharing code within a single security domain such as an intranet, but is unsuitable for use over the Internet at large. ActiveX can work well within an intranet because local auditing, security policies, and trust relationships already exist within an intranet. Any attempt to deploy ActiveX on a global scale is open to serious security attacks. A scheme such as Java, where the safety and security of incoming code can be checked independently without relying on trust, is necessary when going across domains of trust.
We believe that our work on the Kimera Project combines the advantages of both technologies. A Kimera firewall verifies the safety and security of foreign code at its point of entry into a security domain. A Kimera firewall can also modify the incoming code according to central security restrictions, make entries in a secure audit trail, and perform mandatory access control for an enterprise. It then compiles the Java code into native code, and forwards it to a client with a local certificate. The clients can be made leaner and smaller since they can defer verification and compilation services to their Kimera Firewall.