Developing Flash Lite 2.x and 3.0 Applications

Local file security

In Flash Lite 2.x, local SWF files are allowed to interact with and load data from other SWF files, whether local or remote. This creates a security vulnerability because an untrusted local SWF file, downloaded (for example) as an e-mail attachment, can access private data stored on the device and send it back to the content author via an HTTP connection.

Flash Lite 3.0 introduces a new security model based on the Flash Player 8 security model. All SWF files are placed in a "sandbox" when they are loaded into the Flash Lite player. SWF files are assigned to different sandboxes according to their point of origin.

SWF files from the network are always placed in a remote sandbox that corresponds to their domain of origin. Network SWF files can read the data from their domain of origin only. They cannot access data from other domains unless those domains explicitly grant permission to the SWF file making the request. For example, a SWF file from a.com may read (using XML.load, for example) from the server at b.com if b.com has a policy file that permits access from a.com (or from all domains). A SWF file from a.com may cross-script a SWF file from b.com (calling an ActionScript™ method in the b.com SWF file, for example) if the b.com SWF file calls System.security.allowDomain to permit access from a.com.

SWF files from local origins (local file system) are placed into one of three sandboxes, as follows.

Local With Filesystem SWF files may read (using XML.load, for example) from files on local file systems, but they may not communicate with the network in any way.

Local Trusted SWF files may read from local files, interact with any server, and script any other SWF file. (In Flash Lite 2.1, all local files are effectively in this sandbox.)

Local With Networking Sandbox SWF files are allowed to communicate with other local-with-networking SWF files, and send data to servers (using XML.send, for example).

NOTE

 

This new security scheme affects the functionality of almost all ActionScript that involves data loading or cross-scripting, including extremely common functions like getURL, loadMovie, loadMovieNum, loadVars, loadSound, XMLSocket.send, and XMLSocket.load. For a comprehensive list of all API functionality that is affected by security, please see Flash Player 8 Security-Related APIs (PDF) on the Flash Player Developer Center website.

See Flash 8 product Help for information about how the Flash 8 Player's security model works. When using this Help, please note that the following differences exist between the Flash Lite 3.0 and Flash Player 8 security models:

  • Trust management is done by the host application in Flash Lite.
  • No trust configuration files are required in Flash Lite.
  • SWF file developers, manufacturers, and carriers must make all security decisions in Flash Lite. There is no user-mediated trust, or Settings Manager. However, the host application may provide a mechanism by which users can make limited security decisions. For example, the host may allow users to designate a particular SWF file as trusted.
  • Prohibited operations fail silently; no dialog box is displayed in Flash Lite.