Xtras for use with Shockwave 7 must be marked "safe" by their developer and recompiled using the Xtras Developers Kit (this can be done with V6 XDK - see below). By doing so, the Xtra developer is assuring that the Xtra does not pose a security risk to the end user's system. Simply following the steps below will allow an Xtra to work with Shockwave 7 movies without any further modification.

If you wish to take advantage of the auto-downloading of Xtras (new to Director 7), then a special "Xtra packaging" tool must also be used to create a downloadable package. Auto-downloading of Xtras can be used to download any Xtra, whether it is marked "safe" or not. A downloaded Xtra which is not marked "safe" will not be available for use in Shockwave; one which is marked "safe" will be available. Until this packaging tool is made available, an Xtra can be marked "safe" however it will have to be manually installed in the Shockwave Xtras folder in the end userssystem. Please visit the Xtra Developers Center regularly for news regarding the availability of the Xtra packaging tool.

What conditions must be met in order for an Xtra to be declared "safe"for Shockwave?

Internet security and safety are complicated topics, and a complete discussion of them would be impossible in the scope of this TechNote. Operations that might seem benign can in fact have surprising security implications.

It is important to think through what your Xtra does in combination with other functionality that might be available to a Shockwave movie. For example, an Xtra that allows read-only access to files on the user's machine might at first glance seem to be safe, because it couldn't destroy anything. However, because Shockwave movies can communicate through the Internet, a file-reading Xtra could be used to transmit the user's private data. Similarly, an Xtra that allows sending e-mail could be used to quietly send spam from a user's account while that user is playing a game. Neither of these Xtras would be appropriate for marking "safe for Shockwave".

In general, you can allow unsafe operations so long as the Xtra first confirms with the user that the operation is OK. For example, the e-mail Xtra above might present a dialog telling the user it is about to send mail, and allowing the user to cancel. So long as there was no way to bypass this dialog from Lingo, such an Xtra could be marked safe.

If the Xtra registers itself as "Safe for Shockwave," the developer must verify that all of the following statements are true:

It is not possible to use any function of the Xtra to obtain data from a local hard drive, unless the information is already considered public. Files in dswMedia folders are public (but not paths to those files). Contents of files readable by getPrefs are also (but not paths to them). (Machine configuration information, such as OS platform, is not considered protected data.)

File and directory names are considered data that must be protected.

It is not possible to use any function of the Xtra to obtain any information from within the end user's local network (unless that information would also be accessible from outside the local network). Examples of data that must not be disclosed include local network traffic, local IP addresses, MAC addresses, and subnet rules. The Xtra must not make it possible for a Shockwave movie to bypass network security mechanisms such as firewall access, control lists and proxy servers.

The Xtra cannot be used to install native (or non-sandboxed) code on the client machine unless the source of that code has been authenticated and the end user explicitly approves the installation.

The Xtra takes reasonable efforts to minimize denial of service attacks. For example, the Xtra must not make it possible to shut down the machine, fill up the user's hard drive, or otherwise act as a nuisance to the end user.

If the Xtra permits functionality which might sometimes be a security risk, it first explicitly warns the end user and requires confirmation before proceeding. The Xtra must not permit Shockwave movies to disable this warning however it may permit the end user to disable the warning.

This is not meant to be an exhaustive list of safety and security concerns; it merely highlights some of the more common issues. If there are other ways this Xtra could be used to violate the safety of the end user's machine, it must not be marked "Safe for Shockwave".

Note:Schemes where an Xtra requires a password or other secret from a movie before performing unsafe operations are inherently unsafe. Do not use Lingo-supplied passwords as a way to get around Shockwave Xtra safety requirements. It is very easy to extract a password from a movie that uses it, and then use that password to violate security on end user's machines.

Steps to Make an Xtra "Safe for Shockwave"

After insuring your Xtra does not cause any security risk, you have to recompile the Xtra for use with Shockwave 7. There is no problem with marking Xtras "safe" using the D6 headers. You'll just need to add a couple of #defines from the D7 headers.

The "safe" mark is simply a 1-byte MoaBool TRUE value for the kMoaDictType_Bool key kMoaMmDictKey_SafeForShockwave ("safeForShockwave"). In your Registration proc, you have something like:

err = pCache->lpVtbl->AddRegistryEntry(
pCache, pXtraDict, &CLSID_foo, &IID_bar,&pRegDict);

add:
#define kMoaMmDictKey_SafeForShockwave "safeForShockwave"
#define kMoaMmDictType_SafeForShockwave kMoaDictType_Bool
if (!err)
{
MoaBool bItsSafe = TRUE;
err = pRegDict->lpVtbl->Put(pRegDict,
kMoaMmDictType_SafeForShockwave, &bItsSafe, sizeof(bItsSafe),
kMoaMmDictKey_SafeForShockwave);
}

That's it. (The #defines are included in the D7 headers).

By adding this to your code, you certify that you've considered the security implications of your Xtra, and installing it for use it in a browser will not undermine the security of the computer on which it is installed.

Products affected