- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 4 Mar 2013 16:28:25 +0000
- To: Fred Andrews <fredandw@live.com>
- CC: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <C9449DFD-3A54-448D-9E11-A7FE2FBFA156@netflix.com>
On Mar 4, 2013, at 5:07 AM, Fred Andrews wrote: > From: glenn@skynav.com<mailto:glenn@skynav.com> > Date: Sun, 3 Mar 2013 19:24:15 -0700 ... Much of the web community already uses an open platform. This use case is already addressed. The concern is a regression and an analysis of the EME/CDM and use cases is need to assess this matter. Some design changes might be made to mitigate some of the regressions, but in any case the impact of the EME API needs to be well communicated. Can you be more specific on what you mean by "regression" ? Users need to be told that content authors demanding strong copy protect will demand that users computers include an encumbered CDM in the video path to the screen pixels that is not trivially compromised. I'm fine with this statement. But what role do you expect the EME specification to play in such communication to users ? Users of free open source operating systems need to be told that they will need proprietary CDM hardware in the path to the screen pixels to view content that demands strong copy protection. Proprietary CDM hardware is one solution and I'm glad we agree that there exists a solution for users of FOSS operating systems and browsers. I don't think we can claim with certainty that there are no other solutions for such users. You seem to be assuming that any solution in which decoded media is passed to user-modifiable software is equivalent to a solution in which a convenient 'Save As…' option, outputting compressed media files, is provided. Some content authors may indeed consider all such solutions equivalent too, but the decision is a judgement call to be made by the content authors, not a technical issue or something that can be decided by you and I. I don't think we should rule out such possibilities a priori, especially since we frequently hear that users of FOSS operating systems want services like Netflix to be made available on those platforms. Users need to be told that unencumbered CDMs do not technically restrict them from storing the decoded output and that the CDM back channel in this mode is of no utility to the user and amounts to spyware. Obviously, a system which provided no impediment to saving of the media content - for example systems with a convenient Save As … function - has no value. Without an example of an 'unencumbered CDM', though, including information about how it is deployed and integrated with browsers, it's not possible to say that all such solutions fall into this category. Again, as above, the question of utility to content authors is a judgement decision for them to make, not a technical issue we can determine in this forum. The web community needs to have these technical facts communicated to them honestly and clearly. The things above that are facts are not technical facts: the first point on what content authors demand and the second point that hardware CDMs could be a solution for FOSS users. Both involve the judgement of content authors. Nevertheless, noone has tried to hide these things from anybody. I believe to do otherwise is not honest, and I do not respect calls to limit this analysis. It is clear that many here do not support such an analysis and are calling for it to be done elsewhere. Suggesting that something be done elsewhere is not the same as not supporting it. In fact it would be inconsistent to simultaneously oppose something and call for it to be done (anywhere). I think what Glenn and I have been saying is not that analysis should be limited, but that the analysis you propose is flawed and that even if it wasn't there is no technical impact on the EME specification. You can be sure that when the EME spec. is again submitted for CfC FPWD that the impact document will be submitted in parallel and if you are not involved then you will have no input. Of course you are entitled to submit whatever material you like. Glenn and I *have* been providing you with feedback throughout this long thread. …Mark cheers Fred
Received on Monday, 4 March 2013 16:28:58 UTC