Architecture & DesignAdobe's Emerging Rich Media Ecosystem, Part 3: Marketing, Service Level Agreements, and...

Adobe’s Emerging Rich Media Ecosystem, Part 3: Marketing, Service Level Agreements, and Security

Figure 1: Edge/Origin architecture

Edge/Origin server configurations improve performance by distributing the server load among many computers on a network. With an Edge/Origin deployment strategy, all connection requests from clients are redirected to an Edge server. The configuration also lets you maximize your network if you are supporting a large local network. By placing Edge servers in remote office locations, the Edge servers will cache media files locally so each stream does not need to access the Origin (host) server for each stream.

When a client request is received, the Edge server will handle the tasks it can, and then will make a connection to the Origin server for any additional data required. When the Origin server fulfills the request, the data is sent back to the Edge server, then on to the client. To the client, it appears that the connection is made directly to the application running on the Origin server.

The Edge server serves as a “traffic cop”—handling connection overhead, authentication, and other administrative duties—freeing up valuable system and network resources for the Origin server. Every connection and connection attempt consumes resources over and above the actual stream data flowing through the connection. As the number and frequency of connections increase, the load can be excessive; adversely affecting server performance.

The Edge server greatly reduces this load by aggregating connections. The Edge multiplexes the connections from a large number of clients into one connection to the Origin server. All communications between Edge and Origin servers are transparent to clients.

The Edge server also stores the prerecorded media content received from the Origin server in a cache, which is then made available to other clients that connect to the Edge server. Caching static content further reduces the load on the Origin server.

The Effects of Mobility on Wireless Media Streaming Performance

There are other examples that illustrated the need for and difficulty of capacity planning prior to the drafting of an SLA. In many cases, media is delivered from a streaming server on a wired network to mobile clients on a wireless LAN. There are two scenarios: with and without client mobility. Before releasing a new system, you should determine media streaming performance in best-case and worst-case scenarios for each case.

Two main points need to be understood: First, wireless media streaming performance can degrade significantly in the presence of user mobility. (Inconsistent wireless channel quality and intermittent connectivity can lead to excessive retransmissions, dynamic rate adaptation, and RTS/CTS negotiations on the WLAN. These delays degrade the performance of the wireless streaming application.)

Second, the performance degradation affects all clients in the WLAN, not just the clients who are mobile. This problem occurs because of the shared queue at the access point.

These observations highlight the many challenges for providing quality of service guarantees for wireless multimedia streaming. One possible solution is to use per-flow queuing at the access point, or a buffer management scheme that provides fairness.

Figure 2: Delivering media to mobile clients on a wireless LAN.

Another solution is to configure an access adaptor to accept or reject requests based on the number of clients currently connected or the amount of bandwidth currently being consumed.

The Recent FCC Auction of the 700 MHz Spectrum

The U.S. Federal Communication Commission (FCC) has been auctioning off part of the valuable 700 Mhz spectrum—this RF travels long distances and can penetrate thick walls—being “returned” by television broadcasters as they move to digital from analog signals in 2009. These frequencies will be accessible to customers using any device or software application.

At the same time, Google, Microsoft, and other tech companies are pushing for the ability to use these empty, unlicensed airwaves, known as white spaces, to provide high-speed Internet service that might be able to serve hard-to-reach rural regions and supplement other Internet services in cities. But opponents of this idea, namely television broadcasters who use adjacent airwaves, say white-space use can interfere with regular TV signals and could blot out over-the-air broadcasts.

I mention this controversy because, as we approach the next generation of wireless broadband services, there are new unresolved issues that could influence the quality of your broadcast media at its very source: For example, wireless microphones for sporting events, concerts, and churches, which use this unlicensed spectrum. TV broadcasters say this technology could put their productions at risk and support auctioning off those fallow airwaves and making them licensed in order to protect against interference. Stay tuned.

Security

Flash Media Server distributes media streamed via RTMP, an Adobe-patented protocol that runs over TCP. Flash Media Server helps to further protect streamed media by encrypting it and tunneling it over HTTP. This new protocol is called RTMPE. Users view the streamed content via Flash Player. Similar in strength to Adobe’s current SSL protocol (RTMPS), this enhancement can be leveraged by content owners and communication developers to add additional protection to their content. Additionally, SWF verification helps protect SWF files from being reused, modified, or hosted in alternate locations. And, Flash Media Server 3 also supports streaming of encrypted content to Adobe Media Player.

Figure 2 and the Appendix present an overview of the security options available in Flash Media Server 3.

Adobe’s new Flash Media Rights Management Server (FMRMS) sits alongside the Flash Media Streaming Server or Flash Media Interactive Server and protects streaming content downloaded in FLV (Spark or VP6 codec) or MPEG4 (H.264 codec) format and played back on local desktops.

Figure 3: Flash Media Server security architecture.

Digital Rights Management

FMRMS runs on Windows Server and Red Hat Linux to offer content protection and business rules for playback and repurposing of offline content. FMRMS works with applications built on Adobe AIR, such as Adobe Media Player, to extend control of Flash content—even after it’s been downloaded. Content owners can set customized restrictions including how long the content can be viewed, whether an ad needs to be watched first, and who can view it.

Content could be set to require confirmation of playback each time—meaning that a device would require an Internet connection each time “offline” content was accessed—or could be set to require a connection every so many days, weeks, or months.

