Local Security Scenarios

The following scenarios are meant to help illustrate the effects of the new local security rules in Flash Player 8.

User Scenario: Flash Authors and Colleagues

The Flash Player 8 local security rules are designed to help protect end users. For end users, local SWFs are generally some form of final content—something that was downloaded from an Internet source or installed as part of an application. For Flash authors, however, local SWFs are frequently just a temporary copy of content in development—usually content that is bound for eventual deployment on an HTTP server. You may sometimes encounter security restrictions that prevent your content from working as you expect, simply because you are previewing your SWFs while they are still local files.

Consider the following three ways of testing Flash content in development, in order of increasing complexity:

• Test Movie in the Flash authoring application: The Test Movie players don’t enforce the new local security rules at all, so you shouldn’t see any issues in Test Movie mode.
• Using standalone players or browser players to view local SWFs: This raises the possibility of problems resulting from the new rules—such as, for example, when a SWF calls getURL with an HTTP URL.
• Placing SWFs on an HTTP testing server and viewing them with a browser: This form of testing is once again immune from local security problems because SWFs viewed over HTTP are not local SWFs; they operate under the Flash Player remote security rules, which have not changed in Flash Player 8.

Ideally, to avoid undesirable security restrictions during preview-in-browser testing, it would be helpful if Flash Player could distinguish Flash content under development from untrusted SWFs downloaded from Internet sources. Unfortunately, there is no reliable automated way for Flash Player to do this.

Instead, you may find it helpful to configure Flash Player to trust all SWFs in a certain region of your local filesystem. For example, if you store all of your Flash work under C:FlashSites, you can visit the Settings Manager and add the directory C:FlashSites to your list of trusted paths. Thereafter, whenever you view any SWFs within C:FlashSites or any of its subdirectories, Flash Player will place those SWFs in the local-trusted sandbox, thus avoiding any security-related failures. Once you do this, be sure not to place SWFs into your trusted area from sources you do not trust! Keeping your own local SWFs separate from other authors’ untrusted SWFs will allow you to benefit from the same increased protections that all Flash Player end users benefit from.

Let’s imagine that you’ve visited the Settings Manager and configured a trusted directory. Now your own work proceeds uninterrupted by security problems. However, you may need to share your SWFs in development with a variety of colleagues—HTML authors, Flex developers, bitmap artists, and so on. Or you may wish to show your SWFs to managers or clients. Some of these people will probably not have set up trusted directories on their computers, so if they open your SWFs as local files and your SWFs attempt to communicate with the Internet (for example, by calling getURL), or with HTML pages, the local security rules may cause your content not to work as intended while it is being previewed locally. In addition, some of these “extended family” users probably will not have FlashAuthor.cfg installed on their computers, so if your SWFs are version 8 or higher, those people won’t even see warning dialog boxes informing them of the reason for failure.

Unfortunately, there is no single recipe for handling these extended-family issues. The basic problem is that when Flash Player runs on your colleagues’ computers, it has no way of distinguishing your (temporarily) local SWFs from potentially untrustworthy SWFs that came from Internet downloads.

The surest way to solve extended-family issues is to post your SWFs on an HTTP testing server and then send out links, rather than sending your SWFs around as files. However, this is sometimes inconvenient or impossible—for example, when you don’t have a private HTTP server or when you need to share SWFs with people outside your own network and you don’t want to post the SWFs on public servers. Thus, you may need to consider other possibilities:

• Create SWF projectors
• Publish your SWFs as local-with-networking rather than local-with-filesystem
• Create installers for your SWF projects that set up FlashPlayerTrust files
• Send Settings Manager configuration instructions to your colleagues
• Ask your colleagues to post the SWFs on servers of their own

The best solution for you will depend on your situation.

User Scenario: Flash Player End Users

For the most part, the new local security rules should be invisible to Flash Player end users. However, as just described, it is possible that some users may have local Flash applications that were written to communicate with the Internet. When these users upgrade to Flash Player 8, they may begin seeing dialog boxes informing them of potentially insecure operations.

