Tim Berners-Lee approves Web DRM, but W3C members have two weeks to appeal
defectivebydesign.org
defectivebydesign.org
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.
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.
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
Don't forget that vendors like Netflix aren't proponents of DRM, it complicates their streaming architecture and costs a lot of money.
In a future where Netflix and other streaming services makes up a large part of the profit for content owners, we might see DRM disappearing.
Look at how Apple was able to sell DRM free music because their volume was high.
It still sucks to infect the web with this nonsense, but at least it can't do as much evil crap.
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.
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.
so you want to make stuff like netflix as much of a PITA as possible? why? why be this vindictive?
(And please don't come back with "Netflix has no choice BS", they're happily doing all the nasty DRM crap for their own production as well.)
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.
Not op but yes, using DRM in a browser should be hard.
Netflix should just make a native app, like everyone else who needs drm do.
This clearly scopes what is open and webby and what is closed and DRMy.
Nobody has issues installing Spotify to stream music. What makes Netflix special?
Spotify does have a web player using web DRM (Widevine) and a lot of people use it exclusively.
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 use less popular platforms (Linux, Ubuntu Phone, etc) DRM makes it impossible to access content you paid for.
Also if you Root Android, or modify the "approved" platforms in anyway... BAM the DRM kicks you out of your paid for content as well
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.
Yes and that is how a Technical Standards body should be making decisions, based on people/companies feelings ....
That is filling me with Confidence that the open web is in good hands with the w3c...
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.
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.
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.
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.
The argument has a tiny issue in that it's not actually true. At all.
That's a figment of your imagination. They used DRM in an app store app.
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.
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.
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.
EDIT: grammar fix in footnote
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.
Unambiguously, this argument is factually false.
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.
How is it working for ebooks, when the leading vendor has introduced more severe DRM?
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.
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.
Assuming the W3C committee voted down the EME standard, at this late point in the game and with no competing standard to satisfy the use case, what stops Google, Mozilla, Apple, and Microsoft from just implementing the standard as-drafted without the W3C's sign-off?
At that point, the browsers will be enabling functionality that browsers that don't implement EME support can't enable, media channels can take advantage of EME-supported encryption modules, users will see less functionality in other browsers and therefore have soft incentive to migrate away from other browsers, and it becomes incumbent upon the W3C to either release documentation describing already-existing browser functionality (as they've so often had to do) or be ever-so-slightly inaccurate as an authoritative source for describing web standards.
Back when IExplorer had a 90% market share, you could have argued that ActiveX needs to be a web standard. But it wasn't considered a standard even if it was a de facto one and now ActiveX is gone.
I must be getting old if I'm talking with people that don't remember the browser wars or what web standards are about.
A single user-agent technology shouldn't be standardized because that user agent has large marketshare. A tech should be standardized because multiple user agents want to use it, and be interoperable. The ActiveX comparison doesn't make much sense to me.
Mozilla could have implemented ActiveX btw, but they took a stand against it.
So by your definition, what does "many" mean? Is it more than one? More than two perhaps? Should it be all of them?
What if I create a browser and announce that it will not support DRM. If market share isn't important, shouldn't this proposal be dropped?
Yes, web standards are about interoperability, but the problem is that DRM being fundamentally broken it means that open source browsers running on open platforms won't be able to "interoperate", which in my book means that this can't be a standard.
Standards serve the purpose of when user agents want to interoperate, so Mozilla was definitely ok with not implementing ActiveX, just as they would be ok with not implementing EME.
But if Chrome and Safari and Edge all want to interoperate with EME, they're going to do that. Whether it's a W3C standard or a WHATWG standard, or an RFC, or a IHateFreeSoftworeSociety standard doesn't really matter. It's just whether W3C wants to be part of the conversation or not. I see little benefit and little downside to having it be a W3C standard vs. anything else. Or even for that matter, whether the term "standard" is used; even if it's somehow disallowed it's still the same situation.
Yep, it is called WebAssembly.
1) Ted Nelson's vision on how Project Xanadu would have some form of copyright protection / micropayments for authors.
2) Independent content creators that have called it quits. There's tons of examples, but here's one that highlights issues: http://www.tonycomstock.com/2011/09/12/why-i-dont-make-movie...
I guess I see a vision where webDRM is an improvement over the walls of 'Apps' where content may not be DRM-free, but at least be linkable/URL-addressable.
(Disclaimer: I'm writing this without actually reading into the WebDRM spec, so feel free to criticize)
Example: DRM music hasn't stopped music piracy, but better models for the content distribution (i.e. DRM music platforms like spotify, etc.) have demotivated more people from bothering to pirate music.
Wrong. It works incredibly well. That's why the anti-piracy companies are all up in arms over things like PopcornTime. All you need are a couple of other people to download from. Hell, there's whole pieces of software whose whole purpose it is to stream torrents and they do it extremely well. Nothing even compares to the video quality, which is the same as if you downloaded the file ahead of time.
"TOR, vpns etc. aren't well suited for content distribution."
WTF does this mean? You can't distribute content over Tor or VPNs? I only do it every single fucking day without any problems and with ease.
"Due to DMCA, anonymity is a major obstacle for which there isn't a good solution yet."
The DMCA created anonymity? Whatever, I'm not even going to try to understand this one.
Not sure if you are trying to be intentionally dense. Have you heard of DMCA notices ? You get them if your IP is in the swarm, and are uploading copyrighted content. Hence the need for anonymity.
>WTF does this mean? You can't distribute content over Tor or VPNs?
Again, you seem to like being thick for no reason. You can distribute content over every medium imaginable. That doesn't make it the best or an efficient medium.
>Wrong. It works incredibly well.
You can't have adaptive streaming bitrates. The tracker model still relies on a central tracker. Magnet links solve some of those issues, but not everything. There are still some things that are, or would be better off, being centralised. There are several limitations that we don't need to go into length, but it's a far cry from incredible.
It can have all the drm it wants. It's not part of the open web.
Denuvo has gained widespread adoption among AAA game publishers because it tends to hold for the critical period when a game first goes on sale. The DRM is typically broken within weeks but that is good enough for the publisher, as the release period has generally passed by that point. They made their sales.
(This isn't to argue in favor of DRM on the web. It ought to stay in its restricted-device ghetto.)
If web-based DRM actually does remove the browser as an attack vector entirely, and the majority of copyright infringement occurs in other places (studio leaks, etc.), then the content producers might see that as acceptable.
Regardless of all that, I think the distinction is more a philosophical one: you seem to believe that the creative output involved in a game is more reasonable to protect than the creative output involved in a movie, just because of the method of consumption. I think the "human liberty" aspect is a bit much, as well: why do you think you're entitled to the content (on "your terms") that someone else has labored to create?
We can certainly argue (and probably agree) that things like copyright terms are effectively unlimited and that's wrong, and even if they were limited, DRM doesn't give you the ability to get at the content DRM-free after copyright has expired. But I don't see it as unreasonable that a content producer should be able to use technical means to protect their content for a period of time after initial distribution. I think the current implementations of DRM leave a ton to be desired, but I think the concept is sound.
I think overall, though, it's a matter of market forces. People consume "pirated" content because either they can't get the content and consume it in a manner that they want to (and feel strongly enough about that to not settle for the "approved" channel), or people pirate things because they believe the price is too high for a legit copy (and then there are those who just won't pay anything at all, no matter what the price). DRM for music purchases has been largely dropped because people are happy enough with the distribution channels and price that they usually don't look for pirated copies, at least not to the extent that makes the content producers nervous. Will we eventually get to the same place with video? I don't know.
When it comes to suing someone for distributing a work they copied, like you I don't see a difference between a game and a movie.
(added: I dunno why you were downvoted.)
What you're missing is that this delay is fundamentally impossible. The day a movie is available, it will be ripped, no matter how good the DRM is.
Game DRM can hold people off, because the game actually has to run once pirated. Game DRM has to be broken. Movie/audio DRM doesn't have to be broken; it can be ignored entirely by pirates.
The thing is, those "dongle-based protection" have been pirated in the past only in the rare cases where an issue was found in the dongle scheme or keys where leaked, etc. And those don't happen frequently -- whereas any old school copy protection method was broken a few days/weeks at most post release (sometimes even before release, from the demo/alpha versions).
Hasn't happened in 5-10 years for lots of physical key based products, so even if possible again, it's of theoritical and not practical value (we ain't seeing them anytime soon).
I guess they've stopped being lousy at the implementation.
#1 on most of their lists is getting the music/name out. DRM is counterproductive.
So I have this idea for a video/audio streaming website that operates like an open market. Website operator makes a cut for infrastructure costs. Other than that, the site runs pretty much on its own. No content deals, no drm, no geo restrictions, no ads. Some safeguards to limit abuse. A producer puts up content. Consumers consume content. Revenues are split between producers using some fair and transparent proportionality metric. Would there be any appetite for such a model ?
Not sure if it fulfills everything and I like your model better.
Does not compute.
The EME/DRM spec is a bit different in which we still have DRM and it still sucks, but this DRM is now running on a sandbox environment and is standardized which makes it much easier to audit and a lot safer to use in terms of privacy for the user.
Of course "no DRM" is a better solution than "any DRM", but that is a pointless debate because content distributors are already onboard with DRM and there is no turning them back. The W3C spec is a compromise, a solution that enables those wanting to use DRM to be able to do so while we maintain some method of sandbox, privacy and safety. Running a module in EME/DRM is probably much safer than doing the same thing now with custom browser plugins.
As for the discussion of "browser X should not implement it, traitors!!!! Hate you forever!!! Will switch to $MORE_PROPRIETARY_ALTERNATIVE" is also a shortsighted argument in my opinion. If a browser doesn't implement EME/DRM spec, they shut their users out from being able to use many websites that employ DRM and what will happen is that that browser will loose users. If every single browser said "no to DRM" except for a single one, you'd see everyone installing that browser just to be able to play Netflix.
No browser can afford to loose millions of users by not implementing the spec. Those users matters. In terms of browser vendor political weight in spec discussions, user count matters. The DRM battle is a lost one because the content producers/distributors already decided to use it.
Now, if you're against DRM, instead of complaining about W3C spec'ing it out and browser vendors implementing it. You should stop using DRM content. No one is stopping anyone from preferring non-DRM solutions. For example, I don't like light beer, the existence of light beer sounds wrong for me, so I don't drink it but I don't try to stop others from drinking said watery yellow-ish drink. It is the same thing with DRM, instead of focusing your actions on W3C and browser vendors, focus your effort in content producers/distributors, prefer other solutions, make them ponder if it is worth loosing you.
I see this said many times, and it is highly over rated. while Technically speaking yes it calls for a "sandbox" but the need for "Computer Verification" means the CDM has to have full access to the entire system to verify the evil user is not attempting to capture the output. So the sandbox is not really protecting much unless the operating system itself has the CDM integrated as is the case for Windows. So on windows the CDM might be in a functional sandbox but on linux or any other non-proprietary system it is unlikely the sandbox will protect the user from a bad CDM, and given windows track record for security I would not put much faith in their sandbox either.
On the security front I do not believe it has changed much, this idea that the CDM will be more secure seems to be more PR Marketing than actual fact. Further given the refusal of companies to sign onto a Non-Aggression Pledge to protect researchers from DMCA liability it is likely any security issues in the CDM's will go unreported for fear of legal repercussions.
>>>Now, if you're against DRM, instead of complaining about W3C spec'ing it out and browser vendors implementing it. You should stop using DRM content.
Why can a person not do both? Why does a person that has ethical problems with DRM, and view the actual existence of DRM is a threat to their personal liberty be silenced or told to STFU as you have here?
Bad ideas, like DRM, should be continually criticized until they are dead. Vocal opposition as well as monetary boycotts are both valid and should be used to oppose bad ideas like DRM
One of the reason people are opposing video DRM so strongly at the w3c level is we fear it will not stop with Video. Images, Ebooks, Fonts even the web pages themselves are all a target for DRM Supporters. There will come a time that the F12 tools will be useless because the entire page itself is being served via a locked down CDM style plugin. This is just the first phase of killing the Open Web in its entirety
[I]n Firefox the sandbox prohibits the CDM from fingerprinting the user’s device. Instead, the CDM asks the sandbox to supply a per-device unique identifier. This sandbox-generated unique identifier allows the CDM to bind content to a single device as the content industry insists on, but it does so without revealing additional information about the user or the user’s device. In addition, we vary this unique identifier per site (each site is presented a different device identifier) to make it more difficult to track users across sites with this identifier.
https://hacks.mozilla.org/2014/05/reconciling-mozillas-missi...
The sandbox has also changed as have the requirements from vendors and content provider. and while firefox has protected the user better than others, this is also why Firefox is restricted to 720p by all content providers and will likely never get anything more than 720p because they do not allow the deep Operating system inspection and bypasses required to allow for HD and 4K content.
Currently only MS PlayReady on windows 10 is allowed to play back Netflix 4K content because PlayReady is built into the Operating System and treats the User as the enemy.
Mozilla in their ever ending chase to recover some market share has proven time and time again they will sacrifice privacy, and their more Technical User base in order to keep up with Chrome and get back some "regular users" So if Netflix says "We will give you HD content if you drop the sandbox and give widevine full access to the users system" I have little reason to believe Mozilla will not say "Yes Sir Mr. Hastings, anything you want"
Pirates have created markets where there were none and are an important part of every entertainment eco-system. It's been that way since the beginning.
This is just another in a long string of bad decisions that attempts to give major distribution channels far more control than they deserve or could ever manage responsibly.
If you want to make money in entertainment, the business plan is simple. 1. Get people to like you. 2. Find a way for those people to get you money. You don't need Google, Netflix, Apple, NBC, CBS, ABC, RKO, ClearChannel, or anybody else that inserts themselves between you and your customers. None of them provides enough real value to anybody who didn't already have a market before leveraging them.
The fact that this standard is coming to be is just plain silly, but it does no harm in and of itself. All of the potential problems are today's reality. A rubber stamp by W3C implementing a tag in the HTML spec and blessing a workflow change nothing.
The FSF is stirring up noise without providing links to what it's talking about. I presume it's this: https://www.w3.org/TR/encrypted-media/
The workflow isn't particularly well thought out - it's not significantly different than what RealMedia or Adobe have had put together for a generation.
The real downside is the fact that browsers will be further plagued with vague integrations. Those integrations will all carry security ramifications that nobody cares to consider until a major exploit is publicized. The fact that so many people are willing to sacrifice their security for access to a 12 year old lionsgate video is beyond me, but such is the nature of the world we live in. Like I said before though... that is a problem that browsers face today. The new "standard" doesn't change much in reality.
If that's true, for you and for others who share that opinion, what does it matter?
> None of them provides enough real value to anybody who didn't already have a market before leveraging them.
It's hard to take a position like "digital distributors offer no value" seriously when the paid digital media marketplace was created by said distributors.
I don't have a dog in the race. For me, it doesn't. The world would be a better place without DRM and it would be a better place without TSA, but I can do nothing about either.
> It's hard to take a position like "digital distributors offer no value" seriously when the paid digital media marketplace was created by said distributors.
The market was created by Napster and it's cousins. The ability to hand over money was a matter of getting the music labels and movie studios on board - and half of them are still reluctant participants at this point. Anybody can give them money. None of them provides exclusive access to a customer base, and none of them provide a significant boost to sales for products without their own separate marketing.
There's a "Netflix for..." so many different markets because all you need to do is sign a contract with the studios for access to media which they'll deliver directly to customers themselves.
During the time when Tower Records or Target actually provided access to customers that nobody else could provide, the distribution channels were valuable. Now what they accomplish is a simple and easily repeatable commodity.
I disagree that it does no harm. I agree with this quote from the article:
"If EME is ratified by the W3C, the FSF expects it to cause a long-term increase in the amount of DRM on the Web, by simplifying the DRM implementation process for streaming services."
Standardization is explicit support and encouragement.
I would agree with the FSF statement that there will be more DRM on the web.
Where I differ is that I believe it would happen regardless. If it's not standard DRM, then it's Apple DRM and Windows DRM... like we already have.
> Standardization is explicit support and encouragement.
Standardization shouldn't be about good or bad. If enough people want to do something, there should be a standard.
Having said all of that, please don't get me wrong. I'm just clarifying how I feel. I do tend to have unpopular opinions. I don't have a dog in the race and I would be perfectly OK with DRM in general being rejected by the W3C because it is a terrible concept that ends up being paid for by consumers.
which is fragmentation, and bad for businesses that want DRM, but don't want to _pay_ the cost of fragmentation. By adding it to an open standard, they no longer need to deal with end fragmentation (which causes end user a bad experience). But the solution was never to standardize on DRM, but to standardize on _non-DRM_ formats! The pirates can obtain content regardless - DRM only hurts consumers in the long run.
As much as I would like to avoid DRM, relatively few producers are going to budge on the issue. The only options are standardized DRM, non-standardized extensions to provide DRM, or simply doing without. None of the options are particularly desirable. This one is likely the best of the three.
There is no rule that industries whose business is built on copyright need to be able to live in the browser. Netflix demonstrated that quite nicely. Just because the want it doesn't mean they should get it. I personally cripple EME on my browsers, and if your content won't display for me, I'll happily go elsewhere. (Haven't had the problem yet, but fully expect to.)
It is bad enough, but unsurprising, that the closed browsers would go along with user-hostile bullshit like this. That Mozilla did, I find appalling.
Microsoft and Google make CDMs; no one else had a chance in this fight.
While probably correct since the majority of users do seem to like Netflix, others ignore Netflix and get their media through, shall we say more "obscure" sources. Such an obscure browser would seem to suit their needs just fine. Tor Browser doesn't need to be popular among the masses for those who use it to find lots of value in using it, for example.
That doesn't remove the ability of a minority of users to use something different and make use of the more "obscure" sources, but it does allow the majority of non-technical users who don't care one bit about all this to play the content they want, and in a way that protects their security much better than the old plugin-based approach.
As a relevant comparison, I think the current situation with the plethora of proprietary video game DRM solutions that are universally recognised to be terrible is strictly preferable to an alternative world in which video game DRM Just Works™, possibly with hardware support: in no small part thanks to it, we have a healthy amount of pressure on game studios to hold back and a market for DRM-free publishers such as GOG, and perhaps more controversially a healthy piracy ecosystem to punish the worst actors in the market.
I don't agree. Ignoring the massive injustice of ramming proprietary extensions into an open standard, standardising DRM has several secondary detriments to the free culture movement. In fact, standardising EME might actually be the worst of the three choices (the best being no DRM of course). Non-standard extensions are better to the movement (though still disastrous) than standardised ones, and here's why.
The most serious one is that it will appear to be far more convenient. One of the man ways that we could appeal to users who didn't particularly care about their software freedom being trampled on by corporations is that the method they used to trample on their freedoms were inelegant. Your monitor would flicker (and software would break) when it went to HDCP mode, Netflix might break every once in a while, Flash websites always were incredibly buggy. Meanwhile, VLC and family always just worked. Now, EME will make this experience "more seamless" which is a huge downside because now users won't even be aware of how many of their freedoms are being taken away.
The second is that now DRM is more appealing than it might've been 5 years ago. DRM isn't some horrible Flash applet that nobody understands the inner workings of, and when it breaks then you just have to deal with it. It's a standardised system around which more cabals will form. It's not something that just the AAC conspiracy operates around, it's far more accessible. If you thought that Blu-Ray was insane, you've seen nothing yet.
Every Flash vulnerability was a reminder that the status quo was not acceptable. Sure, the reminder came about for the wrong reasons (it turns out the pawns behind a conspiracy aren't generally very good at conspiring), but it came nonetheless. Now that EME will presumably be secure enough, all of these secondary issues that acted as entry-points for people to learn about how badly they are being mistreated will no longer be accessible. "Who needs a copy of their data when you can just stream it with a proprietary player that probably tracks you?"
I disagree with that goal being primary when it comes at the expense of user freedoms.
I for one prefer taking a small risk rather than living in some dystopia where all software must either run in crippled sandboxes or be approved by the central ruling committee for trusted computing.
Maybe this comes from a lack of technical literacy. Maybe it comes from the fact that Microsoft and other large corporations indoctrinate children into thinking that proprietary software is acceptable. I don't know, and that is another front that needs to be fought.
However this is only one of the detriments that I listed of standardising EME.
> Keeping people's computers safe is a primary goal of browser vendors, and this improves that state of affairs.
It's unfortunate that this is the case. Don't get me wrong, security is very important, but security should not be the primary goal. The primary goal should be user freedom, with all other goals secondary.
To butcher a quote, "Those who would give up freedom, to purchase a little temporary security, deserve neither freedom nor security."
> Sure, DRM sucks, but at least the vendors can't root your machine and install keyloggers now.
Why are we as a community saying that corporations are allowed to piggyback on the hard work of the free software community to entrap users? Just because they might not be able to repeat their previous unethical and illegal actions such as installing rootkits (which I'm not sure I agree is accurate).
What work of the free software community? Except for Firefox, all browsers with any market share are developed by big corporations.
Not to mention that Chromium is a free sofware project. It doesn't matter that the largest contributor is Google (it does for the top-level discussion of why the hell did Chromium implement this), the project itself is free software and is thus part of the free software community.
I don't necessarily disagree, but I don't see how that's relevant to "bigcorps piggybacking on the work by the free software community". I'm pretty sure media corps would be fine with an IE world.
Not to mention that Chromium is a free sofware project. It doesn't matter that the largest contributor is Google (it does for the top-level discussion of why the hell did Chromium implement this), the project itself is free software and is thus part of the free software community.
Chromium is developed by the work paid by bigcorps, not by the free software community. The code being open source doesn't change this.
But that's not the world we live in. We live in a world where Firefox saved the web, Chrom{e,ium} has changed it as well (though they have done plenty of things I think are horrible). In _that world_, they are trying to piggyback off the current state of the web's open standards by adding extensions that will only work because the same browsers that made the web what it is today are now forced to implement EME.
> Chromium is developed by the work paid by bigcorps, not by the free software community. The code being open source doesn't change this.
By that logic, Linux is not developed by the free software community (80% of kernel development is done by developers paid by companies -- which I think is great).
They would budge if they had to - what are they going to do, stop selling their only product to paying customers out of spite? But of course it doesn't cost them anything to bluff, and they are used to get their way far beyond what their importance merits.
Imagine if, back in the 90s, bigcorp still-image licensors like Getty or Bridgeman were able to magically foresee how big the internet was going to be. They campaign hard to include a DRM standard into the 90s web, so that nobody could right click and "save as" images from the web. After all, their bread-and-butter is licensing images. They succeed, and now it's the 90s, the web is in its infancy, and nobody can share or save images.
How would have the web evolved differently, if that was the case? I think most of us would agree that this would have put a terrible stranglehold on the evolution of the web as a technology and the web as a cultural force.
We're in a similar position today. Video is fairly new to the web, and bigcorp see how important a deal the web is. Instead of us making a stand and demanding the same freedom we got with images (freedom we largely received because of a combination of ignorance and benign neglect), we've caved and allowed videos to be locked away. Now we'll never see how the web could have evolved if anyone could have right click "saved as" a video.
Google and Microsoft both sell the CDMs (content decryption modules, ie, the actual DRM components used in EME), and it was certainly a benefit they touted for consumers before Firefox had an implementation as well.
Now anyone who wants to make a web browser must pay to play, and the people you pay are your competitors. Even if you could write your own CDM and get it ceritifed/trusted or whatever, you'd still have to convince every DRM-using video provider to also use it in addition to the others, which is going to be a very tough sell. And of course, it may be that no one wants to license a CDM to you to start with, and now part of the web is closed off to your users.
As someone else pointed here:
> You can't simultaneously give us the content and not give us the content.
So in principle fully encrypted paths that can'e be screengrabbed exist. Not all DRM makes use of those components because it excludes users which don't hardware which supports it. But it is there.
> .. which passes it encrypted via HDCP2 to the monitor.
And where does the decryption actually takes place?
> EDIT
https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content...
> In order to make a device that plays HDCP-enabled work, the manufacturer must obtain a license from Intel subsidiary Digital Content Protection LLC, pay an annual fee, and submit to various conditions.[5][6][7] For example, the device cannot be designed to copy; it must "frustrate attempts to defeat the content protection requirements";[7] it must not transmit high definition protected video to non-HDCP receivers; and DVD-Audio works can be played only at CD-audio quality[7] by non-HDCP digital audio outputs (analog audio outputs have no quality limits).
This sounds quite far-fetched though. I'm quite sure we're going to see people literally recording their TV screen with a hand-camera soon.
How about the case where the hardware doesn't support it. Would screen-grabbing be possible then? Where will the decryption take place in that case?
You don't get the content then. Full stop.
There essentially are several tiers of DRM
- hardware-assisted encrypted pipelines (described above)
- kernel module assisted
- pure userspace obfuscated code
If it's in userspace, such as some software DVD players or game DRM then you can use a debugger to dump the keys or maybe hook some method that sends the frames to the gfx card.If it's kernel-assisted you would have to bypass kernel module signing and hook deep into the operating system because the OS will also prevent screengrabbing of the protected surface.
If it is hardware assisted you will have to find a flaw somewhere in the pipeline or buy devices that contain decryption chips that basically are repurposed official decryption chips.
This is the worrying part. While DRM has always existed, it has always been possible to defeat it largely because any software can be reverse engineered. Once you get down to the processor, it's close to impossible. And it's not like we have a lot of processor companies.
The only time there has been a half successful splintering off of the W3C was WHATWG, and WHATWG only worked because it was backed by the browser vendors themselves.
You can't simultaneously give us the content and not give us the content.
WebDRM is broken by default and pushing it is just absolutely retarded.
So the options are:
1. Stick to your guns and keep it out of the standard, free browsers will be unable to play Netflix, Hulu, HBOGo, BBC, etc... Propriety plugins that only work on one browser and/or one platform will exist and be annoying and buggy.
2. Give in and allow this braindamage in the standard because it means most browsers will be able to support video streaming from most sites.
3. Convince the MPAA and all of their members and all of the worldwide organizations like it that DRM is bad and that they should stop demanding it.
In the realm of what the W3C can accomplish, #2 seems like the least worst solution.
Why in the world would you want to subsidize Netflix's development?
So what if Netflix's DRM plugin would be proprietary and buggy? Heck, that's a window of opportunity for DRM-free competition.
By making it a standard it means that we'll never, ever get rid of it. Even if DRM is fundamentally flawed.
#2 is in fact the worst solution.
Devil's advocate, I'm no fan of DRM, but from the end user's point of view, it's a necessity.
The biggest problem with taking the principled stand is that you run into the prisoner's dilemma. And every CS student can tell you that the game theory says you should always defect, if the other parties are adversarial.
I think the biggest problem in the "browser game" is that the different free browsers often see each other as enemies and not as friendly competition. It's a shame because monocultures are what almost killed the internet in the early days, and I don't understand why we're heading back to ActiveX.
By not making it a standard we'll make sure that Neflix never, ever comes to Linux. That guarantees that proprietary operating systems, browsers and hardware will always be prevalent.
> By making it a standard it means that we'll never, ever get rid of it.
<marquee> and <blink> were standards. NPAPI was a quasi-standard.
Black-and-white worldviews are often accurate albeit negligently unrealistic.
Isn't the EME a system binary that would be specific to each platform? There's no guarantee tat they'll be a linux one for each provider.
The point is since it's not standard Linux and BSD will get the shaft.
Netflix already works on Linux, with Chrome and Firefox: https://help.netflix.com/en/node/23742
It uses EME with closed-source CDMs bundled with the browser (Chrome) or downloaded by the browser (Firefox).
What giving in achieved is a reasonable security story around the CDM module as opposed to the free for all of NPAPI plugins. It still totally sucks, but at least hte capabilities of these CDMs are quite limited.
You actually mostly can, today, and "mostly" is good enough for the content producers.
If you have a DRM pipeline that has software and hardware that validates that it hasn't been tampered with (which is absolutely possible with today's technology), then the best an "attacker" can do is point a camera at the display device (and live with the reduced quality that brings), at least not without spending a ton of money on expensive hardware to defeat this.
And as another poster pointed out, DRM isn't really about protecting content from piracy, it's more about content producers having leverage over the people who make content-consumption technology. And it's working quite well for them for that purpose.
Orwell, 1984 - A very sad day, a very poor decision:
"Today, the W3C announced that it would publish its DRM standard with no protections and no compromises at all, stating that W3C Director Tim Berners-Lee had concluded that the objections raised "had already been addressed" or that they were "overruled."
"EFF understood that the W3C had members who wanted to make DRM, so we suggested a compromise: a covenant, modeled on the existing W3C member-agreement, that would require members to make a binding promise only to use the law to attack people who infringed copyright, and to leave people alone if they bypassed DRM for legal reasons, like making W3C-standardized video more accessible for people with disabilities.
This was a very popular idea. It was endorsed by Unesco, by the Internet Archive, by the creator of the W3C's existing membership agreement, by hundreds of top security researchers, by the competition expert who coined the term "Net Neutrality", and by hundreds of human rights organizations and activists from the global south. The Open Source Initiative amended its definition of "open standard" so that DRM standards could only qualify as a "open" if they protected legitimate activity.
Now, it's fair to say that the W3C's DRM advocates didn't like the idea. After a perfunctory discussion process (during which some progress was made), they walked away from the negotiations, and the W3C decided to allow the standardization work to continue despite their unwillingness to compromise."[1]
https://www.eff.org/deeplinks/2017/07/amid-unprecedented-con...
I want two things, at least, from the web:
1. An open platform where I can post content on my own web site, link to other people's web sites, and let them link to my sites.
2. I like to buy access to entertainment: Google Play Music and Movies, Netflix, Hulu, and HBO Now.
Ideally I should be able to have both of theses modes of using the web, and people who don't want DRM should be able to disable DRM and rent Bluray movies, check movies out of their local libraries, etc. There are some producers, like Spiritual Circle Cinema and others, who sell DRM free video.
I would like to see everyone get everything they want from the web.
Personally I am disgusted that this standard is being promoted by the W3C and Tim Berners-Fucking-Lee. The browser vendors are perfectly capable of building (and even standardizing) this tech by themselves.
The open web is as available today as it ever was, and even more so with blockchain and "dark web" technologies like tor and i2p.
Yes, that's the disgusting part. But so it goes. The flesh is weak.
Overlay darknets are indeed the only hope for freedom.
I don't understand these two sentences in conjunction, which is most of why I don't understand all the complaining about this issue. If, as almost everyone admits, the browser vendors are going to ship DRM-enabled playback one way or the other, what difference does it make whether it's in the official spec?
The HTML5 spec is just a piece of paper that exists to make web developers' lives easier. I don't understand the need to assign attributes like "purity" to it, especially when (as you yourself said), whether or not the DRM is in the spec changes nothing on the ground.
I am sad too. Perhaps there was a window of time when we could have gotten rid of NPAPI plugins and not added DRM to implementations and forced media companies to come along. That didn't happen though.
no, having a sanctioned DRM mechanism in an open standard means DRM is being normalized (and by extension, acceptable). The fact that DRM already exists as plugins isn't the point - but making DRM part of the web standard gives free reign for the pro-DRM camp that it's acceptable, or even desirable!
The only acceptable standard is one where the user benefits. I don't see how a user can benefit from DRM, except that this standard makes DRM less difficult to swallow for an end user (who, let's face it, don't give a shit about DRM). The added convenience of standardization means we can never get to a place where DRM-free content is the majority/norm.
About as much as music DRM was the death of music players. And as we all know the only way to play a music file today is to buy them in the Microsoft Zune store and squirt them over to your FairPlaysForSure(tm) certified KindlePod.
It's not a good thing; it lets some very big actors hurt themselves and their paying customers by still pretending that people will eventually come around to paying more for inferior service if only they force feed enough "you wouldn't download a car" ads to their dwindling customer base, and it encumbers the browsers to support yet another legacy standard that will be used only by exploit writers in ten years time.
But in the end this is never going to prevent you or anyone born after the sixties from accessing any significant piece of content. It is only going to stop you from going out of your way to pay for it.
I guess if YouTube started putting DRM on everything, that would reach the level of 'annoying'. Is there any indication they would do that?
There won't be. Unless we actually make things happen to assure against "suddenly DRM", at some point the technology will be there that you cannot trivially bypass.
If Apple and iTunes suddenly crash, they have to make a tiny effort into releasing a conversion/stripping tool and/or open source the system so that ex-customers can at least attempt to help themselves.
EME is pretty great for cracking too - they enable rendering with the browser's own video engine, giving you a nice "hook to dump pre-decoded frame here" point.
https://www.w3.org/TR/2016/CR-encrypted-media-20160705/#medi...
Try to learn how a Google web app works by inspecting the source code sometime.
Terrible, IMO.
Ultimately my screen has to show me the pixels and my speakers have to play the audio.
And you can also buy some expensive hardware to sit between the HDCP decoder chip and the output to the display panel, and buy some more expensive hardware to deal with the huge volume of raw, uncompressed video that comes out of it.
But the content producers are betting that most people won't consider the first option good enough, and will find the second option prohibitively expensive. They're also betting that most people will opt for the convenience of getting it through the browser or mobile device (for a fee) and won't want to deal with getting it from not-so-legit sources. They're comfortable with these tradeoffs, for now, so they're doing what they're doing.
They absolutely don't care about the small minority of people who will do anything to get hold of the content unencumbered. They know they can't control that group of people, but they aren't losing sleep over it. Because, for now, that minority is too small to hurt their bottom line. If that changes, I'm sure they'll pursue a new strategy. But for now, they don't need to.
The effect of DRM is to prevent the user from doing things that would otherwise be technically possible, such as copying. Once the software has decrypted the media, it can do whatever it wants with it. It is just so designed that what it wants to do with it is not the same as whatever the user wants to do with it.
Free or open-source software give the right and the ability to the user to modify what the software does. So if a feature is missing (save a backup copy), the user can add it (or pay someone to).
I piece of software cannot at the same time: * be able to decrypt a video * be able to be changed at the users' will * be prevented from doing certain things the user wants.
If you merely write a piece of open-source software that lacks the ability to save a copy, you merely have a missing feature that can be added by anyone who wants to fork it, you are not preventing copying.
If the decryption is done in hardware, the problem is the same, just shifted. If people have the ability to change the hardware, then we're back to square one, and if they don't, then it's not a free/open-source system.
That doesn't mean that a content producer will verify any old (modified) version of the software and allow it to play (and possibly "leak") their content.
Put another way: it's possible to build a secure DRM pipeline and then release all the source to it while maintaining the security of _that particular version_ of the pipeline. It's perfectly possible (cryptographically) to set it up so an unmodified version of that pipeline will be able to play protected content, while modifying it to (for example) dump decrypted bits to disk will cause the content to fail to play at all.
If it's a part that's open-sourced (hardware or software), then won't it simply be _modified_ to allow it to pass and allow extraction of decrypted content?
If it's _not_ open-source, then you don't have a fully open-source DRM scheme.
> 3. Derived Works
> The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
You seem to be conflating open source with key extraction or decryption ability. You seem to be saying that if a specification is known then that implies an ability to modify the system to a degree that allows those things.
You can have a system whose workings you know precisely, without obscurity, where the SW/HW specifications are open and the only secret is the key material. For instance, you could have keys be embedded in processor fuses. How would a user extract the keys in that scenario?
For DRM systems the user or consumer is the adversary, but the principles of secure system design still apply. You can still place an asset outside of adversary reach. For example, by ensuring that they need a super expensive FIB machine to read keys. Or, more traditionally, by tailoring cryptography to their computational power.
You seem to be conflating the malleability of software with its modifiability in a given system, but in reality those can be controlled. Yes, you can fork the software, but why are you assuming you can replace it on a given system?
Consider a black box with an LED. The box has an internal power supply and the LED emits light pulses in a given pattern pleasing to the user who purchased it. I could give you its physical properties and circuit diagrams. The box has data stored in internal memory. You can call parts of this data software if you like, as long as we agree that the output of the box is a function of this data and time.
The only contradiction inherent in DRM systems is that knowledge of the data/function needs to be given to the adversary and not given to the adversary at the same time. This has less to do with open or closed source, and more to do with whether the user can open the box.
I think that the "solution" to this contradiction has been reduction in fidelity, where the user/adversary is only given an approximation of the function (analog outputs that they have a hard time spreading to other would be users).
DRM sucks, but is not fundamentally at odds with open source.
You actually can create an open source DRM solution, because none of the OSI definition[1] makes reference to user freedom or other issues that DRM violates. As far as the OSI is concerned, DRM is can be released under an OSI license. Of course, you have to consider that according to the Digital Millenium Copyright Act, breaking DRM is _very_ illegal (regardless of whether or not the DRM'd media is still under copyright -- which means that DRM has no expiry).
However, if you subscribe to the free software definition[2], then you run into a problem. DRM in principle violates freedom #0: the freedom to run the program for any purpose. Now, there exist free software licenses that don't protect you against this threat (I believe only the GPLv3 actually addresses this issue), but note that just because a piece of software is under a free software license doesn't make it free software (there are whole classes of programs that might be GPLv3 but are still not considered by the FSF to be truly free -- DRM falls under that example).
[1]: https://opensource.org/osd [2]: https://www.gnu.org/philosophy/free-sw.html
--
Another reason is that I guarantee their EME implementations are going to be full of bugs and making the source available would just make it easier to find them. This is the same AAC conspiracy that gave us the Sony rootkit after all[3] (which then went on to be used by other viruses).
[3]: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...
why does that argument get thrown around so much? flash runs in sandboxed processes too these days.
Obviously it can't be used for DRM, I will just capture the frame and redirect it to a codec to re-encode the stream. Alternately, I can just stream it somewhere else.
On the other hand a secure place to store keys, free from the reach of plugins and javascript would be nice.
Much better than the many posts here trying to force their opinion on the world!
"Oh boy! I'm super excited to be running arbitrary code I downloaded from web sites against an API that was never security-hardened!"
Fortunately for me, my fears turned out to be overblown in that specific instance; there were a few security bugs, but they were patched with relative swiftness.
This reasoning, IMHO, ignores the fact that the user-agent still asks for consent, so the user may choose not to allow anything they can't audit. It's just the "Do you want to allow Flash to play this cool video?" story all over again.
Another comparison to existing tech is Javascript. A lot of sites break if you disable Javascript in your browser, but if you enable it you open yourself to Javascript vulnerabilities.
So, it's similar in the sense that enabling JS increases the potential attack surface, just like installing EME/Flash/whatever does. But at least the JS engine can be examined by whoever wants to.
Also, the comparison to Flash is not quite right. For example, Flash was an entire black-box, top to bottom, with a runtime, codecs, UI, a JS engine, etc., which downloaded code from the internet to run it.
Web DRM, on the other hand, is a standard that allows for an encrypted video stream to be decrypted. The only differences that I can see between this and the current state of web video are that now the stream can be encrypted. Everything else is still using Javascript, HTML, CSS, HTTP, h.264/265, etc.
The thing that gets me is that open-source browsers are free not to implement this extension if they're not comfortable with (or opposed to) it. The theory is that if companies start encrypting their content then open-source browsers will have to follow suit, but we already have that kind of junk; the difference is that now, with EME, we can keep 99% of the stack open standards, open-source, and auditable, rather than having to rely on Flash or Silverlight to do our decoding.
EME isn't the death of the open web, it's the death of the closed web. It's the death of awful, insecure, and obsolete technologies like Flash and Silverlight by taking the one single thing they're still good for and moving it to the browser. If EME failed and no one implemented it, Netflix wouldn't just stream their content unencrypted; they'd keep using Flash or Silverlight, or maybe implement something themselves so they didn't have to.
And, notably, the DRM modules can be sandboxed far more than Flash can.
Aaaand we're back to the days of good ol' ActiveX.
I've had email discussions with people at the EFF about this and we basically just had to agree to disagree. Their interpretation of the choice we're making is that we either get DRM in browsers or we get some magical fairy-tale land where DRM suddenly ceases to exist. I don't buy it.
Plus, as a Netflix subscriber I don't really mind DRM that much. Feel free to ask away, I'm always willing to talk about this.