Media broadcasters could potentially set the access requirements and expiration flags of content that is being streamed both on request, but more importantly dynamically after the file has been distributed.

The content owners I’ve referred to above include:

  • Enterprises who want to deliver video content securely to employees and partners
  • Film and television studios or producers or online video content creators
  • Content distributors such as Internet Service Providers or online video rental outlets
  • Companies with a significant Internet multimedia presence, such as sports and entertainment sites

Content owners and publishers can make money with FMRMS through advertising and licensing. FMRMS, by signing a digital playlist, locks advertising together with content so they always play together. Adobe Media Player offers additional branding opportunities with banners, in-rolls, and overlays. FMRMS, in conjunction with existing user authentication and order management systems, grants a license to individual users for a particular piece of content.

Digital Rights Management (DRM) for offline content isn’t new. Apple implements it with every music purchase, but Adobe’s approach gives the content holder more options. The DRM can be as restrictive as the content owner wants.

Note: I doubt that Adobe has any illusions that FMRMS will stop copyright infringement—any more than dozens of other DRM systems have done so—but the introduction of encryption does give Adobe and its customers a powerful new legal weapon against competitors and ordinary users through the Digital Millennium Copyright Act (DMCA). Under section 1204, penalties range up to a $500,000 fine or up to five years’ imprisonment for a first offense, and up to a $1,000,000 fine or up to 10 years’ imprisonment for subsequent offenses.

Conclusion

This article, the third in a series, was preceded by:

And, the series itself was preceded by:

Taken together, these four articles provide an overview of an evolving ecosystem for developing, deploying, and managing rich media applications, albeit an ecosystem from only one vendor. However, so far, this one vendor has a commanding lead in the marketplace and, so, in my opinion, anyone with responsibilities in this area ought to have at least passing familiarity with the topics covered above.

Appendix

Flash Media Server

Delivering your content with Flash Media Server provides even more protection than that provided by Flash Player alone:

  • No client cache: Flash video and audio content delivered to Flash Player using a normal web server are delivered through progressive download. This content is cached on the end user’s hard drive and can be easily accessed—and possibly stolen by the user. By contrast, video, audio and data streamed to Flash clients using Flash Media Server are not cached on local client machines. You can deliver MP3 files and other media safely and securely knowing that your web site visitors will not be able to go to their Temporary Internet Files folder and obtain your media file assets.
  • No exposed media on the server: When you deliver Flash audio and video using progressive download, the content is exposed on a web server. Savvy computer users may be able to obtain the URL of the web server on which the content is stored and access the content directly. In fact, there are a couple of services, such as KeepVid, which use this exact technique to capture Flash progressive download video and save it to a client’s disk. With Flash Media Server, however, the content is not exposed to HTTP, FTP, or other transfer mechanisms, so media cannot be copied down from the server.
  • Note: Some services erroneously claim to capture “streaming” Flash video, but what they really mean is “HTTP streaming” or progressive download.

  • Proxy server capability: Content streamed from Flash Media Server is not only safe from being grabbed from a server, but Flash Media Server even comes in an Edge Edition that you can place on a server outside the firewall, making it act as a reverse proxy serving up content pulled from an Origin Edition on a server that is behind the firewall. This way, your media files are safely kept behind your firewall and no content is stored on a machine that is accessible to the Internet.
  • Unique transfer protocol limits stream ripping: By default, content delivered by Flash Media Server is wrapped inside the Adobe RTMP protocol. Because this is an unpublished, proprietary format, none of the RTSP stream ripping programs have the capability to rip media delivered over Flash Media Server. This minimizes the ability of unauthorized programs to capture a digital media stream from Flash Media Server to Flash Player.
  • Support for SSL and encrypted streams: Flash Media Server provides the ability to deliver encrypted streams to provide the tightest layer of security for delivering digital media. When you use this option, the server encrypts all audio, video, and data streams prior to transport. Once they are safely delivered to the client, Flash Player decrypts the content in real time and provides it to the user. This encryption is invoked when the client sends information to the server as well, providing the best way to protect content as it travels between the client and server.
  • Client information: When a client connects to Flash Media Server, Flash Player passes certain information about the client up to the server. Information such as the domain or IP address from which the client is connecting can be used to prevent deep linking and other thefts. You can also use this for syndicating content or a player and content to authorized partners.

Deep Linking

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.

Settings Manager

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)

The Flash Player Security Environment

The Flash Player client runtime security model has been designed around resources, which are objects such as SWF files, local data, and Internet URLs. Stakeholders are the parties who own or use those resources. Within the Flash Player security model, each stakeholder can exercise controls (security settings) over their own resources, and each resource has four stakeholders. Flash Player strictly enforces a hierarchy of authority for these controls, as Figure 5 shows:

Figure 5: Hierarchy of security controls

This means, for instance, that if an administrator restricts access to a resource, no other stakeholders can override that restriction. In Flash Player, it is common for multiple stakeholders to have the ability to control access to a resource, and for some stakeholders to formally delegate the right of control to a lower level in the hierarchy. For example, Administrators regularly allow users to make security decisions about their own environment.

Figure 6: Adobe Flash vis-à-vis other players on Internet-enabled PCs

References

About the Author

Marcia Gulesian is an IT strategist, hands-on practitioner, and advocate for business-driven architectures. She has served as software developer, project manager, CTO, and CIO. Marcia is author of well more than 100 feature articles on IT, its economics, and its management.

Latest Posts

Related Stories