Share via

Visual Basic Concepts

  • Article

Safety Settings for ActiveX Components

Safety settings are used to guarantee users that an ActiveX control will interact safely with their computer and its data. When you distribute ActiveX controls for Internet component download, you must assign safety levels to them. If you do not, and your controls damage users' computers or corrupt their data, you can be held legally accountable if the controls were signed.

You can help prevent these problems by verifying that your code is safe and marking it as such. There are two levels to safety in Internet component download:

  • Safe for initialization

  • Safe for scripting

Note   Safety settings apply only to components downloaded in Internet Explorer.

Safe for Initialization

When you mark a control safe for initialization, you guarantee that it will not perform harmful actions on the end user's computer, no matter what data or scripts are used in its initialization. A control that is safe for initialization does not write or modify any registry entries, .ini files, or data files as a result of initialization parameters. Safe for Initialization makes no claims about the safety of the control's methods, run-time properties, or the information it makes available to a script writer.

By default, Internet Explorer displays a warning and does not download controls that have not been marked safe for scripting and initializing. You can designate your software as safe for scripting and initialization when you use the Visual Basic Package and Deployment Wizard to package it for Internet distribution.

Safe for Scripting

When you mark a control safe for scripting, you guarantee that no script can cause the control to damage the users' computers or data. Controls marked safe for scripting should not be able to obtain unauthorized information from the users' computers or corrupt their systems.

Before you mark a control safe for scripting, you must verify that it does not perform any illegal activities or allow openings that could be used to cause damage. In general, controls that can automatically obtain any information about the user and expose that information to a script writer are not safe for scripting. Such seemingly innocent activities can be considered criminal acts in some countries.

In particular, a control should not perform the following actions as a result of scripting:

  • Insertion or retrieval of custom, script-defined registry and .ini file information. In other words, users should not be able to specify through a script which registry or .ini file information to insert.

  • Insertion or retrieval of variable registry and .ini file information that is not owned by the control.

    Note   It is acceptable for a control to insert and retrieve registry and .ini file information that is predefined when the control is distributed, belongs only to the control, and exists for the purpose of helping the control manage its internal functions.

  • Reading a file from a hard drive with a name specified by scripting.

There is a fine line between safe and unsafe actions. For example, an ActiveX control that always writes information to its own registry entry may be safe, but a control that lets you name that entry is unsafe. A control that creates a temporary file without using any initialization or scripting value may be safe, but a control that allows the name of the temporary file to be assigned at initialization or by scripting is unsafe.

Prior to marking a control safe for scripting, it is advisable to create documentation recording the justification, taking the same type of care due any legal contract. This documentation can be included in the .inf file for your control. Your documentation might include:

  • A review by an expert, external developer who understands both the source code and VBScript.

  • A table listing all exposed methods, events, and properties of the controls.

  • A table listing all the files opened, API calls used, and the information retrieved or written.

If there are any dependencies or data transfer between the elements of these two tables, then the control is probably not safe for scripting.

Note   Determining whether a control is safe is not a trivial exercise. To understand what type of functionality you should not implement for your control, you might begin by noting the API calls and commands not implemented in VBScript. See https://www.microsoft.com/vbscript/ for information on the API calls and commands not implemented in VBScript.

Limitations of the Safety Flags

A control marked safe for scripting and safe for initialization is not necessarily safe to use. The previous two sections list actions that the control cannot perform as a result of initialization or scripting, but a control could still perform these unsafe actions at other times.

For example, suppose you create an ActiveX control that could reformat your hard-drive after 10 uses. This action does not occur as a result of scripting or initialization, so you can mark the control as safe. Of course, the person who writes such a control is liable for the usual penalties reserved for virus writers.

Responsibility for ensuring that adequate safeguards are in place belongs to the developer, not to end-users or to HTML authors. If you as the developer fail to include adequate safeguards, you can be held legally responsible.

The bottom line in ensuring the safety of your software is to always have your code independently reviewed by a seasoned developer who understands the issues well. You may want to include information about this review in the .inf file for your download.

For More Information   See "Designing Controls for Use With HTML" in "Building ActiveX Controls" for guidelines for making your controls safe for scripting and initialization. See "Advanced Customization for Internet Component Download" for more information on including information in the .inf file.