EME specification needs to include a CDM specification

[GravisZro]

I've been looking over some existing and plans for future CDMs with DRM and they are in total conflict with the W3C's mission.

One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.

So with Microsoft plotting to have both software and hardware dependencies integrated into their CDM, the omission of a CDM specification from the EME only serves to give aid to what can only be described as global scale abuse.

The only way to ensure full interoperability between platforms and architectures is to use a virtual machine. The good news is that full and open specification exists for just such a thing, it's called SPIR-V which is better known for being part of the recently released Vulkan API. All the documentation and tools are both free and open and it is hardware accelerated as well as software implemented, so it is the ideal platform for CDMs.

[GravisZro]

It should be noted that moving CDMs to be written in SPIR-V would not prevent a User Agent from implementing a hardware dependent scheme but it would mean the hardware used was not dependant on the CDM itself. The result being hardware acceleration for all CDMs on all platforms as long as the User Agent enables it.

[paulbrucecotton]

@GravisZro:

The HTML WG (predecessor of the HTML Media Extensions WG) was told that specifying characteristics of a CDM (ie generic license request/response protocol) was out of scope of the WG's media charter scope. See http://www.w3.org/2015/05/19-html-media-minutes.html#item01

Since this request would fall into the same area which is beyond the current HTML Media Extensions WG charter, we will close this issue with no action.

/paulc HTML Media Extensions WG Chair

[GravisZro]

@paulbrucecotton Decisions like that can be reversed. Given that multiple large corporations have made plans to make hardware specific CDMs, it would be disingenuous to say that a hardware agnostic CDM specification is not needed. It would also be duplicitous to split the EME specification and the CDM specification because they are dependant upon one another.

You have an insurmountable conflict of interest in this matter because Microsoft, your employer, plays a central role in these very dangerous and damaging plans for hardware dependant CDMs.

[plehegar]

The charter extension was granted on the understanding that this would help wrap the first version of the API. This doesn't mean that future work could not include hardware agnostic CDM interfaces but this is not part of the work of EME v1. So, not only @paulbrucecotton isn't acting because of conflict of interest but I would also strongly object if the scope of EME v1 was expanded so late in the process.

[GravisZro]

@plehegar I disagree because the lack of a CDM specification was an intentional action by the companies currently drafting the EME for the express purpose of creating hardware dependance. While the EME does not preclude a system agnostic CDM specification, the companies drafting the EME have a vested financial interest in preventing it. If it's too late in the process to add a CDM specification, then the EME should be withheld from the approval process until an accompanying system agnostic CDM specification is approved.

This has already had real consequences.

Due to the lack of a proper CDM specification, Microsoft was able to make deals with major content providers to require Microsoft Playready 3.0 which uses a CDM that only works on a few browsers, only on Windows platforms and only if you have the latest Intel or AMD CPU. This is also the reason why Linux computers cannot view 4K videos on Netflix website. The only Linux computers that can view 4K content are SmartTVs made by companies that paid Microsoft.

With a system agnostic CDM specification, a CDM would work on any platform and thus Microsoft would be unable to extort millions of dollars from those wanting to use the Playready CDM on non-Microsoft ordained systems.

[mwatson2]

@GravisZro The situation you describe is in no way a consequence of the scope of the EME work in W3C.

Regarding:

This is also the reason why not all 4K SmartTVs can view 4K videos on Netflix.

Just for the record, there are many reasons why the Netflix app may or may not be available on a given device.

It is not clear to me, though, what you expect a "CDM specification" to contain, or, better, to achieve ? Do you believe such a specification must make it possible to view protected content on any device that can render the unprotected version of said content ? Or are you looking for full specification of the capabilities necessary for that, such that anyone could build those from that specification alone ?

[GravisZro]

The situation you describe is in no way a consequence of the scope of the EME work in W3C.

That is incorrect. Making the EME spec but then not making a spec for the CDMs for which EME requires is willfully encouraging proprietary solutions. As it is, you can't use the same CDM for different browsers let alone different operating systems or architectures.

An alternate solution to a CDM specification would be to remove all references to CDMs from the EME.

Just for the record, there are many reasons why the Netflix app may or may not be available on a given device.

