Netflix coming to HTML5 just as soon as the DRM ducks are in a row

HTML5 Netflix will come to Chrome once one more standard is implemented.

Netflix users on Windows and OS X currently depend on Microsoft's Silverlight plugin to watch videos. With Silverlight no longer under active development, the company is looking at alternative delivery systems for its app-free, browser-based video delivery.

The answer it picked is, unsurprisingly, HTML5, but as the company details in a blog post, it's not up to the challenge just yet. The sticking point, again unsurprisingly, is DRM. Netflix's Silverlight player protects the content that it plays, and the company needs to maintain a similar level of protection in its HTML5 successor.

That isn't possible today, but with a trio of features currently being worked on under the remit of W3C, the World Wide Web Consortium, it soon will be.

Two of the features are relatively uncontentious. The <video> element that underpins HTML5-based video playback presently uses a specific URL or URLs as its data source. Netflix, however, performs dynamic management of the source, so that, for example, it can switch to lower bitrate streams if it detects a deterioration in network conditions. The Media Source Extensions (MSE) extends the <video> element to give JavaScript this kind of control.

The Web Cryptography (WebCrypto) API provides a JavaScript API for various standard cryptographic features such as hashing and encryption. This can be used for many things, such as client-side encrypted data storage, client-side generation of signed documents and e-mail message, and client-side secure instant messaging.

The third feature is, however, unwelcome for many. Encrypted Media Extensions (EME) provide an API that allows using encrypted media streams with HTML5's <video> and <audio> tags. EME defines how HTML5 browsers will detect that encrypted streams are being used, and then look up an appropriate Content Decryption Module (CDM) that will verify that the license is being properly respected, and then decrypt the data.

The announcement in February that W3C had deemed EME to be in scope for HTML5's development, and hence something that can be developed under W3C's banner, was not universally welcomed by the Web community. Content owners, and some of those providing services to content owners (both directly, such as Netflix, and indirectly, such as Microsoft and Google, with Internet Explorer and Chrome, respectively) regard EME as either desirable, or at least necessary, if premium video content is to move to HTML5.

For them, the choice is between "Silverlight/Flash/custom apps with DRM" and "HTML5 with DRM." "HTML5 without DRM" simply isn't in the running.

Countering that group are those who say variously that DRM is ineffective, DRM undermines users' rights, and that CDMs allow non-standard, proprietary code to be injected into the browser. In that light, it serves much the same role as plugins anyway, and as such, EME contradicts the goals of the open Web. Most or all CDMs are likely to be proprietary, unmodifiable code, to reduce the chance that they are tampered with.

Currently, the Chrome browser and Chrome OS have preliminary support for MSE and EME. Netflix is using both of these on Chrome OS to provide Netflix video to Chromebook users. It's using a plugin for WebCrypto; once that's included in Chrome, the plugin will be removed. From there, Netflix will begin testing its HTML5 player in Chrome on both Windows and OS X.

The third feature is, however, for many people unwelcome. Encrypted Media Extensions (EME) provide an API that allows using encrypted media streams with HTML5's <video> and <audio> tags. EME defines how HTML5 browsers will detect that encrypted streams are being used, and then look up an appropriate Content Decryption Module (CDM) that will verify that the license is being properly respected, and then decrypt the data.

Reminder for all commenters: <a href="https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2">the purpose of DRM is not to prevent copying, but to give the media companies leverage against technology companies</a>.

So where does Netflix fall under your simplification? Is it, as a media company, trying to use DRM to gain leverage over itself as a technology company?

This solution is for all practical purposes >>> Plugins for users and developers.

That being said, the internet has a huge ideological component to it (which has been its biggest strength) regarding openness. I am not sure how I feel about enshrining something so proprietary in the core HTML standards. Maybe we should simply continue to use plugins for stuff like this?

People can complain about DRM on owned content all they want, but DRM for rental content makes a bit more sense. There are no ownership rights to be dealt with. And you shouldn't be able to view the content after to stop paying for it (i.e. the month is over). I'd rather use HTML5 than Flash/Sliverlight/Java so I don't have to deal with plugins anymore (and are far more likely to be platform agnostic).

Reminder for all commenters: <a href="https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2">the purpose of DRM is not to prevent copying, but to give the media companies leverage against technology companies</a>.

So where does Netflix fall under your simplification? Is it, as a media company, trying to use DRM to gain leverage over itself as a technology company?

This solution is for all practical purposes >>> Plugins for users and developers.

That being said, the internet has a huge ideological component to it (which has been its biggest strength) regarding openness. I am not sure how I feel about enshrining something so proprietary in the core HTML standards. Maybe we should simply continue to use plugins for stuff like this?

I agree with you for the most part, but sometimes one has to be a bit more pragmatic. Plugins limit creativity. If this becomes part of the standard, delivering content to a platform just becomes as easy as having a compliant browser available (which is usually much easier than having a custom plugin available). DRM for content delivery (even if it can be broken) is just mandatory if one wants to get a license to distribute said contract. Media companies don't care about the ideals behind internet.

