To lighten the mood:
|
|
But actually, I’m serious.
People are rightly concerned about what is going on in the W3C with DRM, as couched in the Encrypted Media Extensions (EME) proposal. Please read Henri Sivonen’s explanation of EME if you haven’t yet.
As usual for us here at Mozilla, we want to start by addressing what is best for individual users and therefore what’s best for the Open Web, which in turn depends in large part on many interoperating browsers, and also on open source implementations with a significant combination by number and market share among those browsers.
We see DRM in general as profoundly hostile to all three of: users, open source software, and browser vendors who aren’t also DRM vendors.
Currently, users can play content that is subject to DRM restrictions using Firefox if they install NPAPI plugins, really Flash and Silverlight at this point. While we are not in favor of DRM, we do hear from many users who want to watch streaming movies to which they rent access rather than “buy to own”. The conspicuous example is Netflix, which currently uses Silverlight, but plans to use EME in HTML5.
(UPDATE: Netflix is using EME already in IE11 on Windows 8.1 without Silverlight. And Chrome OS has deployed EME as well. Apple too, in Mavericks.)
What the W3C is entertaining, due to Netflix, Google, and Microsoft’s efforts, is the EME API, which introduces new and non-standard plugins that are neither Silverlight nor Flash, called Content Decryption Modules (CDM for short), into HTML5. We see serious problems with this approach. One is that the W3C apparently will not specify the CDM, so each browser may end up having its own system.
We are working to get Mozilla and all our users on the right side of this proposed API. We are not just going to say that users cannot have access to streaming Hollywood movies, as that is a good way to lose market share and not have any product with which to uphold our mission.
Mozilla’s mission requires us to build products that users love — Firefox, Firefox for Android, Firefox OS, and Firefox Marketplace are four examples — with enough total share to influence developers, and therefore standards. Given the forces at play, we have to consider EME carefully, not reject it outright or embrace it in full.
Again, we have never categorically rejected plugins, including those with their own DRM subsystems.
However, the W3C willfully underspecifying DRM in HTML5 is quite a different matter from browsers having to support several legacy plugins. Here is a narrow bridge on which to stand and fight — and perhaps fall, but (like Gandalf) live again and prevail in the longer run. If we lose this battle, there will be others where the world needs Mozilla.
By now it should be clear why we view DRM as bad for users, open source, and alternative browser vendors:
- Users: DRM is technically a contradiction, which leads directly to legal restraints against fair use and other user interests (e.g., accessibility).
- Open source: Projects such as mozilla.org cannot implement a robust and Hollywood-compliant CDM black box inside the EME API container using open source software.
- Alternative browser vendors: CDMs are analogous to ActiveX components from the bad old days: different for each OS and possibly even available only to the OS’s default browser.
I continue to collaborate with others, including some in Hollywood, on watermarking, not DRM. More on that in a future post.
/be
I think you highlight the right point: people will want to watch movies from Netflix or stream music from Spotify on their computers… if their browsers do not support it, then, they will swicth away.
So that means 2 things:
– either all browser vendors agree to NOT implement that.
– either all browser vendors will implement it.
In some way, I think W3C is blackmailing browser vendors and that’s very sad to me.
Julien: W3C is just taking money from new members freely, including DRM vendors, anti-DNT lobbyists, etc. That’s bad, but if you want to blame a powerhouse, W3C isn’t it. Hollywood, Google, Microsoft, Netflix. The last three could be other powers, the primary issue is w/ H’wood.
/be
I don’t see anything in Mozilla’s mission or in the Mozilla Manifesto that requires Mozilla to “build products that users love”. I do see that Mozilla’s mission “is to promote openness, innovation & opportunity on the Web”.
I’ve heard a fair number of arguments *against* DRM in HTML and EME, but I’ve not heard the arguments *for* it.
What is the problem they are attempting to solve that can’t be solved by simply properly securing the resource? Is it that DRM-proponents want the protected media to only be playable in the client that requested it? If so, how does that benefit anyone (particularly DRM proponents)?
It seems like most DRM is easily beaten by simply recording playback from a source.
I understand the need to protect intellectual property, I’m just curious how DRM was arrived at as “the” answer.
Brendan, good post and good analysis. I think W3C pretty much aligns with your thoughts about the situation.
I wanted to clear up a couple of points.
W3C is not willfully underspecifying DRM in HTML5. To date, the EME specification is a draft proposal within the HTML Working Group and W3C has not taken any position on the spec per se. All W3C has done to date is agree to consider “content protection” in scope. We have not agreed to any specification, so it is hard to say that we have “willfully underspecified”.
You might feel that the current draft is underspecified. We are pleased that Mozilla is participating in the Working Group and raising issues. The issues properly should be addressed in the WG. If at some point the Working Group chooses to move forward with issues against it; with a spec which “is underspecified”, the W3C Director will carefully address any objections that are raised when it is brought forward. As was the case in the H.264 discussions, Mozilla’s insights are valued.
You talk about DRM in HTML5 – but to be clear – noone is discussing putting DRM into HTML5. It is very important to me that a “pure FOSS browser” can be built which is fully compliant with HTML5, CSS, etc. and has the ability to browse the entire web of “not-restricted content” with full interoperability. So EME is proposed to be a separate specification – not part of HTML5.
Jeff Jaffe
W3C, CEO
youtube has updated it’s html5 detector now to show support for MSE and vp9: https://www.youtube.com/html5
If they really want to to have DRM couldn’t/shouldn’t they build them in JavaScript on top of the (hopefully upcoming) CryptoAPI + XHR + Media Source Extension ? At least if would be interoperable and we would be rid of the EME plugin crap.
@Mike: a mission to do X with the Web, without hundreds of millions of users loving the products upholding that mission, is toothless. We had to build Firefox to restart standardization and (via) competition, remember? When you read “promote”, think more than cheerleading. We have been doing a lot more, and effectively, for over nine years.
@Ben: please follow the link to Hixie’s G+ post that I provided in the first bullet point near the end of this post. Here it is again:
https://plus.google.com/app/basic/stream/z13qtnxhuojytbjbr04ci3cowrmtehsy324
DRM is about gaining leverage over “playback devices” and ultimately “users” in order to jack prices a bit higher, a bit longer — but not so long as to tip things to darknets too much. You’re right that all “robust” DRM schemes are cracked, rapidly. It’s clearly not about preventing copying.
@Gabriel: see “robust and Hollywood-compliant” link. A purely JS implementation would (as far as we can tell) not be robust by any of the C&R rules followed by DRM vendors and set up by some combination of DRM vendor over-engineering and Hollywood overreach.
/be
@Jeff: People know what’s up. EME is going forward without any CDM spec, in full view of W3C staff and relevant editors and chairs. But please do surprise me by holding it up until there’s a CDM spec. This won’t help the EME implementations in the field (IE11 on Windows 8.1, Chrome OS — see my UPDATE: in the main post).
> You might feel that the current draft is underspecified.
I don’t “feel” this, Mark Watson, one of the EME editors, wrote that EME does not specify CDMs and is therefore underspecified, explicitly, here:
https://lists.w3.org/Archives/Public/public-restrictedmedia/2013Oct/0156.html
Find “A valid criticism is that EME doesn’t specify the whole system.” I link to this in my blog post.
> We are pleased that Mozilla is participating in the Working Group and raising issues. The issues properly should be addressed in the WG.
You seem to think the W3C exists to provide members (including paying members, which creates a conflict of interest) with whatever they want. I think the W3C exists first to be a good steward of web standards, which matters most when paying members go against the founding open web principles.
We may disagree on this, which will put us at odds. Won’t be the first time the W3C went wrong (https://brendaneich.com/2004/06/the-non-world-non-wide-non-web/).
> You talk about DRM in HTML5 – but to be clear – noone is discussing putting DRM into HTML5.
Tell it to Netflix: from
https://techblog.netflix.com/2013/04/html5-video-at-netflix.html
I quote:
“HTML5 Video at Netflix
By Anthony Park and Mark Watson
Today, we’re excited to talk about proposed extensions to HTML5 video that enable playback of premium video content on the web.
…
We’d like to share some progress we’ve made towards our goal of moving to HTML5 video.”
You know perfectly well that EME is an extension to HTML5, that most evolution of the web platform will be done via such extension specs, and that “HTML5” is used (including by W3C staff) as an umbrella term.
So it goes with Netflix. I don’t think you can wash your hands of putting DRM in HTML5 with standards-title hair-splitting.
Thanks for the comment, but please refrain from writing about how I or anyone at Mozilla might “feel” about EME being underspecified, when the EME editor is on the record about that objective problem. The bug filed by Robert O’Callahan,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
linked from my blog at “Here is a narrow bridge”, is still languishing.
/be
As a proponent of development with web technologies, I want a web developer to be able to do anything a native developer can do. The less we have to lean on plugins and “stuff outside the browser” the better. So instead of focusing on the open/closed part I’m looking at the capable/incapable part.
Right now, the meager video playback we get from standard HTML5 video is not nearly enough, so people are still depending on heavy Flash and Sliverlight plugins. Something like EME should let web devs do more of their work on the web side, but yes leaving an ugly stub of non-weblike “stuff outside the browser” to do whatever things are proprietary.
With plugins we’ve always had the problem that something like Flash/Silverlight isn’t supported on all platforms equally. The crazy thing is that we’ve gotten to the point now where video playback is just about the ONLY task anyone does with either of these technologies. If they have to stay proprietary it makes sense to simplify to an “EME plugin” so the size and attack surface is minimized.
EME is not any worse and arguably better from a practical perspective than the Flash/Silverlight status quo, right? What are the practical alternatives, who is advocating them, what constituency do they have, and what are the odds they will succeed vs EME?
@Jeff
It seems disingenuous to take the position that all standardization activity within the W3C up until the moment that a specification becomes a CR, PR, or perhaps a formal recommendation itself, is essentially a neutral and flexible activity, having no impact on the outside world until the process is complete. With HTML5 scheduled to reach the PR stage sometime in Q4 of next year, clearly the very development of W3C standards spurs implementations and decisions with potentially great consequences for the web long before the W3C takes any kind of official “position” on a proposal. This is the case with EME too, where private implementations of EME, unavailable to any other web developer who even wanted to use them, are already in production use by two vendors for Netflix.
The ongoing process seems to be that EME should be completely finalized to the satisfaction of its proponents, a formal objection will inevitably be made, and the Director will make a decision. This process is willfully blind to the reality that the standard, under the name and endorsement of the W3C, will be the standard by that point regardless of that decision. This process is all the more flawed by the fact that the EME spec has, from the very beginning, adopted, pretty much without specifying, certain core and immutable requirements about content protection (that just happen to correspond with the existing business requirements of a small number of members), and any part of the standardization process is helpless to challenge those requirements. The result has been ordained from the beginning, and most of the work since then has just been filling in the details.
The issues Mozilla and others have raised with EME are not specific technical nits; they are fundamental to the very nature of the activity and should have been discussed and resolved well before anybody started discussing details of an API within a WG.
It’s all well and good to say that the W3C “has not taken any position” on the spec, but at some point passive non-interference with the efforts of several of your members, under the auspices of your processes and name, must be construed as approval. We are well past that point now with EME.
@Dave Methvin: Please see the thread at
https://groups.google.com/forum/#!topic/mozilla.dev.planning/4-svns_uEjA
especially the posts from Henri Sivonen. EME is definitely worse than the NPAPI status quo, because NPAPI is a de-facto standard (we even have a plugin-futures@mozilla.org list run since 2004 to curate it among the WHATWG founders and top plugin vendors) with many plugins using it to interoperate among all browsers.
In contrast, the CDM black box combined with “robustness” requirements means that by default, and in all likelihood without side deals among browser vendors, there won’t be any cross-browser CDM plugins.
That’s a net loss compared to Silverlight on two OSes – which BTW works very well for me compared to Flash, which works on two and a half (counting chromium on Linux with Flapper extracted from Chrome).
Your point about wanting to erase the “native vs. JS” gap is close to my heart, but please read Hixie’s G+ post on DRM:
https://plus.google.com/app/basic/stream/z13qtnxhuojytbjbr04ci3cowrmtehsy324
DRM is not about — cannot be about — open source code-culture hacking to close this gap. It is about technically onerous and yet still ineffective means, which beget hideous legal means as “patches”, to gain leverage over playback devices, ultimately over prices for a time.
If we could make an open source EME implementation, CDM included, that Hollywood blessed, we would. But we can’t (not robust). Now what?
/be
“A purely JS implementation would (as far as we can tell) not be robust by any of the C&R rules followed by DRM vendors and set up by some combination of DRM vendor over-engineering and Hollywood overreach”
Then, it sounds like it’s impossible to have interoperability and be hollywood compliant. A VM/Sandbox of some sort has to abstract away the specifics of the operating system and hardware for the DRM otherwise there’ll just be platform dependent blobs.
Also, Robert O’Callahan’s proposal sounds very weak; it just makes EME plugins more like regular system dependent NPAPI plugins. And even that’s being weakened by concessions further into the bug comments.
@Jeffrey: yes, even roc’s very mild call for a CDM doc-link registry is too much to ask for, apparently.
/be
IMHO The EME standard is useless. If a browser shows it on a screen a user can record it. But to be honest I’m not an engineer or did I read the specs.
In that extend the DRM and the whole issue of intellectual property is a social problem that is reaching a climax (in different areas and not only on the web).
In the area of music, the publishers have found that the open nature of the web provides more opportunities than trying to close it down. For film makers … they still need to discover the crowed funding networks and get rid of the big money addicted business.
I would like to see Mozilla implement this crap by adding distributed DRM cracking to Firefox. I would happily share some of my bandwidth and processing power to this end.
Jeff Jaffe, I didn’t even decide on which side to sit in this discussion, but your comment sounds terribly political in the bad kind of way. You seem to hide your real thoughts behind seemingly all-embracing-all-correct speech. While in fact it seems pretty obvious that by your inaction you are satisfying demands of one side and one side only.
Jeff Jaffe has previously presented the publication of the EME First Public Working Draft as a decision by the HTMLWG:
“The HTML Working Group has announced their decision to release a First Public Working Draft of the Encrypted Media Extension (EME) specification”
https://www.w3.org/blog/2013/05/perspectives-on-encrypted-medi/
I think the HTMLWG should have a formal vote on how to proceed with EME work, in public:
# [01:46] steve: are chairs saying
# [01:47] … there will be a FPWD
# [01:47] rubys: still deciding
# [01:47] steve: and that decision will not be a CfC?
# [01:47] rubys: my input is it probably will not be
# [01:47] paulc: it won’t be public
– HTMLWG F2F, April 2013 https://krijnhoetmer.nl/irc-logs/html-wg/20130424#l-748
“…as I understand it, the decisions of whether the group should publish EME or whether the group should address the requirements that led to EME are still matters left to decisions of the working group.” – L. David Baron
https://lists.w3.org/Archives/Public/public-html-admin/2013Sep/0136.html
My last email to the EME list before unsubscribing, Subject line of this very long thread was “Trust”
…Quoted text removed…
Hold on. That’s what they said about the printing press. Books. The radio. Audio tape. Video tape. Television. Cable TV. It’s all evil.
Now we have the internet and people must be punished, taxed and be held accountable for the use of this medium, as they were for all the media that came before. It is not our responsibility to evolve our business models for changing technology, it is our responsibility to make sure that no technological change change the way we fill our pockets.
They must run programs on their computers that they have no control over so that we have control over them. They cannot be trusted, we can. The W3C must provide an interface for us to fleece the masses or we will have hissy fits like we have with every other technological change.
If the W3C wishes to throw its good name away then we will just have to replace it. They had a good run. If the internet gets parcelled up and sold off to corporate interests, we can replace that too.
I’m unsubscribing from this list. It’s become spam.
Cheers!
@brendan: if I may make a suggestion, I would recommend to reword that part of your posting: “…is the EME API, which introduces new plugins…”
As you have already pointed out in the comment to Dave, EME is even worse that NPAPI plugins because CDMs might not be plugins that can be sharedly used among browsers.
I find that this misunderstanding is prevalent among commenters in favor or EME, i.e. they don’t see that CDMs will very likely be browser specific, forcing app creators and service providers to license either all CDM technologies or go back to the dreaded “Only viewable in $BROWSER”
The real problem here is that Google and Microsoft are steamrolling ahead with this regardless of what the W3C or anyone else thinks. Heck, Google and Adobe have already effectively decided that the NPAPI can go to hell, and Flash is only receiving updates for it in Windows because of “contractual obligations”. Flash on Linux is barely being paid lip-service anymore, and Google’s Pepper is the hot new jam. Google’s even going to remove the NPAPI from Chrome within the next year, and with their clout that will basically mean that the NPAPI will die (an at-best slow) death.
Basically, the ones we have to worry about aren’t the W3C. They’re just the public-facing yes-men who are taking the brunt of the ire. Google are the ones we should be angry at, for taking browser technology other people developed, getting people hooked on it, and now using it to try to dictate how the web operates at every step of the way: Pepper, NaCl, EME, SPDY, WebP, and the now basically useless WebM (since they reneged on their promise to stop supporting H.264).
I sincerely wonder why the rest of the web is focusing on the W3C and giving Google an essentially free pass on this one. It’s painfully clear that they’re the ones to blame here, taking the side of monied interests and slowly dropped the charade of developing open standards and only implementing improved technologies.
You can see this clearly in any Bugzilla thread where people try to paint Firefox as “holding the web back” because they’re not implementing some shiny new feature that Google has casually included in Chrome, no matter how unproven it is. Just look at the two WebP threads, and try to maintain your composure. We let this happen, and now we’re focusing on some idiots who were paid to take the brunt of our anger, instead of the ones who deserve that anger.
@Kevin: good point, I added *non-standard* before plugins.
@Hogart: don’t let noise in bugs get you down. Josh Aas et al. did a study of image formats, WebP is not clearly winning enough for us to include yet. Maybe we missed a metric, or a test methodology, and we’ll change our minds, but we are going to do some science, not go with the pressure from not-so-disinterested parties.
You’re right: Google has power and money. With great power comes great responsibility. Hold them to account, in every way you can: as a consumer, developer, and (Web or other, older kind of) citizen.
/be
Fully agree, non-publicized standards cannot and should not be standards.
DRM, and especially proprietary DRM is a non-sense on the web.
CDMs will never support Firefox anyway, the fact that Widevine is disabled if you turn on debug mode in a ChromeBook says they don’t trust users at all.
As an indie developer responsible for an online app that distributes copyrighted content, I completely fail to see how this “advance” will make the web better for me, my app, or my users.
It seems to me that this feature will make my app appear toxic to users.
Unlike Flash and Silverlight, anyone using the EME API will *only* be using it for user-hostile activities like DRM and user-tracking, which means that my users will block it and potentially red-flag my site, losing me users. Any community-oriented browser would mark its use with a skull-and-crossbones in the titlebar, the label “DRM” in the status bar, or some other obvious indicator.
Unlike Flash and Silverlight, free-to-use cross-platform solutions may not be available, so I may have to pay licensing costs for the privilege of cross-platform compatibility.
Unlike Flash and Silverlight, which work in the overwhelming proportion of browsers, the EME API has low uptake, no support in older browsers, and may even be completely denied in some browsers.
These three elements together mean that in order to make my app viewable by everyone who can currently view it, I must fail back gracefully to another system. Which means a significant increase in the amount of work I have to do as a developer.
Given how bad it will make an app look to use this DRM system, it seems like the DRM version should be the fallback when the existing systems don’t work, rather than being the default.
So, I will incur heavy costs in order to be compatible with the small proportion of potential users who use browsers that don’t support existing DRM technologies. How are these extra costs any kind of improvement for me or my users? How has this improved the web?
I’d hate to see DRM implemented in Firefox. It would just mean more bugs, exploit points, more crashes, and less time spent on more important things. Besides it’s not like an add-on wouldn’t arrive to disable it anyway. I trust neither Google nor Chrome and that’s why I still use Firefox.
I think Mozilla should conduct a poll of Firefox users and assess whether or not they want DRM compatibility (pointless but go ahead). It does seem like a slippery slope because now that I think about it, add-ons which disabled it would be illegal and… Mozilla might be held liable for ever removing it in the future.
It wasn’t nice to know some staff members from W3C (Vanessa Tonini and Yasodara) supported by Vagner Diniz (w3c br general director) called ‘communists’ all those who supports the web without DRM and that we (web users) are bullying them (w3c) by petitioning against the DRM on the web.
They did that at W3C Brazil Conference on a conference talk about the web platform and this is supposed to be considered a official stance, right?
I started a noise on my twitter: https://twitter.com/leobalter/status/402868009980542976