W3C takes advantage of the ambiguity of what the EME spec and "standard" DRM is. People unfamiliar with the spec may think it's the end of plug-ins and a spec for a DRM that is somehow open, implementable and cross-browser.
It's nothing like it. It's a small JS API that launches the same old, fully closed, proprietary DRM solutions. The NPAPI has been replaced with DMCA-protected interface, and previously separate DRM plug-ins are now called "modules" and shipped with the browser.
It's as if Chrome, which ships with Flash bundled-in, created a "HTML Multimedia Extensions" spec with just `navigator.launch("com.adobe.flash")` for launching "Multimedia Modules" (details of which are out of scope of the spec), and hailed it as the end of the non-standard Flash and plug-ins.
I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture.
Second, without EME, the state of the art for DRM video was to run the whole playback path through a plugin. Now, only the DRM bit is generally going to be hidden in binary blob (whether plugin or not.)
This has some important advantages:
* Web content authors can build video players using the same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video. No need to learn a whole different plugin environment for this case.
* Video playback only has one code path, instead of totally separate browser and plugin video pipelines. Video codecs are complex, so this means less security attack surface.
* The browser's built-in playback is generally much more power-efficient, meaning more video viewing time on battery for your Netflix/Amazon/Hulu/etc video content.
* Even if the DRM scheme is some form of plugin, it needs far fewer capabilities than a plugin that has full video playback, live streaming, a scripting environment, etc. So it's less of a security risk
* Flash and Silverlight especially were common sources of critical security vulnerabilities and they'll be out of the picture.
* With approaches like MPEG Common Encryption[1], a single encrypted media resource can be used with multiple DRM schemes. This helps content hosts save on storage, and it makes it materially easier for new browsers to enter the market, since they don't have to ask content providers to host a whole separate copy of the video.
The continuing existence of DRM is admittedly not ideal. But supporting it in the browser instead of solely in the separate world of plugins has major user and developer benefits, as described above.
> same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video
this isn't a pro in my books - i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. This makes a non-DRM version much more simple to view (just click and play), so that users would vote with their wallet, and use the non-DRM version (and avoid the DRM version).
If making DRM video easy to play for end users is the goal, then yes, web-DRM is doing it. But it will make DRM more prevailent, as end users will have no reason to try avoid DRM, thus, making web less open.
This already happened. We had Flash and Silverlight. This didn't make the Netflixes of the world drop DRM, and it didn't make customers flee for DRM-free solutions. All it did was decrease security for all of us.
But yes, you do have a point that making DRM easier will likely make more content producers consider and implement DRM than before. I'm not sure there is a good solution to this right now, and yours is just vindictive and actively harmful.
and when apple decides to drop flash support, what happened? Did netflix or any other video content producer suddenly decide to stop supporting those devices? No, they went with html5 video (and at that time, free of DRM). That was a great step forward for DRM free content for the web.
By making the web standard include a mechnism to include DRM natively, this means content producers once again will have a hassle free way to include DRM. The end user won't care as long as they can get their content, but the slippery slope is there, and one day, the web will only contain content that is DRM'ed (and there would be no way of format shifting, or saving the video for offline viewing or sharing). That is not the web I want to see in 5/10 year's time, and the way to stop that is to prevent the cracks from appearing.
It's actively harmful to consumers of content producing companies, but only if those companies do not move to DRM free platforms. But because companies ultimately have to make the user experience smooth, forcing them off DRM like this to make a smooth user experience is worth it in my books.
Did Netflix ever support iOS devices without an app or DRM? Since iOS 6, there’s been FairPlay DRM available in Safari – and it added support for time-limited (expiring) keys in iOS 9. In many ways, I’m less worried about DRM and more worried about the value of content as expectations change to prefer free stuff from YouTube etc. Making things easy to watch/share is one of the only ways to compete...
> and when apple decides to drop flash support, what happened? Did netflix or any other video content producer suddenly decide to stop supporting those devices? No, they went with html5 video (and at that time, free of DRM). That was a great step forward for DRM free content for the web.
That's a figment of your imagination. They used DRM in an app store app.
The answer after Apple dropped Flash support was for everyone to use native iOS apps. This is not a good thing in any way, shape or form.
Imagine if Netflix, Hulu etc. could have used the browser, complete with Chromecast/Airplay support. It would save us all so much wasted phone storage and app downloads.
Maybe, just _maybe_ that would have been a viable pressure point to favour non-DRM content* if we were all running Firefox.
As it is, too many people decided they are OK with a google browser. The answer to: "It's cumbersome to use DRM" is to tell your consumers to use Chrome.
* I find this highly questionable. We have an abundance of examples of media companies favouring DRM over user experience. Clearly they think a less smooth experience is a price worth paying.
> abundance of examples of media companies favouring DRM over user experience.
I don't think media companies particularly care about user experience. They care about control.
Once you have a piece of content (which you didn't produce) in your hands, and an exclusive distribution contract to guarantee the content producer can't go elsewhere - you have a monopoly over the content in question. DRM is an abhorrent, if natural, extension of this control-freakery. After all, you don't want to provide consumers control over how they view YOUR[0] precious content.
The ingrateful bastards might find a way to enjoy the content without going through the hoops you've carefully put in place. What good would a monopoly be? As the sole content distributor, the last thing you want is competition.
0: Nope, you still didn't produce it. Someone else did. But now you own it.
> and when apple decides to drop flash support, what happened? Did netflix or any other video content producer suddenly decide to stop supporting those devices? No, they went with html5 video (and at that time, free of DRM). That was a great step forward for DRM free content for the web.
Unambiguously, no, they didn't.
They used applications that had Playready or Adobe Access or Widevine built in, or a little bit later they used Apple FairPlay inside the browser. Some also used root level Apple certificates to limit streams to iOS devices only.
Flash and Silverlight were low friction. And both are deprecated or unavailable on a lot of players now.
Making DRM harder for the end user is the only effective push-back. It worked for music. It's working for e-Books. It would have worked for movies... if it wasn't for this.
or, if DRM-free streaming is there, "get netflix on all your devices with a browser, no plugin or installation needed! Netflix everywhere, on your fridge, on your car's video player etc"
> i want DRM to be a difficult and cumbersome stack to use
Exactly. Even flash plugins are too easy, really, so long as flash is ubiquitous. NOW would be the time to hit it, as flash is less common (almost completely absent on mobile) and silverlight is deprecated.
Imagine if Apple and Microsoft and Real had agreed on an easy and ubiquitous plugin framework for music DRM.
We would still be dealing with near-universal DRM for music today.
That's a very principled position but it should not surprise you that any position with 'make things shittier for users' as a key component is unlikely to be well-received by any and all of: standards bodies, browser vendors, content providers, website developers, users, sane people and many others.
Content providers have happily made experience utterly shitty by adding DRM with no regards to users. I don't think they care about your experience a lot.
They seem to care quite a bit. For instance, browser-based DRM and constrained devices have made the experience vastly better than it was just a few years ago. No plugins, you can download content for offline viewing, etc. So I'm not really seeing how they're making it utterly shitty.
How is not being able to download files at all, not being able to just move them to another device and being forced to have a n internet connection to watch HDR Blu-Rays a better experience than just double clicking a mp4 file?
You're not forced the have an internet connection to watch UHD Blu-rays.
The spec allows a disc to require it, but it not a single disc has ever turned it on. It was also in the blu-ray spec, and not a single disc ever turned it on there either.
Sure, but for the vast majority of users, the experience is much better. You can certainly argue that they should care more about minority users such as yourself (and me, Linux desktop user here), but it's a hard sell when the cost of the development and maintenance effort exceeds the revenue brought in.
I don't think there's a great solution here. Content producers believe that DRM reduces copyright infringement to a level that they're at least somewhat comfortable with. Whether that's true or not is irrelevant; it's how they feel about it that matters. Making playback harder for the average customer isn't in anyone's best interests.
This started with someone claiming what should happen is DRM'ed video streaming should be made a difficult and unpleasant experience. Standards bodies and implementors aren't going to do that. What's more, their collective efforts have made the usability better, the availability of content better and as a free bonus, the security is better. That's all.
> DRM'ed video streaming should be made a difficult and unpleasant experience.
why can't DRM'ed video be difficult and unpleasant, but DRM-free videos be made much easier to implement, and have smooth experience for end users?
Why is DRM-free a non-starter? The whole point i wanted to make is that by making DRM'ed video easier to deploy (and consume), it normalizes the fact that _it's DRM_. Why are standards bodies putting in standards that consumers wouldn't ordinarily chooses, and is only meant to appease businesses? Why couldn't they be more socially oriented, such that anti-consumer mechanisms aren't added to an open standard?
Imagine if it weren't DRM, but anti-adblocking? What if the web standards bodies were attempting to prevent adblocking in a browser, in such a way that to be a compliant browser, you can't possibly intercept content? How is that any different to this DRM standard?
That ship has long, long sailed and, despite all predictions to the contrary, has actually been pretty good for users. Again, it's you who suggested everyone should stop and shittify the existing user experience that most people like. That's neither realistic nor constructive.
Earlier this year I downloaded a season of a TV show I wanted to catch up on, into Google Play on my tablet. A few weeks later I was on a plane, and finally had a chance to watch them. Google Play had blithely decided to save space (possibly prompted by the OS) and had removed my downloads.
If they weren't DRMed I would have just downloaded them into space I control and there would have been none of this "oh he's not interested" BS guessing.
I deal with this kind of bovine exhaust regularly.
So, hell, no, DRM has NOT IN ANY WAY been good for me. ANYTHING that makes DRM less viable is an absolute good. Period.
> i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM.
so you want to make stuff like netflix as much of a PITA as possible? why? why be this vindictive?
i agree with netflix, straight up. they invest quite a lot in infrastructure and production to provide these videos, and making it simpler for average folks to get their protected videos in a profitable manner is a win for everyone except idealistic pirates. i don't get why i'd care about the needs of the people who want to ruin a fertile ecosystem for some abstract principle.
With DRM+streaming as default the world will be relying on rights holders and streaming services to preserve an archive of cultural works. A situation that invariably will result in loss of a lot of those works once they stop caring or go out of business.
Consider f.ex. the situation with the missing Dr. Who episodes. BBC is still hopping it can recover copies from the public. Had they'd been aired with DRM at the time they would be lost without hope, now at least there is hope.
> Netflix should just make a native app, like everyone else who needs drm do.
The native app security model on desktop (i.e. can do anything) doesn't make the notion of letting streaming services run native apps look so great.
Do you really prefer giving streaming services (not just Netflix but others too) fully-privileged code execution instead of having an operating system or browser vendors exercise some oversight?
If you read the EME spec, unless they've changed you're not guaranteed to be able to overlay anything over the EME-provided video rectangle using HTML. The only cross-platform approach is to treat it as an opaque, untouchable area that does not interact with the HTML side of things in any way, like the bad old early days of plugins. Also, at least on Android the playback chain goes through TrustZone code that's effectively running at a higher privilege level than the kernel.
>Video playback only has one code path, instead of totally separate browser and plugin video pipelines. Video codecs are complex, so this means less security attack surface.
Nope. For any effective DRM (aka what all browsers use) the video codec decoding happens inside the DRM module. Otherwise anyone could just patch the open source browser and grab the decrypted compressed content coming out of the module. In reality, they can only grab the decrypted decompressed content.
In the browser I'm most familiar with the internals of: most of the playback logic is done by shared software, and the decode of the video track is done in hardware in the common case, for both encrypted and unencrypted videos. There are some forks in the path but a lot of commonality.
Plus having a single blob responsible for, and only for, the DRM part means that hackers will have an easier time crack that, instead of a whole player. So we should get workarounds quite quickly.
Note that part of standard DRM schemes is also "Computer verification" - e.g. that they refuse to work if your PC doesn't have the correct kernel, drivers or software installed. If you need special drivers to fix compatibility, want to customize your Android or do anything but leave your system full untouched and bloated, might be that you'll be prevented from watching online videos.
One of the key arguments when Mozilla decided to implement EME was that the crappy-proprietary-code could be sandboxed by firefox to ensure that it doesn't infect a system with malware, spy on users, etc.
From a security perspective it's light years better than flash and other crappy plugins.
And when they did that, the Content providers responded by saying "Ok then we will only allow you access to low quality content" i.e you can only stream upto 1280x720 resolution on firefox, no 1080 content, and no 4K content..
Today that has low impact, in a few years that situation will be untenable for FF and they will be "forced" to cave once again in order to appease users that do not care about privacy or security
Before DRM plugins could access anything. Now they live in a sandbox which was not possible when they were NPAPI plugins. So the security story is actually much better as far as I know.
It still sucks to infect the web with this nonsense, but at least it can't do as much evil crap.
Now the DRM plugin can only access the DRM subsystem installed on your machine that has root enough access to verify your files, OS version, and graphics drivers, as well as a callchain allowing them to make draw calls to your GPU driver.
It's nothing like it. It's a small JS API that launches the same old, fully closed, proprietary DRM solutions. The NPAPI has been replaced with DMCA-protected interface, and previously separate DRM plug-ins are now called "modules" and shipped with the browser.
It's as if Chrome, which ships with Flash bundled-in, created a "HTML Multimedia Extensions" spec with just `navigator.launch("com.adobe.flash")` for launching "Multimedia Modules" (details of which are out of scope of the spec), and hailed it as the end of the non-standard Flash and plug-ins.