If you haven’t gotten your personal dose of AIR yet, check it out at http://labs.adobe.com/technologies/air/
The install experience for an AIR application has been the subject of much effort internally, and many questions externally. One of the common questions revolves around the relatively “scary” nature of the installation dialogs.
One of the goals of the installation experience is to accurately communicate to the user the potential risk of installing AIR applications in general. An AIR application is a fully privileged local application, with similar powers and risks to a native application–including full filesystem read/write access. As such, the danger is that developers, IT administrators, or users could assume that AIR applications are somehow intrinsically “safer” to install since they are based upon web technologies.
One way a developer can improve the installation experience for the user is to sign the AIR installer file with a commercial code signing certificate. To see the difference in the installation experience for such an application, check out the “Employee Directory” sample AIR application here: http://labs.adobe.com/technologies/air/samples/
In the future there may also be more restrictive sandbox types that provide a “safer” type of AIR application, with a corresponding installation experience to encourage developers to develop applications with the minimum level of necessary privilege.
In response to previous questions regarding FMS security, the reasoning behind the restrictions on interacting with RTMP streams is to protect the content being provided by the server. This is a little different from other data loading operations as RTMP is not directly covered by cross-domain policy files and was not originally intended as an interactive data source (rather than just a hands-off media type).
In theory permitting access to the RTMP stream does not pose security issues so long as the Flash Media Server can reliably specify a preference for who is permitted to interact with the RTMP streams. So don’t be surprised if this restriction is relaxed in the future.
For detailed information regarding protection content served from Flash Media Servers, see http://www.adobe.com/devnet/flashmediaserver/articles/protecting_video_fms.pdf
When you host SWF content inside HTML, you have a few tools at your disposal to control how much privilege that SWF has. If you are hosting SWFs that you created or trust completely, these may be unnecessary, however you may find them useful otherwise.
When specifying container tags (i.e. OBJECT or EMBED), you can optionally provide one of the following two parameters: “allowScriptAccess” and “allowNetworking”. These tags can only be specified within HTML (not from a SWF itself), and apply to that root SWF and any other SWFs the root SWF may load.
Today I’d like to take a shot at summarizing the reasoning behind having cross-domain policy files in Flash Player, and some best practices related to implementing them.
The browser security model normally prevents web content from one domain from accessing data from another domain. This is commonly known as the “same origin policy.” Note that this policy does not prevent the displaying of HTML or media assets cross-domain, such as HTML in an IFRAME or other images, etc. This is also true in Flash Player.
In the realm of security, “trust” is generally defined as “something acting the way you expect it to act.” By that definition, URI schemes (http://en.wikipedia.org/wiki/URI_scheme) have a checkered history at best.
Many developers tend to assume that a URL simply refers to a network data loading protocol, such as HTTP, HTTPS, and FTP. However, it been extended over time to include:
- local file I/O (file:)
- network file I/O (smb:, nfs:)
- local application integration (mailto:, various IM & streaming media schemes)
- local operating system integration (generally very dangerous stuff like shell:, vshelp:, local:)
Flash in particular also supports the asfunction: scheme, which can be used to call local ActionScript functions within your SWF.
If you are building an application that handles URLs, you should be aware of your responsibility to ensure that any URLs that are passed to the application and acted upon–either by having the application loading it directly or by the user clicking on it–are handled appropriately.