Adobe's Emerging Rich Media Ecosystem, Part 3: Marketing, Service Level Agreements, and Security, Page 5
Deep linking is when people at other web sites use images on their web site but they are hosted on your server. At the very least, this costs you bandwidth. Some sites look at the referrer address and when the request isn't from the site's domain, provide a picture saying deep linking isn't allowed.
Some commercial web sites object to other sites making deep links into their content either because it bypasses advertising on their main pages, passes off their content as that of the linker or, like The Wall Street Journal, they charge users for its content. Sometimes, deep linking has led to legal action, such as in the 1997 case of Ticketmaster versus Microsoft, where Microsoft deep-linked to Ticketmaster's site from its Sidewalk service. This case was settled when Microsoft and Ticketmaster arranged a licensing agreement.
Ticketmaster later filed a similar case against Tickets.com, and the judge in this case ruled that such linking was legal as long as it was clear to whom the linked pages belonged. The court also concluded that URLs themselves were not copyrightable, writing: "A URL is simply an address, open to the public, like the street address of a building, which, if known, can enable the user to reach the building. There is nothing sufficiently original to make the URL a copyrightable item, especially the way it is used. There appear to be no cases holding the URLs to be subject to copyright. On principle, they should not be."
Note: Web sites that are built on rich web technologies such as Adobe Flash and AJAX often do not support deep linking. This can result in usability problems for people visiting such web sites. For example, visitors to these web sites may be unable to save bookmarks to individual pages or states of the site, web browser forward and back buttons may not work as expected, and use of the browser's refresh button may return the user to the initial page.
However, this is not a fundamental limitation of these technologies. Well-known techniques now exist that web site creators using Flash or AJAX can use to provide deep linking to pages within their sites. The References section contains links to additional information on this subject.
Client Authentication with Flash Media Server
Using Flash Media Server, there are a number of different ways that publishers can verify and authenticate users before a stream is delivered. Authentication methods available in Flash Media Server include the following:
- Authentication at the SWF level: In this rather simple method of authentication, the publisher authenticates viewers using existing systems prior to serving the SWF file. Once a user passes authentication and the SWF file is served, audio and video content can be streamed. The benefit of this method is that it fits within your existing workflow, requires no additional changes, and yet authenticates users before serving up content.
- Authentication at the stream level: With this method, a SWF file is served up without protection but users are authenticated when they connect to the server and request a stream. This authentication can be done two ways with Flash Media Server:
- Scripting: Using a combination of client-side and server-side ActionScript, client information such as username, password, or even connection information can be passed to the server running Flash Media Server. Once that happens, that information can be used to authenticate users against back-end systems. Support for XML objects and Flash Remoting calls in the server facilitate this process.
- Executing authentication applications: For the maximum level of control, a plug-in module with Flash Media Server enables publishers to run external applications that are responsible for providing access to the server and content. This is useful for providing access in pay-per-view scenarios or even to prevent rogue sites from deep-linking into your content or server.
The options listed above can be used to support a number of different authentication uses, including:
- Support streaming in a single sign-on system
- Authenticate users against an LDAP directory
- Prevent unauthorized sites from deep-linking to your content
- Prevent others from stealing bandwidth
- Support pay-per-view content or events
- Offer rights management or conditional access to streamed content
Adobe Flash Player 9 Security
Adobe Flash Player runs Flash applications (also referred to as SWF files). Flash Player content is delivered as a series of instructions in binary format to Flash Player over web protocols in the precisely described SWF (.swf) file format (described at http://www.adobe.com/licensing/developer/). The SWF files themselves are typically hosted on a server and then downloaded to, and displayed on, the client computer when requested.
SWF files consist of multimedia content (vectors, bitmaps, sound, and video) and binary ActionScript instructions. ActionScript is the ECMA standards-based scripting language used by Flash; it features APIs designed to allow the creation and manipulation of client-side user interface elements, and for working with data.
Flash Player is designed to allow all SWF file content to be viewable and available consistently across a broad range of platforms, browsers, and devices. Flash Player also is designed to provide a robust environment to ensure security and privacy for the author, user, host institutions, and any of their respective data.
The Settings Manager is a special control panel that runs on your local computer but is displayed within and accessed from the Adobe web site. Adobe does not have access to the settings that you see in the Settings Manager or to personal information on your computer.
Figure 4: Flash Player security option settings (one of several dialogs)