Streaming == Content Protection? (Part 2)

samzhang — Fri, 23 May 2008 22:41:11 GMT

So in part one, I talked about technically how streaming and content protection works and why they're independent and not tied to each other. Today, I'd like to share with you how I view the claims behind this notion and what they're really about. The claims I'm going to quote here are from a technical paper that was published by a company that advocates this concept. If you're familiar with media streaming, you should know which company I'm talking about. :) For the purpose of this blog, let me call it "the company". (Disclaimer: this is not the same "the company" that chases Michael Scofield and his brother in "Prison Break" :-) ).

Below are some of the claims in that technical paper which is trying to prove that streaming helps with content protection.

1. Progressive-downloaded contents are always saved in browser's cache

This is true, but only with default setup. If you know HTTP protocol, you probably know that HTTP protocol defines headers that can be used to disable caching. That means your web server can actually tell browser or cache/proxy not to cache the response. It's very easy to configure and here is an example of how it can be done on IIS7:

Figure 1: Selecting "HTTP Response Headers" Icon

Figure 2: Add "no cache" headers to the response

In the example above, I created a folder called "NoCache" under my default web site. Then I select "HTTP Response Headers" icon at this folder level (by doing that I only disable caching for this folder and below). Then I go into "HTTP Response Headers" UI page and add two response headers: "Cache-Control" and "Pragma" both with value as "no-cache". "Cache-Control" header is defined in HTTP 1.1 and "Pragma: nocache" header is for legacy HTTP 1.0 clients. See HTTP protocol spec here for more detail.

Ok, that's it! If you want to verify, you can try this:

1) Before adding these two headers, use your web player to play a media file in this "NoCache" folder. Then go to your browser's temp file folder and search for the cached file.

2) Add these two headers, clean your browser's cache and then repeat (1). You should no longer be able to find the cached file.

As you can see, servers can prevent progressive downloaded files from being available in a well-behaved browsers cache.

2. SSL Encryption

This technical paper talks about their streaming server supporting SSL encryption. What makes me uncomfortable is that it in nowhere mentions the fact that you can also easily do SSL from web server (aka HTTPS). Here I'm not going to dive into the details about how to configure SSL on IIS7. I'm sure you can find a lot of references on MSDN and iis.net.

3. Proprietary Streaming Protocols

Well, I can't really argue for this one because it's a well-known truth that "the company" has decided to use their own protocols and keep them in private. But using a proprietary protocol automatically makes the content "protected" just doesn't make sense to me. It's sort of saying if I speak in another language, my words will immediately become "protected". The reality is that it's just a matter of time before people crack it with good reverse engineering effort. Technically there's nothing preventing a "full featured" streaming client from saving the streamed content once it understands the streaming protocol. All it needs to do is to re-assemble the pieces from the streaming format back into the file format. Actually today if you do a search with "%ProtocolName% download" (replace %ProtocolName% with the name of the streaming protocol of "the company"), you would find that there're already tools out there which knows how to interpret this protocol and then save the streamed content to local files. The reverse engineering effort seems to have largely succeeded.

Using proprietary streaming protocol has many other limitations outside of the scope of content protection. For example, you would be locked into one particular type of streaming server, media client and file/codec format. Your contents can not easily flow to other type of clients which support standard protocols. It would be next to impossible to add support for new media formats, etc. These are all important things to consider.

Ok, with all that, let me try to summarize the points I'm trying to make here:

1. Streaming does not automatically give you content protection because they're not tied to each other. Content protection mechanisms can also be used with progressive download from web server. Streaming is just another way to deliver media contents. Streamed content can always be reassembled back into the file format. In another word, streamed content can also be "downloaded".

2. There're still things you can do on web server to better protect your content from being saved and trivially ‘used’ by well-behaved browsers. Disabling caching and using SSL are some examples. More advanced content protection mechanism can be implemented for progressive download by implementing modules and code on web server and media clients. This is the same idea as the watermark module developed by Fabio for protecting images. Modern web server like IIS7 has become a powerful programming platform on top of which you can develop all kinds of cool solutions.

