Code signing can guarantee that code is trusted to be operated by an end user. However, allowing ActiveX controls to be accessed from scripts raises several new security issues. Even if a control is known to be safe in the hands of a user, it is not necessarily safe when automated by an untrusted script. For example, Microsoft Word is a trusted tool from a (presumably) reputable source, but a malicious script can use its automation model to delete files on the users machine, install macro viruses, and worse.
We therefore require that controls vouch for their ability to be safely scripted. They do this either by supporting a simple interface (IObjectSafety) or through entries in the registry. Such an entry promises that, no matter how malicious a script is, the automation model of the control does not allow any harm to the user, either in the form of data corruption or security leaks. (Of course a control can lie and say its safe for scripting when it isn't. But if control writers really want to be malicious there is no need for scripts to be involved at all--they can do whatever damage it wants directly in the control implementation.)
If a control is not marked as safe for scripting, the user will receive a warning dialog whenever the control is inserted on an untrusted page, asking them whether to the object should be visible from scripts. (This is only at medium security level, at high security, the object is never visible to scripts, and at low, always visible.)
This security mechanism allows controls to be authored which support interesting, potentially unsafe capabilities, while only allowing those capabilities to be used from pages which the user trusts.
Another potential security hazard is initializing a control's state using untrusted data. When a control is created, it can be given data from an arbitrary IPersist* interface (from both local and remote URLs) for initializing its state. This again is a potential security hazard because the data could be coming from an untrusted source and the control might do harmful things when given bad or private data.
We therefore define another category of controls--controls which are safe for initializing from persistent data. These are controls which are guaranteed to do nothing bad no matter what data they are initialized with. The user receives a warning, as described above, if a untrusted page attempts to initialize a control that is not safe for initialzing.