Hacker News new | past | comments | ask | show | jobs | submit login

> This system, "Encrypted Media Extensions" (EME) uses standards-defined code to funnel video into a proprietary container called a "Content Decryption Module." For a new browser to support this new video streaming standard -- which major studios and cable operators are pushing for -- it would have to convince those entertainment companies or one of their partners to let them have a CDM, or this part of the "open" Web would not display in their new browser.

This is the crux of the issue. The W3C is creating a standard which gives control to the publishers over which browsers can display their content.

Whether that's "right" or "wrong" is worth debating, but sometimes the real issue at stake gets obscured in these discussions.




I've read many articles critical of EME and this is the first time I've heard this information. If true, as you said, it is THE issue.

It was always my assumption that EME represented a standard way for CDM's to interact with the browser. EME is to CDMs as NPAPI is to plugins. That is to say, a CDM can theoretically work in any browser implementing the EME standard. Is this assumption completely false?


That assumption may indeed be false.

See here[0] in the FAQ "What does this mean for downstream users of the Firefox code base?"

>>> The solution consists of three parts: the browser, the CDM host and the CDM.

>>> However, the CDM will refuse to work if it finds itself in a host that isn’t identical to the Mozilla-shipped CDM host executable.

At first, I interpreted this to mean Mozilla, not Adobe, had implemented the restriction due to some particulars about the deal with Adobe. But I was wrong...

>>> This leaves downstream users of the Firefox code base with the following options:

>>> 4. Making arrangements directly with Adobe to get a non-Mozilla CDM host executable recognized by the CDM.

In other words, the CDM can discriminate on the CDM host.

My only hope is that this is non-standard temporary behaviour while Mozilla finishes EME. Otherwise, this is extremely terrible.

[0] https://hacks.mozilla.org/2014/05/reconciling-mozillas-missi...


...and this - I guess - is where the DMCA issue that the EFF raises comes in.

Because sure, you could build a browser that loads Adobe's CRM and fools it into thinking it's been loaded into Firefox - but if you did that, you could well be construed as defeating a technological copyright protection method.


So then, the only way CDMs are acceptable IMO is if they're never given enough information to know where they're running.

This should be a critical part of the standard and I'm surprised I haven't heard the EFF pushing for this, specifically. If the CDM has enough information to discriminate, your choice of browser for watching DRMed video is entirely in the publisher's hands.

The fact that you may get in trouble for fooling the CDM to run on another browser is almost beside the point. Why should we trust a black box with ANY information outside of the DRM-specific?

A website can refuse to load based on my user-agent, for example. However, I have full control over what the website knows about my browser including my user-agent. Because of this fact, I am always free from browser-discrimination on the Web.

But I have zero control over what the CDM knows about my browser. Therefore, the CDM has complete and unavoidable ability to prevent me from accessing parts of the public Web based solely on my choice of browser. AFAIK this is unprecedented. It means that users are no longer free from browser-discrimination, perhaps for the first time in the history of the Web.


> This should be a critical part of the standard

The standard is not at all concerned with the browser-CDM interaction, sadly. And yes, that's a major issue with the standard. We (Mozilla) brought it up repeatedly when the standard was being developed, because it causes precisely the issues you describe, and basically got ignored. Microsoft, Google, and Netflix (the editors for the standard) simply didn't see this as a problem.

Now in practice, Mozilla aims to give the CDM as little information as possible, because we think it's the right thing to do. But nothing in the EME standard requires us to do that, and I can't tell you what other browsers do with their CDMs.

> It means that users are no longer free from browser-discrimination

That's correct. You never _really_ were, by the way: sites can and do use Modernizr-like testing instead of UA string sniffing to detect what browser you're running, so the only way to avoid being discriminated against by a site that really wants to discriminate is to have a browser which responds the same way an "approved" browser does to all API calls... Doable, but in practice requires using an "approved" browser with some tweaks that are invisible to the site.


a CDM can theoretically work in any browser implementing the EME standard

Nope, it's the opposite. The CDM API is not standardized and in practice every browser uses a different CDM: Chrome has Widevine, Firefox has Adobe, IE/Edge has PlayReady, and it's not clear what Safari uses.


The CDM API is called "EME" and it is a standard. That's why Widevine can be made to work with Firefox (https://github.com/i-rinat/gmp-widevine).

EDIT: Firefox now supports Widevine

> Beginning in version 47, Firefox desktop also supports the Google Widevine CDM.

https://support.mozilla.org/en-US/kb/enable-drm

The issue with browser-specific CDMs at this time seems to be only because of varying completeness of EME implementations.


"EME" is the API CDMs expose to scripts, with browser mediation. It's not the API CDMs expose to the browser, which is not standardized at all, sadly.

> The issue with browser-specific CDMs at this time seems to be only because of varying completeness of EME implementations.

No, it's basically baked into the standard, because the editors were fine with having CDMs be browser-specific.


