Save Firefox

If you don't want to send information back to Google, don't use Chrome.

Use Chromium instead. It's Chrome, but without the spyware, and only has the open-source components.

It won't work for Netflix though, but for all your other browsing, it should work exactly the same as Chrome. Keep Chrome around for Netflix.

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.

No you can't. It's all inherently snake oil. The nature of the universe is such that if you can see something then you can copy it. Either you get people to respect copyright by believing in the social contract or you lose. There is no technological solution.

> As OP points out, music ended up being ok with watermarking.

Watermarking isn't DRM. (Though it shares a lot of the same failings in the sense that it reduces quality for legitimate purchasers and can be removed by pirates.)

> Hollywood might be ok with something like hardware tokens (which imho would be superior to "just download and execute this blob and shut up").

That kind of hardware is just software embedded in silicon. Any "hardware token" can be fully emulated in software as soon as you extract the keys out of it, which somebody is going to figure out how to do and then tell all their pirate friends how to do. By the time the hardware is in enough hands that you can require it to be used, it's already broken. And you can't patch silicon over the internet, so the pirates win for a decade. Then you come out with some new hardware that pirates have several years to break before it's in enough hands that you can require it again.

> If that was the case, we wouldn't be hearing musicians crying foul about Spotify every other day.

Spotify has DRM. Losing money to competition is not the same thing as losing money to piracy.

> At current prices, that's unlikely. The experience is not terrible with current players either; what drives privacy at this point is mostly price.

It's mostly not. A Netflix subscription is extremely affordable. The problem with it is that their app kind of sucks, and even that is rainbows and sunshine compared to the unmitigated horror of cable TV set top boxes. Movie companies should stick to making movies and leave the software to Canonical and Apple and Google.

> Hollywood doesn't want to give up margins that are unrealistic in the digital age, which is why they fixate on DRM.

Except that those two things have nothing to do with each other.

> There is teaching and there is shaming. Shouting at them that they are morally-corrupt buffoons is not "teaching".

That's because there are three different sets of people: The actual artists, the morally-corrupt buffoons, and legislators. Teaching is what the artists need. The others need something else.

The advantage of building a Universal app using Windows Runtime is that it will run on Windows 8/8.1/10, Xbox One and Windows Phone. That's more than half a billion users....