On Wed, May 14, 2014 at 9:10 PM, Rubén Martín <nukea...@mozilla-hispano.org> wrote: > * It's not the first time we take decisions because everyone else is > doing it, and we want to keep being relevant. > o This worries me the most looking at the future, since we are > going to be always the only ones with completely different > values to the rest of the players in the browser ecosystem. > o Have we lost hope to be enough relevant to avoid these situations?
Chrome being available and doing H.264 on one hand and EME-style DRM on the other sure makes the overall situation different from what the situation was like at the time of IE6 and Firefox 1.0. > * We want to get rid of plugins but we implement something that always > depends on an external and proprietary module. Making Adobe Access available to Firefox without the Flash platform in between is not inconsistent with a desire to address problems with NPAPI plug-ins. > o It won't be impossible to access the full web using open source > bits, since if we also agree on this, even people not using DRM > right now are going to switch to it eventually. We simply can't know for sure how the market dynamics play out. However, as noted in my earlier message, EME doesn't make DRM free of cost to streaming services or fully cross-browser-compatible. Jonas Sicking wrote: > And remember, just like with the video codec issue, just because we > lost in this instance doesn't mean that we've given up. Moreover, the EME situation might have gone differently if the H.264 situation had gone differently. The H.264 situation showed that when stuff works in <video> in Chrome, IE and Safari and works in <object>/<embed> in Firefox, we can't turn the tide by keeping it not working in <video> in Firefox. Jim wrote: > Mozilla has made no formal objection to the EME at the W3C. We didn't do so, because the likely outcomes were: 1) No change in what the W3C was doing. Effecting no change would not have been a meaningful win. It might have scored us some positive political points in some quarters. It might have also made it harder to ensure that Firefox users will be able to continue to view the content that they currently can and that users of other browsers are and will be able to view. 2) EME getting kicked out of the HTML WG into a new DRM WG. This would have been worse than having it in the HTML WG, because once you've created a working group whose purpose is to work in DRM, the group might seek to sustain its existence even after the deliverable it was created to deliver has been delivered. In other words, this outcome would have made more probable that the W3C would work on other DRM-related things after EME was done. 3) EME getting kicked out of the W3C and getting picked up by another standardization forum. This would have been worse than having it at the W3C, because another forum would probably have been more IPTV-oriented and less Web-oriented. The Microsoft PlayReady-informed key acquisition architecture that EME embodies is a better fit for the Web than the alternative key acquisition architecture that is popular among the IPTV constituency. (See http://lists.w3.org/Archives/Public/public-html-media/2013May/0016.html on an elaboration on the Webbiness merits of the EME architecture.) The pressure to enable Firefox to integrate with EME-style DRM doesn't come from EME being on the Recommendation track at the W3C. It comes from the combination of 1) Users want to see Hollywood movies. 2) Major studios require movie streaming services to use DRM. 3) Our existing DRM solution, NPAPI, not being sustainable with e.g. Silverlight getting end-of-lifed. 4) Chrome, IE and Safari taking the path of enabling EME-style DRM. > You didn't even try to make a case to users to stick with Firefox if they > were forced to use an alternative browser to view some media content. Some users might use another browser for DRM and still come back to Firefox for other needs. However, I think the notion that Mozilla's position should be "use another browser" is fundamentally naive. It doesn't result in users not having DRM on their computers. It doesn't result in Mozilla getting to sandbox the DRM. It doesn't result in users not engaging with services that use DRM. It doesn't address what Firefox OS users should do. (Though, granted, we haven't announced anything for Firefox OS, either.) It would likely result in people (not everyone but many) to consider it easier to only use the other browser. > Selling out on users control over their own computer is not the right > decision. How are we selling *that* out when we 1) Are going to give the user the option to decline Adobe Access DRM (at the cost of not being able to use some services) 2) Are going to sandbox the DRM component 3) Are not currently sandboxing Flash Player or Silverlight? ? >> The decision today is an improvement over the NPAPI-based DRM >> solutions that currently exist. > > Wrong, just ask Henri. EME-style DRM is technically an improvement over NPAPI-based DRM, in my opinion. If EME had been here first, no one would argue that Firefox's Adobe Access integration would improve by adding the Flash platform in between and removing the Mozilla-controlled sandbox. The market dynamics of EME CDMs are different from the market dynamics of NPAPI plug-ins, which has the potential of making the impact EME-style DRM worse than NPAPI DRM for Mozilla. We can't know what ends up happening exactly. However, due to having systematically worked to erode the business case for non-DRM uses of NPAPI, we don't really get to choose to e.g. reverse the end-of-life decision Microsoft made with Silverlight and stick to NPAPI as the solution. Boris Zbarsky wrote: >> Even when W3C employees started joking about assassinating EME dissenters > > I was not aware that this had happened. That's clearly not acceptable in a > professional setting. I believe this is a reference to http://lists.w3.org/Archives/Public/public-html-admin/2014Feb/0062.html , which I agree was inappropriate. The Wanderer wrote: > For my part, I wasn't aware that this had been implemented by anyone > yet, nor that it was yet anything more than a proposal for a standard > that had not yet been finalized (and which was seeing opposition from > some parties, and might not be finalized at all). I suspect that other > people might be in the same position, and this might help explain the > lack of previous outcry. Netflix first announced their EME deployment in the context of Chrome OS: http://techblog.netflix.com/2013/04/html5-video-at-netflix.html Google's part is in the bowels of Google+: https://plus.google.com/100132233764003563318/posts/6QW8TLtV6q3 Microsoft and Netflix have co-marketed Microsoft's implementation: http://www2.netflix.com/ie11testdrive linked from http://ie.microsoft.com/testdrive/ (Yes, it's deployed in production, too.) That Google and Microsoft have been doing this isn't exactly a secret. Their names are even on the EME spec! Apple has stayed quiet, though. You have to go look in the WebKit codebase and the WebKit Bugzilla to see what's happening. I agree that the difference in the level of outcry is likely mainly due to EME being a better fit for the expectations that people have of Microsoft, Google and Apple than the expectations that people have of Mozilla. Trevor Saunders wrote: > So, I actually feel more or less the oposite way about h264 mostly > because it meets the DFSG requirements, demonstrated by Debian shipping > it in the main part of there archive not the non free one. FWIW, I view Debian putting H.264 in main and the FSF listing ffmpeg in the Free Software Directory (https://directory.fsf.org/wiki/Ffmpeg) while explicitly excluding Firefox because Firefox suggests non-Free software despite being itself Free (https://directory.fsf.org/wiki/Firefox redicerts to https://directory.fsf.org/wiki/GNU_IceCat) are the most blatant examples of even the core of the Free Software movement not standing with us on the H.264 issue. (As noted above, I think we might have reacted to EME differently had things gone differently for our opposition to H.264.) Also, FSF's PlayOgg campaign is supposed to be against certain formats but the campaign promotes VLC *which plays those formats*! Pretty serious collateral enablement in my view. Jim wrote: > Henri seems rather hard to understand, but he seems to have promoted the EME > in the end. I think I've never promoted EME over publishing without DRM. I do consider the EME architecture superior to the most likely alternative architecture for integrating DRM with <video>, though. (See the link earlier in this email.) I also think that relying on NPAPI for compatibility with services that require DRM is not sustainable. > Only Henri spoke out. I think others spoke less at the W3C mainly to avoid contradicting what I said when others had spent less time to study the details of the issue. That is, I don't think others should be considered to be at fault for having spoken less. > Part of the reason for not objecting was that TBL might do even worse, but > not standing up to him is just spineless. I have called TimBL on his bad arguments, in public: http://lists.w3.org/Archives/Public/www-tag/2013Oct/0058.html . Jeff Jaffe, too: http://www.w3.org/blog/2013/05/perspectives-on-encrypted-medi/#comment-13387 . A Formal Objection is something different, though. See earlier in this email about that. > Firefox could recognize media needing DRM decoding and launch a separate > media player. That wouldn't mean that users would be running a system free of DRM. What's the win? Also, such a system would not solve the problems that the proponents of EME are seeking to solve. For example, a streaming service couldn't write its own adaptive streaming logic in JavaScript and couldn't write its own branded player controls in JavaScript. A solution that doesn't satisfy those opposed to DRM (your proposal still involves DRM!) and wouldn't satisfy the proponents of EME is no solution at all. On Fri, May 16, 2014 at 12:26 AM, Chris Peterson <cpeter...@mozilla.com> wrote: > If the CDM can run while completely sandboxed from network and file access, > then it could be implemented in asm.js so the CDM.js would be portable > across all browser platforms and architectures. :) > > I realize that obfuscation of closed-source code is probably easier with > binary blobs than textual asm.js code, but maybe not much. That sounds like > an interesting area of research. I'd like to emphasize "research" as opposed to "viable solution for movies in the near term". This (non-exhaustive) list reasons why that wouldn't work should be enough to explain why: * A Hollywood-approvable CDM needs to be resistant against decompilers. asm.js does not have arbitrary jumps. To achieve proper performance, emscripten uses decompilation techniques to rediscover natural loops. You'd have to find a way to make asm.js code unnatural and still performant. * You need to be able to solve node locking. An asm.js program has less of an opportunity to examine the sandbox it is in than the Adobe Access CDM will have to convince itself this is in the genuine Mozilla-provided sandbox. (The Adobe CDM will Tivoize the Mozilla-provided sandbox from the inside. I'm not aware of how to do that convincingly with asm.js.) * The CDM needs to include an H.264 decoder. If the CDM is a JS program provided by the site, shipping an H.264 decoder becomes the site's problem. It's more convenient for streaming services to let Someone Else to be the one who deals with shipping an H.264 decoder to end users. If someone wants to pursue this, I suggest pursuing streaming music subscription with Opus or Vorbis instead of trying to tackle H.264 movies as the first item. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
