- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 28 Feb 2012 08:34:27 -0800
- To: Mark Watson <watsonm@netflix.com>
- Cc: Kornel Lesiński <kornel@geekhood.net>, "<public-html@w3.org>" <public-html@w3.org>
2012/2/27 Mark Watson <watsonm@netflix.com>: > On Feb 27, 2012, at 7:54 PM, Kornel Lesiński wrote: >> On Tue, 28 Feb 2012 01:55:18 -0000, Mark Watson <watsonm@netflix.com> wrote: >>> There are also use cases where the content provider, for whatever reasons, >>> is confident that authorized users will not pass the key or content to >>> unauthorized users and in these cases too the "clearkey" system has value. >> >> Sorry, I don't see logic in this. >> >> If user is trusted not to share the content, how can there be value in >> ineffectively trying to protect content from being shared? > > There are authorized and unauthorized users. The content should not be > shared with the unauthorized ones and this can be done by encrypting it - > both in storage and transport. > > But there could be cases where the authorized users are trusted not to share > the content or the keys. For example, if the video is a family video and the > authorized users are members of my family, I may trust them not to share the > content outside the family just because I ask them not to. Or the authorized > users may all be employees of a company and recognize the importance to the > company of not sharing the content outside the company. > > I'm sure there are other examples. I was just arguing that clearkey has some > utility compared to Henri's proposal to just use https in these cases. But it *doesn't* have utility compared to https in this specific case - if both the server and the user are trusted, you only need to encrypt the connection, and that's what https does. In your other case (server is untrusted), DRM is unnecessary baggage; you only need JS encryption/decryption that can be inserted between the server and a <video> element of the user. This can be specified and implemented without many of the concerns that people have been raising about this proposal. The only case where the additional machinery of DRM has any value is when the user is not trusted. This case, however, has proven to dissolve away in other media industries. While it's not yet completely gone, it's clearly on its way out. I see no reason why video is privileged such that it will always maintain this as an important case, given the history elsewhere. Thus, this is a problem that will solve itself. When the user is trusted, you can use either http (when everyone is trusted), https (when only the server is trusted), or JS encryption (when no one else is trusted). The case where the user is untrusted will disappear on its own, following history in similar media formats, or at least become small enough that traditional measures such as legal contracts will suffice. ~TJ ~TJ
Received on Tuesday, 28 February 2012 16:35:14 UTC