Sam Zhang's Blog

Streaming == Content Protection? (Part 2)

2008-05-23T22:41:11Z

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)

2008-05-23T01:38:00Z

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

Web Playlist and Bit-rate Throttling - Working together

2008-05-06T23:54:00Z

Hello, my name is Sam Zhang (or 章葛强 if you can read Chinese) and I'm a lead developer on IIS Media Pack team. I've always wanted to start my own blog to talk about IIS and media but couldn't do it until now. J IIS Media Pack team is a relatively new team with a vision to enable advanced media scenarios on IIS platform. This team has a group of bright and smart people who are really passionate about web media technologies. I hope you will find useful information in my blogs and at the same time provide us your valuable feedbacks.

I think you've probably known or used the two Media Pack modules we've released so far: Bit-rate throttling 1.0 and Web Playlist CTP2. There have already been some great posts about the features and functionalities in these two products. So I won't go into those details again. Today I'd like to talk about how these two modules fit into IIS pipeline and how they work with each other.

First, let's talk about Web Playlist. If you have used Web Playlist, you probably know that Web Playlist by default handles requests with ".isx" extension. In Web Playlist, ".isx" is defined for "default playlist provider" and you can add your own playlist extension by adding a playlist provider. In IIS7 pipeline, the component that handles requests and produces responses for a particular extension is called "request handler". For example, ASP.net registers a request handler with ".aspx" extension. In IIS7, request handler only gets invoked if the request comes with the extension that it registered with. In our case, default web playlist handler is only called if the request has ".isx" extension.

For Bit-rate Throttling (BRT), the design approach is different. It's less about "what to return" but more about "how to return". In another word, BRT's job is to control how fast we can send the response rather than figuring out what response needs to be sent to the client. So with that, it was naturally implemented as an IIS7 module instead of a handler. In IIS7, a module listens to one or multiple event notifications which are fired for all the requests. BRT mainly listens to RQ_SEND_RESPONSE event which is fired right before the response is going to be sent. All the magic of doing bit-rate control happens at that point.

So, if you have both Web Playlist and BRT installed and enabled, they both exist in the request processing pipeline but get invoked at different stages. At the same time, they're totally independent with each other as well. For example, it's perfectly fine to just run Web Playlist without BRT if bandwidth consumption is not a concern. Because BRT is implemented as a module in IIS7 pipeline, it can handle all type of responses, static file or dynamic responses, as long as you have the right throttling rules defined.

So how exactly is BRT working with Web Playlist? If you have used Web Playlist, you probably know that the entry URLs embedded in the ASX response are obfuscated. There's no way to tell which content is going to be returned just by looking at the URL. Web Playlist keeps track of the user session state and communicate with playlist provider to find out the exact content at runtime. Can it still be properly throttled? The answer is yes, and you get the same behavior as if the client is requesting a static media file. BRT does not rely on the request URL to determine where to look at. Instead, it directly intercepts the response entity and find out what is actually being returned. If the response contains a file handle, it knows how to trace back to the original location of the file, get the file extension and apply the corresponding throttling rules. If it's a media file, it will follow the same logic of parsing the encoded bit-rate from that file and use the proper media throttling rules (e.g. 20s/100%). So all you need to do is to set the right throttling rules for the file type you want to return with Web Playlist, and everything else will happen automatically. It works not only with entries entered with relative URIs in playlist but also with entries located by physical path which does not need to be in the public URL namespace. One thing to note here is that BRT won't work with remote URLs you set in your playlist because the actual downloading is going to happen on the remote server (well, you could still install BRT on your remote server J).

As you can see, BRT can easily work with static files as well as dynamic responses. Web Playlist is just a good example here. You can write your own request handler to dynamically return media files or any type of responses and BRT will just work.

Want to give it a try? J