- From: Duncan Bayne <dhgbayne@fastmail.fm>
- Date: Thu, 13 Jun 2013 16:14:51 -0700
- To: public-restrictedmedia@w3.org
> The media in question is already restricted to those people. EME doesn't > do > that. If anything, EME will increase the set of people able to access the > media. Think about it: those people are the potential customer base for > services like ours, why would we want to reduce the size of that set ? You tell me. Currently, Netflix doesn't support Linux. > By contrast, CDMs will be much smaller in scope and therefore easier to > port. Both the vendors and the customers of CDMs have an incentive to > support as many platforms as possible in order to maximize their revenue > and potential customer base respectively. So, essentially your argument is that the design choices behind EME might lead to wider platform support by CDM vendors, which would lead to an improvement in platform support by DRM systems. Forgive my cynicism, but I've not noticed any DRM vendors (my own company included!) putting any effort into minority / FOSS operating systems so far. > Why do you think CDMs will have any language-specific functionality at > all ? I expect there'll be the usual installation / error reporting strings, etc. It's the protected content that worries me more in this regard. > That's a restriction applied by the server, not by a client component. > Using DRM to "enforce" geo-restrictions implies to me that you are > somehow making use of the robustness of the client component to more accurately > identity the location and then either report this securely to the server > or apply the restrictions at the client based on allowed locations returned > in the license. I don't see how you would do that. I'm not sure why you see the distinction between client and server enforcement as significant? My position is that the issue is with the W3Cs endorsement of DRM - that is, the full stack from server to CDM. If the server refuses a key because of the IP address of the client, that's functionally equivalent to the client refusing to decrypt based on IP. > Compared to plugins today, since CDMs are integrated with browsers, we > can > expect the browser implementors to pay attention to their security and > privacy properties. For example, if the CDM vendor refuses to explain to > the browser implementor exactly what the CDM does, the browser > implementor > may choose to throw a scary dialog before the CDM is invoked, warning the > user that they are about to executed unknown, untrusted code and giving > them a choice not to (or more likely, the browser would choose not to > ship > that CDM at all). Given the history of DRM providers - including the Sony Rootkit fiasco - why should browser vendors be at all inclined to believe assertions about functionality without having access to the source of the CDM? > Likewise, if the CDM will communicate some kind of identifying > information > to the server, the user may be warned of this (and given the choice to > disable the CDM). Such a CDM would not operate when in "anonymous" > browsing > mode. Assuming that everyone plays nicely together, and never lies about what the CDMs do. Given the history surrounding this technology, are you really willing to bet that this is never the case? > Hmm, I feel caught in some circular logic. Weren't the goals you quoted > the > goals of the W3C ? What do you consider the "goal of an open web" that > would be sacrificed ? Yes, those were W3C goals. What is being proposed is to have the W3C accept a closed-source, proprietary DRM system as a recommendation, and as I've explained, I think that solution is inimical to most of those W3C goals. Perhaps this is the fundamental difference between our positions? As far as I can tell, you see EME as an improvement upon existing DRM systems (and it is, no doubt about that), and therefore that it should be adopted by the W3C. Whereas I see DRM as fundamentally incompatible with W3C goals, so regardless of whether EME is an improvement on Silverlight and its ilk, the W3C should refuse to endorse it. -- Duncan Bayne ph: +61 420817082 | web: http://duncan-bayne.github.com/ | skype: duncan_bayne I usually check my mail every 24 - 48 hours. If there's something urgent going on, please send me an SMS or call me at the above number.
Received on Thursday, 13 June 2013 23:15:13 UTC