Thanks for the precise and comprehensive reply, Henri. Nick
On Mon, May 19, 2014 at 9:03 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > 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 _______________________________________________ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
