Streaming == Content Protection? (Part 2)

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