- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 14 Apr 2017 10:20:34 -0700
- To: www-tag <www-tag@w3.org>
- Message-ID: <CAEnTvdC_ejsdx33bfFeNCeeRLEx72wQEh3fs-_S2h44dN+TxtA@mail.gmail.com>
Dear TAG, I responded to Hadley's post last night and subsequently read the TAG's minutes on this issue. Respectfully, I do think your response misses a key point. EME not only gives browser implementors "a seat at the table" (as Alex pointed out) with respect to DRM but they make the *choice* *of* and have *responsibility* *for* the DRM implementation and/or its use*. Content providers no longer get to choose. This is a major shift in both technical and business architecture. Browser implementors have strong incentives to respect user security and privacy and obviously if the *user's agent* does not respect those things, we have much bigger problems. I've been working on this shift of responsibility to browsers for six years. It's the single most important thing in EME. W3C and browser implementor involvement has been a strong force for strengthening the security and privacy aspects of the specification and W3C's continued involvement would be a force against regression. So, its disappointing that this is not recognized in your comments, which read as if CDMs are just plugins-by-another-name over which browsers have no control. Also, several if not all browser implementors have been *exemplars of good practice* with respect encouraging, celebrating and rewarding independent security research and this is another reason to be optimistic that this shift in responsibility will pay dividends. There is no evidence that these implementors are carving out exceptions to their security approaches for the DRM component. The EFF's covenant did not get much support because it would entail a long and costly legal negotiation (cf patent policy) and reached much further than security research. I'd note that if one really wants to solve a problem in standards, it rarely works to come back with the same previously rejected proposal a year later (not saying the TAG did this, but others have). I think there could easily be a lighter-weight solution, but none of the people raising this problem have made any suggestions, so we have the guidelines as the only thing on the table. ...Mark * just to add, even if the DRM implementation is a platform capability, the browser implementor chooses whether it is safe to use it - and which to use if there are many - just as they do with any other platform capability.
Received on Friday, 14 April 2017 17:21:10 UTC