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.
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?
See here 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.
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.
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.
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.
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.
EDIT: Firefox now supports Widevine
> Beginning in version 47, Firefox desktop also supports the Google Widevine CDM.
The issue with browser-specific CDMs at this time seems to be only because of varying completeness of EME implementations.
> 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.
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.
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.
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?
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.
> 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.
Is it really true that CDMs are actually browser-specific or are able to enforce a browser whitelist? If so, that is horrific.
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.
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.
A standard way to allow anyone to run one of those CDMs and removing the publishers as the gatekeepers.
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.
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".