Bullshit. EME specifies a Javascript API for use by websites.

What Firefox uses to talk with a CDM is right there in the name of that Github repo: it's an interface called GMP and was created by Mozilla specifically for video/media-type browser plugins.

It's not used by Chrome, Safari or any other non-Mozilla browser.


That shim exists because Chrome and Firefox have different CDM APIs. There isn't a common API.


The common API is called "EME". Chrome and Firefox's API's are different because they're unfinished.


That "EME" API is what is exposed to scripts (think DOM). Not how the browser and CDM communicates (think XPCOM).


Sadly, the assumption is false.

The EME standard is a standard for a way for scripts on a page to ask the browser to talk to the CDM. The actual interaction between the browser and the CDM is completely unspecified; it just needs to enable the browser to implement the EME APIs.

I think a more apt comparison is that EME is to CDMs more like the 2D canvas API is to graphics libraries. At least in a world in which graphics libraries had very restrictive licenses and you could require, via the canvas API, a particular graphics library to be used for rendering your canvas.


Thank you, bzbarsky. Please help us (me) understand the situation a bit better if you have the time.

1. Could you please describe a bit more about the browser-CDM interaction and what is implemented there?

2. Why do you think the browser-CDM interaction was left unspecified? Wouldn't a standard be beneficial to all parties, even CDM developers (no need to back-and-forth with browser developers: just follow the standard)?

3. For a browser to support a CDM, is a developer required to write CDM-specific browser code? That is, if CDM APIs are not standardized, then does the browser need to be modified to accommodate each API? Maybe this is obvious but I can't believe this is the state of things.

4. I, and I believe many others, have been under the impression from the beginning that EME was intended to globally constrain CDM behaviour. What you've described in this thread is entirely different. EME is just an API for CDM-script interaction and nothing more. Meanwhile, these blobs are integrated into the browser and the extent to which they're constrained is up to the browser developers. Unlike an NPAPI plugin, there is no standard for what they're allowed to do or know.

It occurs to me now that a standard defining browser-CDM interaction would never come from the W3C as it is simply outside their scope (ie. Web standards, not browser standards). CDMs can choose where to run today because there wasn't enough interest (or coordination) in establishing a standard browser-agnostic environment for them to run in. Now the CDMs are here, entrenching themselves, and the time to establish this environment is long gone. Is this an accurate representation?


> Could you please describe a bit more about the browser-CDM interaction and what is implemented there?

I don't really know what this interaction looks like in non-Firefox browsers. Last I checked, the CDMs Chrome ships didn't work with Chromium, but I don't know whether that's still true, and I don't know whether the browser-side bits involved are implemented at all in Chromium or just in Chrome. Likewise, I don't know whether the CDM interaction bits in Safari are in the public WebKit repo or not. IE's source is not available, of course. In the case of Firefox, https://hacks.mozilla.org/2014/05/reconciling-mozillas-missi... really does cover most of the details. We put together an API that made sense on our (Firefox) end internally. We then worked with some CDM vendors to integrate their products, by building shims to convert the API their CDMs exposed to the API we wanted to be using internally. That's probably all I can say on the subject.

https://hsivonen.fi/eme/ has a reasonably in-depth discussion of the way these bits fit together from someone who was much more intimately involved in this than I was.

> Why do you think the browser-CDM interaction was left unspecified?

Because the people writing the spec pushed back pretty explicitly on doing so, claiming that this would take too much time and overconstrain things too much in terms of both CDM and browser implementations.

> Wouldn't a standard be beneficial to all parties, even CDM developers (no need to back-and-forth with browser developers)

The CDM developers I'm aware of are Google, Apple, Microsoft, and Adobe. Three of these are also browser developers, who are shipping their own CDM in their own browser. Two of those three, along with Netflix, happened to be the spec editors.

There was literally zero incentive for them to standardize the browser/CDM interaction, and some incentives to NOT do so. So they didn't.

> For a browser to support a CDM, is a developer required to write CDM-specific browser code?

Yes. Not just that, but for actual CDMs on the market the developer is also required to work with the CDM vendor to accept that particular browser as a trusted enough party.

This is because CDMs are supposed to prevent the decoded data being captured, so they must either handle their own on-screen display or do so via an intermediary they trust. See also the "What does this mean for downstream users of the Firefox code base?" section of https://hacks.mozilla.org/2014/05/reconciling-mozillas-missi... and note that in the setup described there the CDM basically bakes in some sort of signature of the actual browser _binary_ that it's willing to work with. So just compiling the same, or worse yet slightly modified, source is not enough to get something that works with the same CDM.

> Maybe this is obvious but I can't believe this is the state of things.

It's totally the state of things.

> I, and I believe many others, have been under the impression from the beginning that EME was intended to globally constrain CDM behaviour.

EME describes a set of things that a CDM must effectively support. This means that a browser can demand that a CDM run in a sandbox that limits its interactions with the outside world to whatever is needed to support the EME APIs. This is the approach Firefox is taking with its CDMs.