I agree with you for the most part, but sometimes one has to be a bit more pragmatic. Plugins limit creativity. If this becomes part of the standard, delivering content to a platform just becomes as easy as having a compliant browser available (which is usually much easier than having a custom plugin available). DRM for content delivery (even if it can be broken) is just mandatory if one wants to get a license to distribute said contract. Media companies don't care about the ideals behind internet.

I agree with you. I don't believe that this is a simple problem at all. It is a question of where you draw the line between preserving the ideology that, arguably (definitely IMO), has been fundamental to the internet's success, and making exceptions to it in order to make things easier for devs/users.

I agree strongly with this. I don't believe Hickson is correct here at all. Media companies have a lot of leverage over technology companies by virtue of the fact that tech companies don't wanna piss them off/be sued out of their existence. DRM doesn't do anything with regards to that.

Couldn't HTML5 media encryption also be used for encrypted videoconferencing (not just DRM)? Or does that fall under a different standard?

You could just use SSL for video conferencing, since you're generally not concerned about the other party's ability to capture the stream. The stuff referenced in this article is about protecting the content until it's actually displayed, which is not possible with SSL.

Reminder for all commenters: <a href="https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2">the purpose of DRM is not to prevent copying, but to give the media companies leverage against technology companies</a>.

So where does Netflix fall under your simplification? Is it, as a media company, trying to use DRM to gain leverage over itself as a technology company?

This solution is for all practical purposes >>> Plugins for users and developers.

That being said, the internet has a huge ideological component to it (which has been its biggest strength) regarding openness. I am not sure how I feel about enshrining something so proprietary in the core HTML standards. Maybe we should simply continue to use plugins for stuff like this?

I hate DRM in stuff that you buy. But in this case you don't own the content, it's a rental.

I don't think plugins are the answer as they can create new vectors for attacking end-users. We don't want something else that our parents and/or grandparents have to remember to update. And I really don't think we want media companies installing more stuff on our PCs.

Having it in the standards means the browser manufacturers need to deal with the security. Even though I fully expect MicroSoft to create their own "standard" just to be a pain in the ass to everyone else.

The third feature is, however, for many people unwelcome. Encrypted Media Extensions (EME) provide an API that allows using encrypted media streams with HTML5's <video> and <audio> tags. EME defines how HTML5 browsers will detect that encrypted streams are being used, and then look up an appropriate Content Decryption Module (CDM) that will verify that the license is being properly respected, and then decrypt the data.

For a RENTAL service, that shouldn't be a problem.

The problem is not "I want to keep movies that I 'rent' forever for free!!!". The problem is architectural.

If you look at the proposal, there are a few ugly little devils in the details:

Examine the diagram. The top levels(covering all the key requesting and exchanging) are noisy but largely harmless. Now, down by the CDM, we have "CDM May Use or Defer to Platform Capabilities". Oookay... So, it's "HTML5"; but it is entirely compliant with the spec to, for instance, have a video element that can only be played back on a Roku device, or if Windows says that your Protected Video Path is all squeaky clean. Note also: "CDM implementations may return decrypted frames or render them directly". Here again, the browser does the HTTP stuff, then the actual video piece gets handed off to a 'CDM' that can control everything from decryption to the point where it gets painted on your screen.

Essentially, the 'CDM' is the same thing(with room to be worse) as the oh-so-not-HTML plugins, like Flash and Silverlight, just with a few standardized javascript knobs to twiddle. It moves so much out of the browser that(while an OSS browser could theoretically implement it), it makes the user 100% dependent on whatever software and/or hardware the video streamer feels like requiring.

We might as well "Enable legacy applications in HTML5!" by defining the <Win32binary> tag, which would accept a URL pointing to a valid win32 executable and 'defer to platform capabilities' in order to execute it.

Would going to HTML5 with DRM enable Netflix to work in linux without going through a bunch of hoops?

tuco

If a browser that adopts the standard exists, then there would be no issue to play the content.

If a browser that adopts the standard existed, it would be able to examine the content in order to determine what CDM Netflix requires. That's all the standard provides for. Whether or not the CDM actually exists, that's not 'in scope'...

Couldn't HTML5 media encryption also be used for encrypted videoconferencing (not just DRM)? Or does that fall under a different standard?

You could just use SSL for video conferencing, since you're generally not concerned about the other party's ability to capture the stream. The stuff referenced in this article is about protecting the content until it's actually displayed, which is not possible with SSL.

I can think of security scenarios where you wouldn't want the other party to be able to record a voice or video call. Classified government communication and webcam strippers come to mind. In some jurisdictions it's illegal to record a phone call without the other party's consent.

I agree strongly with this. I don't believe Hickson is correct here at all. Media companies have a lot of leverage over technology companies by virtue of the fact that tech companies don't wanna piss them off/be sued out of their existence. DRM doesn't do anything with regards to that.

But the tech companies have all released players that play non-DRM content, both books and movies.

