4 ms·

HTML DRM consists of two parts. The first part is EME (extended media extension) that defines the API how a browser interacts with the CDM (the actual implement

by pyalot2 14y ago

HTML DRM consists of two parts. The first part is EME (extended media extension) that defines the API how a browser interacts with the CDM (the actual implementation of the DRM) The EME is what is being standardized. The CDM is what is up to the platform provider (or any plug-in provider) to implement, such as Google, Sony, Microsoft etc. There are a couple problems with this. 1) The actual DRM functionality will not help keep people from having to deploy on flash/silverlight because the technology is ladden with proprietary licenses and NDAs. Ordinary web developers will not be able to make use of "HTML DRM" 2) Since the CDM requires to do some user specific encryption/restriction, the CDM will be able to uniquely identify each web user regardless of privacy settings, cookie blockers etc. You will not have control over what the CDM does, it will sacrifice your privacy on the web, absolutely. This is a supercookie on steroids. 3) Due to the CDM having to be provided by third parties as a proprietary blob, this will make it harder to support the DRM on free/libre/speech/beer implementations such as Firefox, Linux etc. 4) It will decrease compatibility of video on the web by fracturing already fractured video support (the codec wars) into the even more fractured DRM format wars. 5) Because the CDM is a proprietary blob, there is no scrutiny, code review and control over what it does. Fiascos such as Sonys rootkits and a host of security exploits in shoddily written proprietary DRM blobs are inevitable. 6) Companies like Google, Microsoft and Apple will use the DRM to gain leverage over their competitors by intentionally denying them compatibility to consume videos of services they created. 7) Companies like Netflix, Amazon etc. will use the DRM to gain leverage over their competitors by denying them the ability to produce videos compatible with their DRM implementation. 8) And finally DRM will be used by everybody implementing it to rise the barrier of entry for companies in the entire market, as well as to exclude innovation.

bzbarsky 14y ago
Actually, it's even worse. EME does NOT define how a browser interacts with the CDM at the moment. That's precisely why some people are objecting to it in its current state. EME defines how script in a web page can ask the browser to talk to the CDM. How the browser actually does that is up to the browser and CDM vendor. There is no requirement that any CDMs expose any sort of standardized API that browsers can use to talk to them. For example, given the current proposal Microsoft can ship a CDM on Windows that only IE can talk to, Google can ship a CDM that only works in Chrome, etc. So in its present state the setup can be trivially used to lock out third-party (and especially open-source) browsers: just don't let them talk to any CDMs.
randall 14y ago
Thank you for this summary. It helped a lot.

by pyalot2 14y ago

bzbarsky 14y ago

Actually, it's even worse. EME does NOT define how a browser interacts with the CDM at the moment. That's precisely why some people are objecting to it in its current state. EME defines how script in a web page can ask the browser to talk to the CDM. How the browser actually does that is up to the browser and CDM vendor. There is no requirement that any CDMs expose any sort of standardized API that browsers can use to talk to them. For example, given the current proposal Microsoft can ship a CDM on Windows that only IE can talk to, Google can ship a CDM that only works in Chrome, etc. So in its present state the setup can be trivially used to lock out third-party (and especially open-source) browsers: just don't let them talk to any CDMs.

randall 14y ago

Thank you for this summary. It helped a lot.