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:
Note Safety settings apply only to components downloaded in Internet Explorer.
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.
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:
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.
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:
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 http://www.microsoft.com/vbscript/ for information on the API calls and commands not implemented in VBScript.
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.