Microsoft KB Archive/216434

= INFO: How Internet Explorer Determines If ActiveX Controls Are Safe =

Article ID: 216434

Article Last Modified on 3/22/2007

-

APPLIES TO


 * Microsoft Internet Explorer 4.0 128-Bit Edition
 * Microsoft Internet Explorer 4.01 Service Pack 2
 * Microsoft Internet Explorer 4.01 Service Pack 1
 * Microsoft Internet Explorer 4.01 Service Pack 2
 * Microsoft Internet Explorer 5.0
 * Microsoft Internet Explorer 5.01
 * Microsoft Internet Explorer (Programming) 5.01 SP1
 * Microsoft Internet Explorer 5.5

-



This article was previously published under Q216434



SUMMARY
When you use ActiveX controls on a Web page, depending on your security level, you may receive the following warning message in Internet Explorer:

An ActiveX object on this page may be unsafe. Do you want to allow it to be initialized and accessed by scripts?

This article explains how Internet Explorer determines if an ActiveX control is considered safe for scripting and initialization.



MORE INFORMATION
There are two ways to mark a control as safe for scripting and initialization:
 * Implement the IObjectSafety interface.
 * Provide the following registry keys for the control's CLSID under the Implemented Categories section:
 * The following key marks the control safe for scripting:


 * The following key marks the control safe for initialization from persistent data:

Microsoft recommends that you implement IObjectSafety to mark a control as safe or unsafe. This prevents other users from repackaging your control and marking it as safe when it is not.

The IObjectSafety interface allows a container to retrieve the control's initialization and scripting capabilities through its SetInterfaceSafetyOptions method. First, Internet Explorer checks to see if a control implements the IObjectSafety interface. If it does, Internet Explorer calls SetInterfaceSafetyOptions for the IPersist interfaces to check if the object is safe for initialization. When a control is first scripted, Internet Explorer first calls SetInterfaceSafetyOptions on the IDispatchEx interface of the control. If that fails, it calls SetInterfaceSafetyOptions on the IDispatch interface.

If the control returns unsafe for any of the interfaces, Internet Explorer warns the user according to the user's security settings for that zone (Internet, Local Intranet, and so forth).

If the control does not implement the IObjectSafety interface, Internet Explorer looks under the Implemented Categories section of the control for the keys mentioned above. If these keys are not present, Internet Explorer warns the user according to the security settings.

NOTE: The implementation of the IObjectSafety interface always takes precedence. If a control implements the IObjectSafety interface and returns unsafe for the IDispatch or IPersist interfaces, the registry keys are ignored even if they are present in the Implemented Categories section.

In some cases, a control may be "blindly" aggregated, and the aggregator may pass the QueryInterface function calls directly to the aggregated control. If the aggregated control implements IObjectSafety and marks itself unsafe, any registry entries in the aggregator are ignored. In this scenario, you can implement IObjectSafety explicitly on the aggregator and expose only the safe methods of the aggregated control.

