Preorder Estimated Availability Date. Your credit card will not be charged until the product is shipped. Estimated availability date is subject to change.Preorder Estimated Availability Date. Your credit card will not be charged until the product is ready to download. Estimated availability date is subject to change.

Requirements

User level

Intermediate

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.

Policy file strictness: Phase 2

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.

What is impacted?

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).

What do I need to do?

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.

Socket connection timeout

For ActionScript Socket and XMLSocket objects, all securityError events will be sent after a predetermined amount of time has elapsed since the call to connect(). This means that previously immediate securityError events 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 securityError event. The predetermined timeout is 20 seconds by default but can be specified by ActionScript developers using the new Socket.timeout and XMLSocket.timeout APIs.

What is impacted?

This change can potentially affect any SWF file that uses the Socket or XMLSocket classes. 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).

What do I need to do?

Developers should be sure to account for the new error by listening for the SecurityErrorEvent.SECURITY_ERROR event from Socket and XMLSocket objects 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.

Upload and download require user interaction

In Flash Player 9, ActionScript could perform uploads and downloads at any time. With Flash Player 10, the FileReference.browse and FileReference.download operations may be initiated only through ActionScript that originates from user interaction. This includes actions such as clicking the mouse or pressing the keyboard.

What is impacted?

This change can potentially affect any SWF file that makes use of Filereference.browse or 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).

What do I need to do?

Any existing content that invokes a browse dialog box using Filereference.browse or FileReference.download outside 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.

Setting data on the system Clipboard requires user interaction

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 Clipboard.generalClipboard.setData() and Clipboard.generalClipboard.setDataHandler() methods.

What is impacted?

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.

What do I need to do?

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.

Content-Disposition header may prevent SWF files from playing

Some HTTP servers sometimes send a response header that looks like this:

Content-Disposition: attachment

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.

What is impacted?

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).

What do I need to do?

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 URLLoader or URLStream class to download the loadee SWF, rather than the Loader class as usual. After the loadee SWF has finished downloading, call Loader.loadBytes to 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.

Related-object properties in events may not be available

The following properties of ActionScript 3.0 events contain references to DisplayObject instances:

MouseEvent.relatedObject: During a mouseOver, mouseOut, rollOver, or rollOut event, 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 mouseFocusChange, keyFocusChange, focusIn, or focusOut event, 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 menuSelect or menuItemSelect event, 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.allowDomain method), then the value of this property is changed to null.

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:

MouseEvent.isRelatedObjectInaccessible

FocusEvent.isRelatedObjectInaccessible

ContextMenuEvent.isMouseTargetInaccessible

What is impacted?

This change can potentially affect any SWF file that refers to the MouseEvent.relatedObject, FocusEvent.relatedObject, or ContextMenuEvent.mouseTarget properties. 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).

What do I need to do?

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.allowDomain without understanding the impact this will have—in particular, do not call Security.allowDomain if you do not trust the specified domain with the privilege of arbitrarily scripting your SWF file.

POSTs containing file uploads require upload security checks

When a SWF file performs an upload to a server, using the FileReference.browse and FileReference.upload methods, Flash Player enforces two security rules:

FileReference.browse must 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.

What is impacted?

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).

What do I need to do?

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.

Camera and microphone unavailable in certain WMODEs

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.

What is impacted?

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.

What do I need to do?

If you are affected by this restriction, try changing your "wmode" setting to "window" (the default).

New security-related features that are available

Local save and load

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.

What is impacted?

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.

What do I need to do?

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 File APIs which provide this functionality in Flash Player 9 content running inside an AIR application.

Limited full-screen keyboard input

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.

What is impacted?

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.

What do I need to do?

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 stage.displayState to StageDisplayState.FULL_SCREEN_INTERACTIVE for full keyboard support in full-screen mode.

Peer-to-peer communication via RTMFP

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.

What is impacted?

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.

What do I have to do?

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.

Data can be read from the Clipboard inside a paste event handler

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 flash.events.Event.PASTE event.

What is impacted?

This is a new feature for Flash Player 10. New content may be created for Flash Player 10 that makes use of this enhancement.

What do I need to do?

If you would like to make use of this feature, you will need to publish content for Flash Player 10.