If the media companies were to release their movies without DRM, consumers would copy them to whatever devices and there's nothing the tech companies could do. What could media companies sue the tech companies for? Providing a player that read a standard format?

Once you have DRM, even if it's largely window-dressing, bypassing that DRM requires a deliberate action, which the DMCA specifically outlaws. That is what you can sue a tech company over.

As long as this becomse something supported by most/all browsers, i'm OK with this. This is better than having to depend on silverlight and this is a rental service, so, I'm OK with copy protection as long as it doesn't make it difficult or insecure for the user.

The third feature is, however, for many people unwelcome. Encrypted Media Extensions (EME) provide an API that allows using encrypted media streams with HTML5's <video> and <audio> tags. EME defines how HTML5 browsers will detect that encrypted streams are being used, and then look up an appropriate Content Decryption Module (CDM) that will verify that the license is being properly respected, and then decrypt the data.

For a RENTAL service, that shouldn't be a problem.

The problem is not "I want to keep movies that I 'rent' forever for free!!!". The problem is architectural.

If you look at the proposal, there are a few ugly little devils in the details:

Examine the diagram. The top levels(covering all the key requesting and exchanging) are noisy but largely harmless. Now, down by the CDM, we have "CDM May Use or Defer to Platform Capabilities". Oookay... So, it's "HTML5"; but it is entirely compliant with the spec to, for instance, have a video element that can only be played back on a Roku device, or if Windows says that your Protected Video Path is all squeaky clean. Note also: "CDM implementations may return decrypted frames or render them directly". Here again, the browser does the HTTP stuff, then the actual video piece gets handed off to a 'CDM' that can control everything from decryption to the point where it gets painted on your screen.

Essentially, the 'CDM' is the same thing(with room to be worse) as the oh-so-not-HTML plugins, like Flash and Silverlight, just with a few standardized javascript knobs to twiddle. It moves so much out of the browser that(while an OSS browser could theoretically implement it), it makes the user 100% dependent on whatever software and/or hardware the video streamer feels like requiring.

We might as well "Enable legacy applications in HTML5!" by defining the <Win32binary> tag, which would accept a URL pointing to a valid win32 executable and 'defer to platform capabilities' in order to execute it.

Given that content providers implement HTML5 video largely to serve Android and iOS users, I don't see how platform lock-in would be any more an issue than it already is for mobile. There isn't a single dominant player in mobile like there is on the desktop, and the Chrome folks recently divorced WebKit, so there isn't even a single dominant browser platform anymore.

Content providers will let you watch Game of Thrones from your Mozilla phone or Raspberry Pi if and when they see fit, regardless of whether they're using HTML5. Standardizing and modularizing media encryption will lower the technical and cost barriers to doing so, but should have no effect on the contractual and licensing issues.

I can think of security scenarios where you wouldn't want the other party to be able to record a voice or video call. Classified government communication and webcam strippers come to mind. In some jurisdictions it's illegal to record a phone call without the other party's consent.

Here's the problem: for something like a video conference, something as simple as a smartphone video recording would provide a suitable copy. No DRM would be able to prevent that. In these cases, you just have to trust the other side.

Reminder for all commenters: <a href="https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2">the purpose of DRM is not to prevent copying, but to give the media companies leverage against technology companies</a>.

So where does Netflix fall under your simplification? Is it, as a media company, trying to use DRM to gain leverage over itself as a technology company?

I can think of security scenarios where you wouldn't want the other party to be able to record a voice or video call. Classified government communication and webcam strippers come to mind. In some jurisdictions it's illegal to record a phone call without the other party's consent.

A video camera setup beside you, just out of view of the vidconf equipment gets past all the link encryption you cod ever create.

I can think of security scenarios where you wouldn't want the other party to be able to record a voice or video call. Classified government communication and webcam strippers come to mind. In some jurisdictions it's illegal to record a phone call without the other party's consent.

Here's the problem: for something like a video conference, something as simple as a smartphone video recording would provide a suitable copy. No DRM would be able to prevent that. In these cases, you just have to trust the other side.

For entertainment content, a 1:1 recording is vastly more desirable.

The I'm sure a content decryption module could integrate with building security systems, biometric authentication and other third-party verification to ensure that wouldn't happen. Like the CDE could mandate that you give a blood sample and lock yourself in a Farraday cage in order to watch Game of Thrones.

I agree strongly with this. I don't believe Hickson is correct here at all. Media companies have a lot of leverage over technology companies by virtue of the fact that tech companies don't wanna piss them off/be sued out of their existence. DRM doesn't do anything with regards to that.

Which they are totally and absolutely wrong about, because DRM does nothing to stop piracy and just penalizes legitimate paying customers.

It is well past time to make ALL DRM illegal and tell companies "Stop treating your customers like criminals! You are free to go after people who sell counterfeit copies of your stuff, but leave the other 'pirates' alone, they are usually doing nothing more than people with VHS recorders did 20 years ago, sharing with friends!"