Of course the CDM vendor can tell the browser vendor to go take a hike with its sandboxing demands and simply refuse to run in such a sandbox. Then the browser vendor can either back down or not ship that particular CDM.

There was a lot of talk about how EME opened the _possibility_ of CDMs that were more constrained than NPAPI plugins are (because the NPAPI includes all sorts of stuff, whereas a CDM could be built with a much smaller and more sandboxable API). And some people (the Netflix ones in particular, iirc) sure made it sound like this possibility would be a definite reality. And to some extent they were right: the CDMs in Firefox are certainly a lot more sandboxed than NPAPI plugins! But that's because Firefox decided to make it so, and EME somewhat enabled it to make that decision, and the CDM vendors involved agreed to play along.

> (ie. Web standards, not browser standards)

I'm not sure the distinction is that meaningful.

That said, the W3C can, when it wants to, work with other standards bodies on joint things. Examples include WebSocket (API defined by W3C, wire protocol defined by IETF), WebRTC (similar), JavaScript (API and integration points defined by W3C, language defined by ECMA), and probably other things I'm forgetting. If people had really cared about standardizing the browser/CDM interaction and had really decided that the W3C was the wrong venue for it (which is not obvious), another venue could have been found.

> because there wasn't enough interest (or coordination) in establishing a standard browser-agnostic environment for them to run in.

Correct. The only interest expressed in such a thing was from Mozilla and Opera, as I recall. Oddly enough, those were the only major browser vendors that were not also CDM vendors. What a coincidence!

> Is this an accurate representation?

I think the time to establish such an environment is not any more gone than it used to be, because nothing has much changed. Apple, Google, and Microsoft are still both browser vendors and CDM vendors, and still not interested in standardizing CDM stuff. Mozilla could create a "standard" on its own, but it would be rather meaningless in practice. And the problem of CDMs wanting to authenticate exactly who they're talking to on the binary level would remain.


I think the point is that to consume any particular piece of content, the publisher decides which CDM is appropriate, which effectively lets them decide who (which browser) can consume their content.


In the assumption I'm describing, it's irrelevant which CDM a publisher chooses. The reason being that the CDM must operate via EME, an open standard that can be implemented by any browser. Therefore, CDMs are inherently browser agnostic just like NPAPI plugins.

Is it really true that CDMs are actually browser-specific or are able to enforce a browser whitelist? If so, that is horrific.


> Is it really true that CDMs are actually browser-specific or are able to enforce a browser whitelist?

The EME standard only covers the DOM APIs and the interactions between the video player JavaScript and the CDM. There is no standard browser API or ABI for CDMs like there is for NPAPI.


Does that matter if the CDM is only exposed to sites via a standardized API?


For the site, it doesn't matter. For someone who wants to build a new browser that supports EME, it does matter. There is no standard CDM API, so they must get copy open-source code (from Firefox or Chrome) or rely on documentation from a closed-sourced CDM.

For Firefox, Mozilla has a plugin ABI called GMP (Gecko Media Plugin) similar to NPAPI. Unlike NPAPI, GMPs are not directly instantiated by web content and, AFAIK, the list of supported GMPs is hardcoded in Firefox. Cisco's OpenH264 codec and Adobe's Primetime CDM are GMPs. Google's Widevine CDM has its own API, so Firefox uses a Mozilla-written GMP that wraps Google's Widevine DLL or .so binary.

https://wiki.mozilla.org/GeckoMediaPlugins


I'm afraid I don't know the history of it well enough to give a good answer, but IIUC what the EFF is claiming here is that CDMs are (potentially proprietary) blackboxes and that EME treats them as such. Therefore, publishers are able to decide which browsers are even allowed to use the CDM which they designate.

As far as CDMs being blackboxes in the standard - you can verify that yourself: https://w3c.github.io/encrypted-media/

It would be good to have an EFF expert explain some of the nuance here though.


Exactly. As far as I knew, EME was the solution to the problem they were talking about.

A standard way to allow anyone to run one of those CDMs and removing the publishers as the gatekeepers.


its a standard for the sites themselves to run a certain CDM, its totally unspecified on the browser side

IE, firefox cannot use google sandvine, even if you have chrome installed, because it is not a standard interface from the browser's perspective.

CDMs are absolutely not browser agnostic like NPAPI.


The specification is called EME.

> Beginning in version 47, Firefox desktop also supports the Google Widevine CDM.

https://support.mozilla.org/en-US/kb/enable-drm


EME is the standardized specification on the browser side... That's all it is.

CDMs could technically only work for one browser via fingerprinting, but that could already happen without EME (or DRM entorely) using browser fingerprinting to only serve content to UAs the publishers "trust".


Regardless of whether it's right or wrong, it seems counter to W3C's intended purpose of promoting open web standards.


You hit the nail on the head. Thank you.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: