Re: DRM, EDE, CDM, W3C and the TAG: Is <object classid="[flash]"...> the relevant precedent?

Philippe Le Hegaret writes:

> thank you (and the TAG) for trying to understand the set of issues
> around EME. One clarification that I'd like to make regarding your
> background information however:
> [[
> Ignoring (3) above for the moment, the prospective situation seems, as
> Triplett [3] points out, to be broadly comparable to what we already
> have with respect to the <object> tag and e.g. Flash or Quicktime:
> videos embedded in <object> tags with the relevant
> Adobe/Macromedia/Apple classids historically could only be played
> using proprietary, non-open-source plugins.
>
> As I understand it, Tim's argument (and that of other W3C staff,
> including CEO Jeff Jaffe) depend essentially on that parallel.  They
> amount to saying "We're just giving you the EME" (|| "we're just
> giving you the object tag"), "if content owners use that functionality
> to deliver (protected) content and users install the necessary CDM (||
> proprietary plugins) to view it, that's a matter between consenting
> adults and part of the Open Web".
> ]]
>
> I do not believe that Tim or Jeff tried to draw a parallel with the
> object tag in their respective blogs.

They didn't make that parallel explicitly, no, but their argument is,
as I read it, essentially that EME in HTML5 merely provides a socket,
as it were, and that what platforms/customers/clients plug into that
socket is not within W3C's scope.  I found the case of the <object>
tag, as pointed out by Triplett, to be a helpful parallel case in
understanding how this kind of division of labour has worked in the
past.

> Certainly there is a desire to reduce the proprietary footprint in
> the Web stack and there is an open question of whether or not EME
> helps enough, but neither Tim nor Jeff have stated support for EME
> itself as a solution so far.
> The only support that has been stated was for having work on content
> protection in scope, as a consequence of the use case for premium
> content. And, by content protection, it was never meant to reduce it
> to a mechanism that would rely on a CDM. The use of "content
> protection" is meant to be general and not force a technical
> approach. Effectively, EME adopts one approach that will make use of
> CDMs but I'd like to reemphasize the fact that EME has not been
> endorsed by Tim or Jeff.

No?  Tim's post is defending "put[ting] content protection for video
in-scope for discussion", i.e. including the EME spec work in the HTML
WG charter, right?  And Jeff's post [1] says "[T]he W3C Director has
established that work on content protection for the Web is in scope
for the HTML Working Group." That sure looks like saying EME is the
W3C's current bet for how to enable content protection.

> I do realize that, since the HTML working group is working on EME,
> many people believe that the W3C Director will endorse EME at the
> end but the option not to endorse is still on the table.

And one of the TAG's jobs is to help the Director with technical and
architectural background analysis, which is what I've tried to
initiate in my post.  The Director very rarely rejects Proposed
Recommendations -- I'm not taking a position on whether he should or
not, be if we wait until PR to do the background analysis, it will be
too late.  I'm suggesting the TAG needs to catalyse a detailed
analysis of the kinds of arguments I outlined, and which the responses
to date have helped correct and extend.

> EME itself contains a list of issues in its status and
> we're still interested in understanding the pros and the cons. The
> discussion within the TAG can certainly help.

I hope so.

ht

[1] http://www.w3.org/blog/2013/05/perspectives-on-encrypted-medi/
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Received on Friday, 25 October 2013 08:58:11 UTC