15 October 2008
Note: The following article is for developers only. Customers who are experiencing Adobe Flash Player installation issues should begin troubleshooting in the Flash Player Support Center.
Adobe Flash Player 10 offers a variety of new features and enhancements as well as some changes to the previous behavior of Flash Player. Some of these changes may require existing content to be updated to comply with stricter security rules. Other changes introduce new abilities that were previously unavailable or restricted by security rules.
Please review the following security-related changes made in Flash Player 10. Use this list to determine whether you will need to make changes to your existing content for it to function correctly in this Flash Player release.
Changes that may require action:
New security-related features that are available:
Adobe tightened the rules regarding Flash Player and cross-domain policy files starting with Flash Player 9,0,115,0. Due to the impact of these changes and how they would affect many existing websites, the changes took place over a series of three phases in multiple releases of Flash Player.
Flash Player 9,0,115,0 implemented Phase 1. Following that, Flash Player 9,0,124,0 continued with Phase 1.5: strict rules for sockets only. Flash Player 10 will complete Phase 2 including cross-domain policy file changes for all other non-socket content (HTTP/HTTPS/FTP).
The completion of Phase 2 changes the default behavior of the meta-policy for policy files. A meta-policy is a policy that dictates the behavior of policy files on a domain, enablng an administrator to exercise greater control over all policy files being used with that domain. The concept of meta-policies was introduced in Phase 1 with Flash Player 9,0,115,0. For that version of the player, the meta-policy used a default value of "all," which allowed all policy files on a domain to remain valid; this allowed the behavior to remain consistent with previous versions of the player.
With Phase 2 in Flash Player 10, the meta-policy default will change from "all" to "master-only." This will allow all master policy files (any policy file saved in the root of the domain with the name crossdomain.xml, such as http://example.com/crossdomain.xml) to continue to function as expected. However, all other policy files defined in alternate locations will require an explicit meta-policy for them to work.
This change can potentially affect any SWF file accessing cross-domain content. This change affects SWF files of all versions played in Flash Player 10 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
Read the article, Policy file changes in Flash Player 9 and Flash Player 10.
If you have not already, define a meta-policy for your domain. Even if you are only using a master policy file, it is recommended you still explicitly define a meta-policy. Meta-policies can be set in the master policy file within a site-control directive, or through headers sent by the server.
If you depend on content from a domain outside of your control, you should contact that domain's administrator and make sure they have a meta-policy that is up to date.
securityErrorevents will be sent after a predetermined amount of time has elapsed since the call to
connect(). This means that previously immediate
securityErrorevents will take longer to be dispatched, and also that connections that might earlier have succeeded after a long delay (for example, because of network congestion or outages) will instead result in a
securityErrorevent. The predetermined timeout is 20 seconds by default but can be specified by ActionScript developers using the new
This change can potentially affect any SWF file that uses the
XMLSocketclasses. This change affects SWF files of all versions played in Flash Player 10 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
Developers should be sure to account for the new error by listening for the
XMLSocketobjects in their code. An explicit timeout may also be set. Longer timeouts favor greater robustness under marginal network conditions at the expense of longer delays in discovering failures. Shorter timeouts favor quicker discovery of failures at the expense of reduced robustness under marginal network conditions.
In Flash Player 9, ActionScript could perform uploads and downloads at any time. With Flash Player 10, the
FileReference.downloadoperations may be initiated only through ActionScript that originates from user interaction. This includes actions such as clicking the mouse or pressing the keyboard.
This change can potentially affect any SWF file that makes use of
FileReference.download. This change affects SWF files of all versions played in Flash Player 10 beta and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
Any existing content that invokes a browse dialog box using
FileReference.downloadoutside of an event triggered by user interaction will need to be updated. The dialog box will now have to be invoked through a button, keyboard shortcut, or some other event initiated by the user.
In Flash Player 9, ActionScript could set data on the system Clipboard at any time. With Flash Player 10, the
System.setClipboard()method may be successfully called only through ActionScript that originates from user interaction. This includes actions such as clicking the mouse or using the keyboard. This user interaction requirement also applies to the new ActionScript 3.0
This change can potentially affect any SWF file that makes use of the
System.setClipboard()method. This change affects SWF files of all versions played in Flash Player 10 and later. This change affects all non-application content in Adobe AIR—however, AIR application content itself is unaffected.
Any existing content that sets data on the system Clipboard using the
System.setClipboard()method outside of an event triggered by user interaction will need to be updated. Setting the Clipboard will now have to be invoked through a button, keyboard shortcut, or some other event initiated by the user.
Some HTTP servers sometimes send a response header that looks like this:
The purpose of this response header is to indicate to client software (browsers, Flash Player, e-mail clients, etc.) that the file being returned should not be rendered inline as active content. For example, imagine you're reading e-mail messages on a web-based service and you click a link that represents a file attached to a message. The server may well respond with "Content-Disposition: attachment"—meaning, "Hey, browser, don't open this file. Save it to disk instead." This header can sometimes serve a security purpose: If a server provides files that were uploaded by untrusted users, the "Content-Disposition: attachment" header can help prevent those files from being executed in the server's domain.
Starting with version 10,0,2, if Flash Player sees a "Content-Disposition: attachment" header while downloading a SWF file, it will ignore the SWF file rather than play it. Note that this restriction applies only to SWF files and not to other types of content, such as images, sounds, text, or XML files, policy files, etc.
This change will affect any SWF file whose HTTP server specifies "Content-Disposition: attachment" while serving the SWF file. This change affects SWF files of all versions played in Flash Player 10,0,2 and later. This change affects all non-app content in Adobe AIR (however, AIR application content itself is unaffected).
If you control the HTTP server on which the SWF file resides, determine whether you trust the SWF file to execute in the server's domain. If so, remove the "Content-Disposition: attachment" header by changing your HTTP server's configuration.
If you do not control the HTTP server on which the SWF file resides, you have two options:
- Contact the server administrator, inquiring whether the "Content-Disposition: attachment" header can be removed.
- Download the SWF file from another SWF file that uses ActionScript 3.0. In the loading SWF, use the
URLStreamclass to download the loadee SWF, rather than the
Loaderclass as usual. After the loadee SWF has finished downloading, call
Loader.loadBytesto transform the SWF data into a running SWF file. Note that this technique may not work because the loadee SWF may refer to relative URLs or rely on security sandbox privileges that are not available from the loading SWF's context.
The following properties of ActionScript 3.0 events contain references to DisplayObject instances:
- MouseEvent.relatedObject: During a
rollOutevent, this property refers to the other object, if any, that was involved in the change of objects underneath the mouse pointer—the object that either was previously or is currently under the pointer.
- FocusEvent.relatedObject: During a
focusOutevent, this property refers to the other object, if any, that was involved in the change of focus—the object that is either relinquishing or taking focus.
- ContextMenuEvent.mouseTarget: During a
menuItemSelectevent, this property refers to the object, if any, over which the context-click (right-click or Control-click) occurred.
Starting in Flash Player 10.0.2, if an object that would be referred to by any of these properties resides in a different security sandbox (for example, because it is part of a different SWF that was served from a different domain), and the two sandboxes do not both trust each other (by means of the
Security.allowDomainmethod), then the value of this property is changed to
These properties can already have null values—for example, when a user rolls over an object from the background. This change merely introduces new situations where a null value can be found.
If SWF files wish to determine whether a null value resulted from this restriction, they can check the values of three new Boolean properties:
This change can potentially affect any SWF file that refers to the
ContextMenuEvent.mouseTargetproperties. This change affects SWF files of all versions played in Flash Player 10,0,2 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
Your SWF file may continue to work without problems. Test your event handlers to see if they react properly. If there are problems, identify which other SWF file(s) are involved in the overlap of event information. If possible, have both SWF files call
Security.allowDomain, specifying each other's domains. However, do not call
Security.allowDomainwithout understanding the impact this will have—in particular, do not call
Security.allowDomainif you do not trust the specified domain with the privilege of arbitrarily scripting your SWF file.
When a SWF file performs an upload to a server, using the
FileReference.uploadmethods, Flash Player enforces two security rules:
FileReference.browsemust be called from within a user-event handler (mouse or keyboard event)
- If the upload goes to a server in a different domain than the SWF file calling
FileReference.upload, a policy file is required on the target server, trusting the domain of the SWF file
Starting with version 10,0,2, Flash Player enforces these same two rules at the time any networking API is called to perform a POST that will appear to the server to contain an upload. The format for these uploads is called RFC1867, and it consists of a Content-Type of "multipart/form-data", with a section in the POST body that includes a "filename" attribute in a "Content-Disposition" header.
This change can potentially affect any SWF file that makes use of any networking API to send a POST request that contains an RFC1867 upload. This change affects SWF files of all versions played in Flash Player 10,0,2 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
If this restriction causes your SWF content to stop working as intended, you will need to modify and republish the SWF file.
If you control the server to which the POST is being sent, you can change both the SWF and the server to use an alternate format for transmitting files, or just different syntax within the multipart format. If you avoid using the "filename" keyword, Flash Player will not treat your POST as an upload.
If it is a requirement that you use RFC1867 syntax, then try to ensure that you make your POST call from within a user-interaction handler, and that the server contains a policy file trusting your SWF's domain if you are POSTing to a server other than the SWF's own origin server.
Starting with version 10,0,2, Flash Player will not permit use of camera or microphone, or display of the Settings UI, when any of the following conditions are present:
- When the window mode (set with the HTML "wmode" attribute) is "direct" or "gpu"
- When the window mode is "transparent" or "opaque" (Linux only)
The Settings UI is the inline UI visible when users right-click or Control-click on SWF content and choose Settings.
This change can potentially affect, on Linux only, any SWF file that is sourced with a "wmode" attribute of "transparent" or "opaque", and that makes use of Camera or Microphone APIs. This change affects SWF files of all versions played in Flash Player 10,0,12 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
The "direct" and "gpu" modes are new in Flash Player 10, so no previously published SWF content should be affected by the "direct" and "gpu" restrictions.
If you are affected by this restriction, try changing your "wmode" setting to "window" (the default).
Flash Player developers will be able to allow users to save and load data from a playing SWF file to and from the user's hard drive using standard operating system browse dialog boxes. Previous implementations of this process required a server to manage the transfer of data from Flash Player to a user's computer. This will now be completely handled on the client side by Flash Player.
This is a new feature for Flash Player 10. Existing content will not be affected, but new content may be created for Flash Player 10 that makes use of this enhancement.
If you would like to make use of this feature, you will need to publish content for Flash Player 10.
Note: AIR developers already have access to
FileAPIs which provide this functionality in Flash Player 9 content running inside an AIR application.
Flash Player 9 does not allow keyboard input when displaying content in full-screen mode. Flash Player 10 changes this, allowing for a limited number of keys to be usable in full-screen mode. These include Tab, the Spacebar, and the (up, down, left, right) arrow keys.
This change affects all SWF files played in Flash Player 10 or later. This includes SWF files published for earlier versions of Flash, so long as they are played within Flash Player 10. This also affects non-app content in AIR.
It is likely that this change will not affect any existing content. However, you now have the opportunity to modify your content to make use of the new keyboard support to allow additional user interaction in full-screen mode.
Note: App content in AIR can set the value of
StageDisplayState.FULL_SCREEN_INTERACTIVEfor full keyboard support in full-screen mode.
RTMFP provides a UDP-based secure network transport alternative to RTMP between Flash Player and Flash Media Server. RTMFP also adds basic peer-to-peer capabilities that enable Flash Player instances to publish and play audio and video directly without relaying the media through an intermediate server. Flash Media Server is still required initially to establish these direct connections.
This is a new feature for Flash Player 10. Existing content will not be affected, but new content may be created for Flash Player 10 to make use of this enhancement.
If you would like to make use of this feature, you will need to publish content for Flash Player 10 that communicates with Flash Media Server supporting the RTMFP protocol. If you are the administrator of a network where this new feature will be used, you should become familiar with the security features of RTMFP, the direct peer-to-peer communication capabilities, and how it makes use of UDP, which may require changes to your network firewall configuration.
In Flash Player 9, the system Clipboard could not be read at any time. With Flash Player 10, the new ActionScript 3.0 method
Clipboard.generalClipboard.getData()may be used to read the contents of the system Clipboard, but only when it is called from within an event handler processing a
This is a new feature for Flash Player 10. New content may be created for Flash Player 10 that makes use of this enhancement.
If you would like to make use of this feature, you will need to publish content for Flash Player 10.
Where to go from here
For an overview of the changes coming in the next release of Flash Player, read Introducing Adobe Flash Player 10.
For a practical guide to what you need to know to work with the required changes that have been made to policy files in the upcoming version Flash Player, read Working with policy file changes in Flash Player 9 and Flash Player 10.
You should download Flash Player 10 from the Flash Player Download Center.