A user’s options in this situation are simple. They may decide to ignore the problem, they may contact the application vendor to inquire about a fix, or they may elect to try and fix the problem themselves.

Users who decide to fix the problem may click the Settings button in the warning dialog box. This will take them to the Settings Manager, where they can read about local security, choose Edit Locations > Add Location, and select a local path to trust. It is not always trivial to figure out what path needs to be trusted; sometimes trusting just the single path that appeared in the warning dialog box is enough but sometimes multiple SWFs may be involved in an application. In such situations it will sometimes be necessary to trust the entire directory containing those SWFs. After each guess at a trusted path, the user will have to return to the original application and restart it—for example, by refreshing their browser.

Upon reaching the Settings Manager, users may also decide to select Always Allow to trust all SWFs of version 7 and earlier. This is a simpler fix than determining paths to trust but it reduces users’ security in return for this convenience.

Application Scenario: Fixing a Hybrid Help System

Let us imagine that you are maintaining an application that uses local SWFs and you receive inquiries from your users who say they are seeing Flash Player Security dialog boxes informing them of potentially insecure operations when they view certain parts of your application. Let’s say your application is a hybrid help system, which is a common form of local SWF application: a collection of HTML and SWF files that communicate with each other using getURL and possibly fscommand.

A first step should be to determine how serious the problem is. Is this a crucial component of an important application with a major break, or has a small feature broken in a hobby project? Are you willing to redistribute fixed files to all your users? The answer will often be yes, but be sure to validate the need for a fix before investing in one.

One option is to simply tell users to visit the Settings Manager and trust the path where your help system resides. However, this may involve too many steps for some users to complete, and may also make users uncomfortable if they do not understand the implications of their security decisions.

Another option is to republish your SWFs as local-with-networking, or postprocess them using the Local Content Updater. If the only security violations that your content produces are from calls to getURL, this should be sufficient. However, if your SWF and HTML files script each other using fscommand, getURL(“javascript:…”), or other hybrid scripting operations, the local-with-networking sandbox is not enough to restore your application to its former state; you must place your SWFs in the local-trusted sandbox.

If your users are technically savvy, you can provide them with a FlashPlayerTrust file and instructions on where to place it. Alternatively, you can create a small script or program that automatically creates a FlashPlayerTrust file in the appropriate location. If you know where your SWFs are installed, you can simply trust the directory where you expect them to reside. However, if users have chosen a non-default install location, you may need to prompt users for the location where they have installed your content, or search their filesystems for your SWFs.

Application Scenario: Occasionally Connected Contact Manager

For our final scenario, let’s imagine you are building a local SWF application that is intended to periodically synchronize data with an HTTP server and serve as a local repository of that data at other times. The data in question might be an address book, so think of this application as an “occasionally connected contact manager.”

Let’s say you’ve determined that you need net-send privileges, but not local-read privileges—for example, you won’t need to read local XML files for configuration. So, when publishing your SWF(s), you select Access Network Only under Local Playback Security in the Flash publish options. Now your SWFs are free to use getURL, XML.load, and other HTTP operations.

Now you set about connecting your application to the HTTP data source for synchronization. Let’s say you’re using XML.sendAndLoad() to exchange simple XML data. Because XML.sendAndLoad is a net-read operation, you need a policy file on the HTTP server that you’re synchronizing with. Let’s say you want your policy file to govern only the relevant data, not the whole HTTP server—so you put the policy file next to the XML data source and you call System.security.loadPolicyFile in your client SWF, specifying the location of the policy file. The policy file looks like this:

<cross-domain-policy>
   <allow-access-from domain="*" /> 
 </cross-domain-policy>            

The policy file must trust all locations (“*”) so that your local-with-networking SWF(s) can load data from your server, in keeping with the global permission principle.

That should do it!