Writing a technical article about the standards process around web DRM without even obliquely addressing any of the criticism of it seems like a strange choice to me. Almost everything in this article was already publicly known; what I'd like to have seen was an actual rebuttal of the criticisms of, among others, Ian Hickson, so as to move the standards conversation forward.
Companies like Netflix are stuck between a rock and a hard place. They'd sooner do away with DRM as it adds significant cost and complexity yet only serves to inconvenience their users. However they're forced into using DRM by the content owners who argue that such measure are required to protect their content.
This is why their position on DRM is often left unspoken, they can't publicly discredit because they need the studios on their side. But equally it's hard to address the criticisms if they also agree with such criticisms. So it's easier to just avoid being drawn into the argument to begin with.
If what you say is true, since they have started producing their own content (House of Cards), maybe they could experimentally distribute those shows (or at least some episodes) without DRM and use the results as a proof to convince studios that DRM is unnecessary and pointless.
The experiment's already been done. House of Cards was only released with web DRM, and yet it was available via the usual unauthorised channels almost immediately. Even when no non-DRM alternatives are available, DRM is still useless in preventing dissemination.
It also sort of depends on the scale of copying. Having easily available "download movie from netflix" versus "download movie from shady piracy website". Obviously, the analog hole is always there, so there will always be that vulnerability.
OK, the experiment isn't exactly the same, but it tests the same hypothesis: that the presence of DRM does not affect the dissemination of the content.
In fact, I'm not sure that performing DrJokepu's experiment as stated would prove anything: releasing episodes of HoC without DRM would have little effect, as they have been copied despite not having been made available without DRM.
My idea was that if it can be shown that piracy levels are about the same with and without DRM an argument could be made that perhaps investing in DRM is a waste of time and money.
While this is probably true, surely their special role in the financing and distribution of the show would have allowed Netflix to negotiate such exploitation rights if they wanted to.
The main function of DRM is not to prevent copying; it's to provide content rightsholders with a legal hook on which to hang people who make/distribute/use unauthorized copies.
Why should they address criticisms of DRM? They've already decided that they need DRM (or rather, their contracts require it). So, why should they spend the time debating the same things over and over again?
From their perspective, the DRM question isn't if, it's how. So, that's what their article is about.
But they talk about the "how" (the EME) as a done deal, when they don't seem to be, given Mozilla's opposition; more people will have to be convinced for this to actually work. Besides, everyone knows their proposed "how" already. A blog post that just says want to move to HTML5 delivery using this set of extensions they've already publicly supported for this purpose doesn't add much to the discussion.
They need DRM due to the reality of their relationship with Hollywood. There's nothing to debate. Either they get DRM support in HTML5 and switch to it, or they continue to use plugins and apps.
I don't see a problem with that. No DRM in HTML5. People are demanding less horrible web standards (flash must die!), and we watch the tension build until something catastrophically breaks. Something HAS to break.
I am willing to play chicken. Flash must die, and more than that, the standards should make no additional allowances for broken behavior, such as allowing websites to discriminate between Platform A and Platform B.
In practice, as long as Javascript remains in its present form, they will be able to effect this sort of discrimination, but the W3C doesn't need to actively promote brokenness.
They are a single company operating in a single market... they don't offer to sell me any product and i have no interest in what they have... i and people like me make up the vast vast vast majority of the the internets population.
So we don't even get an opportunity to play chicken... google and netflix will break the net and shove this shit down our throat regardless. Why should we the vast majority of the Internet give a shit about their precious hollywood contracts?
They have not moved away from plugins, they merely replaced 3rd party plugin with their own.
Their HTML5 solution relies on their own closed browser-specific plug-in (EME CDM) and browser vendors that don't have Netflix's license are unable (both technically and legally in US) to use it.
So they continue to use plugin that runs their native code. The only change is that they've taken away leverage that NPAPI gave Microsoft and browser vendors.
I honestly don't understand DRM in html specs. Most people use open source browsers. To crack the "DRM" all you would need to do is open up the source code and slightly modify it. DRM only works when either the client side code hasn't been cracked or when the server side requires clients to log in. The first is impossible with open source, and the second is already a part of html.
The DRM doesn't happen in the browser, it happens either in the OS or on a hardware component. Encrypted Media Extension just provides a way to communication with the DRM component. It's up to the web page to choose what type of DRM they accept. Expect most to require DRM on the hardware.
This means "premium" video is going to be fragmented. Big companies like Apple, Samsung, Microsoft will get it, open source operating systems and DIY devices will not.
> This means "premium" video is going to be fragmented. Big companies like Apple, Samsung, Microsoft will get it, open source operating systems and DIY devices will not.
People said the same about DVD and bluray DRM, yet they've been cracked and open source drivers distributed. Though it's sad that it ever had to come to that.
cracked and work's out of the box are two different things... practically and legally.
i dont care about netflix... like the vast majority of the internet, they dont even operate in my market. yet their greed is going to fragment the internet that i make a living from... all they are doing is ramming a new version of shitty proprietary plugins/binary blobs down our throats.
> cracked and work's out of the box are two different things... practically and legally.
libdvdcss works out of the box and is completely legal in Europe. It's the Americans that stand to lose more by imposing DRM extensions on the internet. At least if they're part of HTML, the technology can be reverse engineered and made cross-platform. With the current mess we're stuck with having to run Silverlight DRM extensions in WINE. So as much as I hate DRM, I'd sooner see it part of an open and cross platform spec than have content locked to specific software that only runs on specific platforms.
If the DRM black-box is talking directly to the display hardware, you might not be able to do this. Of course then your video will also not be subject to things like CSS opacity, clips, rounded corners, etc, etc...
Which indeed is why the implementations aren't going to be open source. The last I saw of the design, the intention was to put the entirety of decryption, decode, and display into a binary browser plugin and the HTML5 parts were only the bare minimum needed to push encrypted data to said plugin.
Yes, this is precisely the idea of the second of the three technologies mentioned (encrypted media extensions) - let HTML5 video interface with a separate opaque binary plugin that implements DRM.
Of course such binary plugins will be browser- and OS-specific, so this is going to result in a lot of problems, and goes against the spirit of the web.
The distinction is especially important in case of video. Only Google's own build of Chrome has license for H.264 and MP3 codecs and Netflix DRM plugin, and Chromium doesn't.
I think if your intention is to encrypt your video content then you really have no business being on the web in the first place. Just build a native app and do whatever you want, and stop trying to bend open standards to be compatible with your business.
Or, people get to use the web however they want without rigid "open everything" extremism. Netflix is the best business model on the internet right now: you pay them $X a month, get great content, everyone gets paid. DRM makes that possible. I find it far preferable to the advertising/spyware-based monetization model, which seems to be the only other viable business model for content on the internet. The internet standards should be flexible enough to accommodate both and let consumers choose.
O'RLY? That seems like a big jump of logic there. It's just as possible that with zero DRM they'd still do fine given playing back a movie in Netflix is far nicer than searching for the movie on some ad-ridden virus infested download site and then waiting several minutes to hours for it to be available.
So the content producers are in the clear, right up until someone comes up with a user-friendly interface for doing Netflix -> DVD rips.
The point of DRM isn't to make it impossible for some people to copy the content. It's to make it inconvenient for ordinary people to copy the content. That's what the big problem with Napster was (after all, people have been copying content on Usenet since the dawn of time).
With the current scheme house of cards was outside netflix within a week (if not the same day) So content producers are already doomed, why saddle html5 with DRM and binary blobs?
Well Netflix has less of an incentive for DRM on their own content, since they don't have any DVD/Blu-Ray sales to protect. But to the extent that unencrypted streams make it easier for unsophisticated users to rip DVDs from streams, it's a relevant consideration for the big media companies that offer content on Netflix.
In the long run, content producers will survive because the general purpose PC will be marginalized as a platform. The future is not people watching torrent-ed rips of movies on their laptops, it's people watching Netflix and similar services on their Apple TVs and iPads. At that point it doesn't matter if the content is encrypted or not, since it won't be convenient for your typical user to watch a ripped copy.
I would argue that the content producers will survive in spite of the fact that they lose the battle to create an entirely hands off encrypted media path from the website to your viewing device.
They will survive because they make their content easy to buy. They will survive /well/ if they make their content easy to buy and to license.
Then it's a very good thing so people understand that you cannot rely on a platform where one company has all the power on what can run and what can't.
Maybe it'd spring see nice anti-competitive trials. Results being irrelevant, as long as people understand that locked platforms are bad.
They're are many legit reasons to encrypt video (CCTV, video chats, etc). The web is the platform of the near future, I'd rather support this stuff natively than need multiple closed source desktop or mobile apps.
Encryption != DRM. All of that stuff you can do now with SSL. No one cares about video streams over SSL. It's what happens after the SSL layer that matters.
Indeed, but you're not going far enough. I never buy from any website that uses HTTPS! The idiots running them don't appreciate the open way the web is meant to be used.
"We will remove this last remaining browser plugin as soon as WebCrypto is available directly in the Chrome browser. At that point, we can begin testing our new HTML5 video player on Windows and OS X." - What do they have against linux?
"...and we've just started using this technology on the Samsung ARM-Based Chromebook. Our player on this Chromebook device uses the Media Source Extensions and Encrypted Media Extensions to adaptively stream protected content."
I'm not an expert on Chrome OS internals but it seems to me that being a GNU/Linux derivative with an X Server, it's not much of a jump to say the Linux version is being developed and tested first.
Edit to clarify: I'm guessing the development is being done on a Linux machine rather than directly on a Chromebook.
ChromeOS does not use X, though X can run on the devices.
Chromium is actually providing it's own compositor and windowing system.
The plugin they are getting rid of the is the Chrome-only Pepper API based plugin that for some reason is unavailable on the current Samsung ARM Chromebook.
From Valve's Steam stats Linux has been between 2-2.5% in its first opening few months where as OSX is only 3.5%. If a Mac port is assumed, one might wonder if that should be extended to Linux. and it's not impossible we'll see Linux over take Mac on Steam this year as it stabilizes, gets more games and more people sign up.
Maybe not on the desktop, but there are plenty of people using it as a media center OS. Enough that someone went to the trouble of rolling a custom Wine distribution to get Silverlight + Firefox accessing Netflix.
At this point it's just kind of silly to exclude Linux, especially when all the heavy lifting is already done; Chrome OS _is_ Linux, and I believe the Roku devices are Linux-based as well.
The reasons Netflix might have to exclude Linux are not unique to Netflix, but somehow Amazon and Hulu - both Flash-based, of course - manage to support these customers.
I think in the short term Chrome will be a prereq to watch Netflix (fallback to Silverlight in other browsers). In the long term DRM requirements are going to change and hardware-level DRM is going to be mandatory. Speculation.
The cardinality of the intersection of the set of people running Linux on a desktop/media center and the that of people dying to watch DRM'd content is likely small enough to be easily ignored.
They shouldn't be boasting, rather they should be ashamed about adding DRM to the HTML standard. And they present it as if it's a great achievement. Really unpleasant, if not even disgusting.
And if someone here claims that Netflix don't really like it, but just oblige the crooked studios who push for DRM, what are they excited about then?
Maybe they're excited because it means that more people can use their service (and won't have to suffer the terrible experience of Silverlight). Just a thought.
They could say that, adding, that as a whole this is bad, and they'd rather not do it, but "no choice and etc." (no really?). But they didn't. I personally don't think that being excited about implementing an unethical thing is good.
Presumably they are going to require proprietary native code running in the browser? If pure open source could actually play the streams then the DRM is pointless.
I suspect you're just trying to be a smartarse, but it hides an important point. It's not that HaikuOS can't watch Netflix, but that in the platform-specific DRM world, no new system that comes along can ever be a viable desktop without the blessing of the media establishment, and that this has the effect of entrenching existing players, especially those with money and connections.
The corollary of that is that keeping illicit distribution going might be a good bet for a diverse computing future.
How feasible would it be, instead of encryption/decryption in the browser source code (which can be defeated easily), to do decryption and rendering in javascript, perhaps with emscripten + asm.js optimizations? That should provide a reasonable amount of security through obscurity.
The problem, as with any DRM scheme is that the plaintext is available somewhere. Figure out where the buffer is, read it via the JS console (or Pin if the browser won't cooperate) and you're done. Asm.js probably offers as much protection as a normal binary, although the niceties of the JS runtime might make developing patches to dump streams easier than in native code.
I'd definitely say it's feasible, although I'm not sure it would add much beyond what Flash/Silverlight already provide.
Can anyone please explain me the purpose of DRM used by Netflix? I mean, if you can see the movie, doesn't it mean you can screen-record it with pretty great quality? And it can be done with any of available programs out there. What's the point?
What exactly is Netflix trying to prevent by using DRM? It seems like people are happy to pay for a Netflix subscription, even more if they could stream on Linux.
They are probably trying to prevent breaking their contracts with the content providers, which, somehow, think DRM actually hinders things.
We'll see how quickly the new Netflix-only Arrested Development ends up on The Pirate Bay.
I have a Netflix subscription, but sometimes I still prefer to torrent. I can force HD, I can load proper subtitles (ones without all caps), I can fix audio or video issues (levels).
No, they were just re-encodes to my knowledge. I have a Netflix account and I checked out one of the pirated ones just to compare. I couldn't tell a difference so they did a good job, but I'm sure the difference was there.
I'd imagine the Netflix DRM will get broken sooner or later, especially as they continue to release Netflix-only content, but the screen caps have been so good that the pressure to do so hasn't been very high I don't think.
I don't know what the original quality is, but for TV, there are usually 2 or 3 release formats (excluding webrips): standard quality (about half the height/width of 720p), 720p, and 1080p. The standard quality and 720p are usually posted a few minutes after the show airs, and the 1080p usually comes a long time later. Sometimes, episodes are even posted before the show airs in your region.
But how are they doing the rips? Are they getting the original encoded stream, doing analog capture and reencoding, or what? If DRM forces them to do a less than perfect copy of the stream, that's a big win for the content producer.
Sorry for the late response; I don't usually check threads. According to someone I asked on IRC, House of Cards apparently airs somewhere offshore (I think it was Germany), but that is where the non-webrip episodes are coming from. It also explains why there are only six different non-webrip episodes released.
BTW, the webrips are the ones that are coming from DVI or from captured + decrypted video streams.
Right, but then you decode -> re-encode which decreases quality. At the aggressive bit-rates used for HD content online, that can be substantial. So as long as DRM forces re-encoding, content producers can say: "buy it for the best quality" and that's a win for them.
It would take about five minutes for a Napster-like browser plugin to arrive that would allow the user to trivially dump the whole movie to their hard drive. Maybe Netflix's business model could sustain that, but the content owners would have a heart attack, fearing cannibalization of their other distribution networks.
Sure, everything's all on the torrent sites anyway, but the legal scare tactics worked to scare enough people away. With Netflix-Napster, though, there'd be no way to tell the difference between a legit stream and an unauthorized rip.
Obviously copy-friendly business models are preferable, maybe even inevitable, but for now, intellectual "property" rights trumps all.
By switching from Silverlight DRM with public interface (NPAPI) to Netflix DRM plug-in (CDM) with secret API and more restrictive licensing they're gaining ability to prevent any unapproved software from using the website.
Currently thanks to NPAPI interoperability anybody could build a browser/player that plays Netflix in ways they cannot easily control.
But with their own DRM plugin they can for example ensure that only Google-built Chrome can play Netflix and Chromium can't, so you won't be able to build your own Netflix settop box.
It's not about preventing piracy. It's about enforcing content providers' wishes on browser and OS vendors, and using W3C's name to legitimize the practice.
My understanding is that it has already been axed. Microsoft supports product versions for 10 years after their official release. You can expect to see bug fixes, but no new versions.
Can't the big media eco-system collaborate and develop a plug-in instead (open source, platform agnostic, an extension to HTML5 video etc)? I would rather download and install "HTML5 Premium Content Add-On" or have it pre-packaged in my browser/OS any day than have the internet itself be that much more opaque by design.
This is exactly the opposite from what they want, as it allows unapproved 3rd parties to access their website and provide user interfaces they may not like.
This is why they're moving away from public NPAPI and replacing it with a secret CDM API:
> we strongly believe that all standards pertaining to the web should be open. Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards.
Not suggesting iOS would need to support it native or in Safari (though they might choose to), they would only need to allow developers permission to have it as a dependency in their app packages (Netflix.app, BBC.app, etc). it could just be a thin layer on top of HTML5 video element, just to support DRM delivery. Why is this less desirable than it being baked into the HTML spec itself, essentially breaking the open web?
Browsers supporting all relevant W3C specs and all codecs still won't be able to play HTML5-based Netflix.
Playback relies on Netflix's proprietary Content Decryption Module that they've given to Google to bake into ChromeOS.
Netflix is replacing `<object>` + NPAPI plugin with `<video>` + Netflix CDM plugin. So their HTML5 player is as much standard as their HTML4 player was — it's merely a tag to launch a proprietary binary.
Apple would have to license Netflix's CDM plugin and bake it into the iOS in the way that ensures it's usable only in ways approved by Netflix.
There is no way to avoid that, and that's the whole point of EME spec that Netflix+Google+Microsoft pushed through W3C.
Apple also used to have an open letter on their website supporting the notion that all internet standards should be royalty free. Strangely it seems to have been removed.
I'm always pleased with Netflix- their product is good and so is their engineering. I'd consider them the ideal company to work for as much of their product is both cutting edge and customer facing.
Looking at the open positions, I see no internships or entry-level positions in Engineering- anyone have any advice on landing a gig there?
It's great to see Netflix pushing for HTML 5 media encryption, it's one of the things the orignal spec for these elements lacked. Once it becomes standard across the browsers we'll hopefully see more media publishers come onboard supporting HTML 5.
As i understand it, it's a standard API that the browser exposes to external processes. The browser doesn't have any DRM plugins, just EME. the decryption happens outside the browser, and any decryption modules installed on the system will be available to all browsers.
You can say it any way you want, but Apple devices will only support FairPlay (which will not be available on any non-Apple platform) and I would expect Chrome OS to only support Widevine. There will not be interoperability.
No, EME is an API that the browser exposes to site-supplied JavaScript code. The JavaScript code uses EME to talk with a Content Decryption Module (CDM) whose exact characteristics (including the protocol you talk with it; EME sees byte buffers) is unspecified and out of the scope of the EME spec. The interface between the browser and the CDM is not being standardized.
The CDM is basically a new kind of proprietary component that exposes a CDM-specific protocol to the Web and that is annexed to the side of the browser. You should not assume the distribution model to be the same as with traditional plug-ins: E.g. in the case of Chrome OS, the CDM comes from Google itself.
Standard practice. It's really limited support. The Eeebox's video decoding hardware I bought just a few months ago isn't supported by silverlight and probably never will be, which makes watching HD streams on netflix nearly impossible. That's just going to get worse.
I wouldn't assume so quickly that because it works on Chromebooks, it can work on Linux. Google uses a certain type of DRM for Chromebooks, and they've collaborated with Netflix for this.
Only if Netflix chooses to port their HTML5 DRM plug-in (CDM) to Linux and makes the CDM API available to browser vendors (the W3C spec they wrote deliberately does not have this API documented).
And this is unlikely, since Netflix and other cable companies stated they need strong DRM with OS and hardware support (which I presume is what they got in the closed version of ChromeOS).