3. The concept of proprietary streaming protocol provides content protection is NOT time-withstanding. Without a real content protection mechanism, tools that understand that protocol can easily capture the contents. Using proprietary protocols has many other limitations that might cause business concerns.

To be fair, I still need to acknowledge the fact that today it is indeed a lot easier to download and save contents from web server than from streaming server. For example, some tools do not rely on browser cache, instead they directly intercept the URL to the media file and download it separately. Some tools have made it as simple as a single-click experience. As I said above, you could also find tools that can "download" and save streamed contents but those tools are not so popular today. In my view, this is mostly due the fact that most media sites today still use progressive download to deliver their contents for its low cost and ease of use. If some day a particular streaming protocol becomes very popular, I bet capturing and downloading with that streaming protocol is just going to be as easy as downloading web contents today. In that sense, if you move to streaming just for content protection, you may get some benefits for the short run. But in the long term, you're really betting that the streaming solution you chose will NOT be mainstream. Because once it is, tools will be greatly enhanced and the perceived benefit of "content protection" will disappear immediately. But if you do win the bet and get the "protection" you want, which means you ended up choosing an unpopular streaming solution, wouldn't you be losing more?

Thanks for reading.

-Sam

Streaming == Content Protection? (Part 1)

samzhang — Fri, 23 May 2008 01:38:00 GMT

Recently I got a chance to talk to a customer who does a lot of media streaming as well as progressive download. One thing he mentioned was that more and more people start to believe that if they want content protection, they need to switch to streaming instead of using progressive download from a web server. I know that this idea has been floating around for quite some time but I never imagined that content protection would be a major reason why people want to do streaming. Because technically they're just two different things.

The fundamental difference between streaming and progressive download is the protocol which defines how client controls the media as well as how media data is packaged on the wire. For progressive download from a web server, standard HTTP protocol is used and the binary format on the wire is the same as the file format. For streaming protocols, like RTSP/RTP, media specific control commands (like pause, seek, fast forward and rewind) are defined. Also when transferring the content, the original media file is broken into meaningful pieces (like headers, streams and samples) and repackaged into streaming protocol format. So in streaming case, the binary format on the wire is not the same as file format. This repackaging, however, does NOT alter the actual media data in any way. All the samples and header information stay the same. No encryption is involved. All the data is till in clear. It's sort of like converting your old word .doc file to the new .docx format. Yes, the format did change but whatever the original document has is still there in the new format.

Content protection typically happens at different layers. I usually categorize content protection into two categories: link protection and file protection. Link protection is for, as the name suggests, protecting the link. In another word, it prevents third-party application or entity that sniffs or hijacks the content transfer session. An example of link protection would be SSL. The payload is encrypted before getting transferred through the link and decrypted as soon as it reaches the destination. Link protection is usually associated with the transfer session, not the actual content or file. Because link protection is only protecting the link, it does not have any control over how the media file is used once it reaches the client machine. If you want to have control over the media file itself, you would then need a file protection mechanism. DRM is an good example of media file protection. For DRM content, the media data (usually samples) is already encrypted when the file was originally created. Web server or even streaming server can be agnostic about the media encryption. Because all they need to do is to deliver bits or samples. Whether the content is encrypted or not does not really matter. Decryption for DRM content happens when the user tries to view the content. Client machine needs to contact license server to get the license and decrypt the content.

So as you can see, content protection is not tied to streaming. Yes, you can do streaming with SSL or DRM content. But you could also do progressive download with SSL or DRM content. Streaming gives you more functionality for transferring and viewing the media content by using more specialized protocol, but from network delivery's perspective, it's just another kind of pipe. Content protection is a special sauce that can be added separately and optionally to both streaming or progressive download.

Ok, this is all about theoretical analysis. Next time in part 2, I will go into the details about the claims that some company are making about "Streaming == Content Protection". You feedback is always appreciated.

-Sam

Sam Zhang's Blog : IIS Media Pack

Streaming == Content Protection? (Part 2)

Streaming == Content Protection? (Part 1)