SmartTVs are just Linux computers (I've updated my comment to reflect that) and have web browsers and as such would be capable of viewing the Netflix website and 4K video streams using the EME and Playready CDM if CDMs where system agnostic. As it stands, the only Linux computers that can view 4K content are SmartTVs made by companies that paid Microsoft.

It is not clear to me, though, what you expect a "CDM specification" to contain, or, better, to achieve ?

Then please read my original post because I wrote that "[t]he only way to ensure full interoperability between platforms and architectures is to use a virtual machine. The good news is that full and open specification exists for just such a thing, it's called SPIR-V..."

Do you believe such a specification must make it possible to view protected content on any device that can render the unprotected version of said content ?

I'm not sure of exactly what you are asking but I think that CDMs should be able to run on any platform regardless of the operating system or hardware architecture that you use. As long as the browser enables CDMs to be used, it should work on anything. "One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, ..."

[mwatson2]

Ok, so it seems what you are asking is for a standardized virtual environment in which CDMs can run, specified such that any implementor can provide that environment and thereby run any CDM.

The reason for my confusion (and I think others on this thread) is your use of the term "CDM Specification" which suggests a specification of the CDM. A specification of the CDM would encompass license requests / response protocols and other aspects of DRM which we decided should be out of scope, not least due to the IPR challenges there.

There are a number of challenges associated with defining a standard virtual environment that would be suitable for running DRM components. Several of them are technical but there would also be IPR and business hurdles. It would be a substantial project.

You are correct that our current approach does not achieve the goal you quoted. But it does bring us somewhat closer, compared to what we had previously (plugins) and so it is worthwhile nevertheless.

[GravisZro]

@mwatson2

There are a number of challenges associated with defining a standard virtual environment that would be suitable for running DRM components.

Not really, the work has already been done. Just look at SPIR-V which defines everything already. Seriously, the Vulkan API is being ported to every platform and not taking advantage of it would be foolish. You get a virtual platform and hardware acceleration all in one swoop. Here's a whitepaper describing the basics. I've told you about this multiple times, you just aren't reading what I'm writing.

Several of them are technical but there would also be IPR and business hurdles. It would be a substantial project.

"IPR and business hurdles" should never be the concerns of the W3C.

But it does bring us somewhat closer, compared to what we had previously (plugins) and so it is worthwhile nevertheless.

How does it bring us any closer to a unified solution? Flash was crappy but it wasn't tied to a single platform.

As someone commented, "So we are replacing shitty proprietary plugins like Flash and Silverlight with.... more shitty proprietary plugins. yay standards!"

[mwatson2]

To be more specific, DRMs typically provide some kind of secure attestation that enables the service provider to know that the DRM code is what they expect it to be and is running in an environment with the expected properties (primarily security and robustness properties). The virtual environment needs to provide support for this and SPIR-V does not.

The is difficult to achieve outside of any business context: the service provider needs some basis on which to trust the attestation from the DRM / virtual environment, which typically involves a secret of some kind on the client and a legal contract with the provider of that secret. Anyone using or implementing it is going to need IPR coverage.

A standard which cannot be implemented and would not be used if it was is not worth much, so solutions to those issues need to exist for it to be worthwhile developing the standard, even if they are not in W3C's scope.

How does it bring us any closer to a unified solution? Flash was crappy but it wasn't tied to a single platform.

CDMs are vastly smaller in scope than Flash or Silverlight were. The cost of porting and maintaining them on multiple platforms is much lower, so one would expect to see wider platform support.

[GravisZro]

To be more specific, DRMs typically provide some kind of secure attestation...

As I've been assured many times, the ECE is not specifically for DRM. If companies don't want to use it, they don't have to. However, requiring CDMs in the EME but not specifying a standard CDM interface only results in proprietary solutions all around. So to still fulfill the goals of the W3C, the only options are to provide a CDM interface specification or remove CDMs from the EME.

A standard which cannot be implemented and would not be used if it was is not worth much, so solutions to those issues need to exist for it to be worthwhile developing the standard, even if they are not in W3C's scope.

• There is nothing worthwhile about breaking the internet.
• By your own admission, Netflix will abandon the EME and CDMs if someone were to break all CDMs, right?
• Stop trying to make the EME happen if it means breaking the internet.

The internet does not need Netflix, Netflix needs the internet.

CDMs are vastly smaller in scope than Flash or Silverlight were. The cost of porting and maintaining them on multiple platforms is much lower, so one would expect to see wider platform support.

Will Netflix be the ones paying to port Playready 3.0 CDM to Linux or should everyone on Linux just pirate 4K content since Netflix won't give it to them?

[paulbrucecotton]

The HTML WG (predecessor of the HTML Media Extensions WG) was told that specifying characteristics of a CDM (ie generic license request/response protocol) was out of scope of the WG's media charter scope. See minutes.

Since this request would fall into the same area which is beyond the current HTML Media Extensions WG charter, we will mark this issue with Milestone VNext.

/paulc HTML Media Extensions WG Chair

[sabado]

Just for saying, are three CDM implemented by Apple, Microsoft and Google, they are owners of the three largest browsers. In fact this is a oligopoly situation. CDM implementation must be open and well documented, but it is covered of oscurism. And trust me, either of actual implementations are't fully secure.