- From: Glenn Adams <glenn@skynav.com>
- Date: Sun, 3 Feb 2013 07:23:09 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, www-archive <www-archive@w3.org>
- Message-ID: <CACQ=j+fJ+qRc7RD_W3W8Q-Y7znNZrWoK+d1-bSVgpGHzZRrNXQ@mail.gmail.com>
On Sat, Feb 2, 2013 at 8:40 PM, Sam Ruby <rubys@intertwingly.net> wrote: > On 02/02/2013 08:39 PM, Glenn Adams wrote: > >> The point being made on public-html is that the current private >> assurances seem to be at variance with the long time observable public >> behavior. >> > > Note: I am by no means saying that such objections are blocking. What I > am saying is that such objections have been expressed, and we need to > provide a substantive response to these objections. > Just one last point, which is that such objections are not objections to EME per se, but to the entire domain of content encryption as it has been fielded in the past. I'm not sure any adequate, substantive response is possible, since the same objection could be made to any proposal to support content encryption. For example, an alternative proposal might be to reframe EME as an extension to TLS that would allow a pluggable key and encryption method in TLS as well as a JS API that interacts with TLS that serves the same functions as being proposed with EME. The only really new aspect of this would be the JS API, since TLS already supports arbitrary encryption and key types (as chosen during the initial handshake). It seems to me one could potentially make the same objections to this reframed proposal as are currently being made for EME, yes? Which, if so, shows that the objection is not specifically related to EME as such. At bottom, the objection seems to be with the past business practices of content providers (driven by content owner licensing restrictions). The W3C doesn't seem to have any control over such practice, and it seems unusual to propose restricting W3C technical solutions due to past business practices in another solution domain. Even if such business practices continued, would that be a legitimate reason to block EME, which can certainly serve uses that don't follow such past practices? I think this is all I can add to this thread, so let me make this my last reply, unless you wish me to answer something specific. Regards, Glenn
Received on Sunday, 3 February 2013 14:23:58 UTC