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

Tim Berners-Lee has posted his views on the DRM-in-HTML5 issue at _On
Encrypted Video and the Open Web_ [1].  Along with the discussion of
this topic at the recent TAG F2F [2], I found a comment on Tim's post
by Josh Triplett [3] particularly helpful.  Here's a summary of how
this might actually be a TAG issue, that is, why it is at least in
part architectural.

*Background*

1) Providing a robust (read: acceptable to W3C members who are pushing
   this) Digital Rights Management (DRM) capability in HTML5 comes in
   two parts:

   1a) Encrypted Media Extensions (EME) [4]: extensions to the <audio>
       and <video> tags and special-purpose APIs associated with them
       to hand access-control for the media they identify to a

   1b) Content Decryption Modules (CDM):
        "a part of or add-on to the user agent that provides
         functionality for one or more Key Systems." [5]

        "A Key System is a generic term for a decryption mechanism
         and/or content protection provider." [6]

2) The current EME draft says (in the *Abstract*):

   "Implementation of Digital Rights Management is not required for
    compliance with this specification: only the simple clear key
    system is required to be implemented as a common baseline."

   I think we can safely stipulate that the simple clear key system
   will not be judged robust enough to satisfy some important content
   providers.

3) As only obliquely implied by the introductory diagram in that draft
   [7], completely license-protected web-to-screen pathways require
   CDM-integration with the platform software _and_ hardware.  I
   commend Peter Gutmann's _A Cost Analysis of Windows Vista Content
   Protection_ [8], an analysis of the impact of this requirement on
   Microsoft Vista and contemporary hardware (chipsets and displays),
   to those interested in understanding this point and its practical
   (and architectural) significance in detail.

4) It seems very unlikely that content providers intending to make use
   of strong DRM protection for their content will provide opensource
   implementations of their CDMs.

*Arguments for and against EME in HTML5*

A) The Open Web argument

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".

This parallel does beg the question as to whether the difference
between the freely-available Adobe and Apple plugins for use with the
<object> tag, and the presumably restricted-to-customers CDM plugins
which will be necessary for use with EME changes the overall picture
in important ways.  Until this question is confronted and addressed,
I'm not sure the above justification for EME in HTML5 holds up.

B) The "All your platform are belong to us" argument

But (3) is much more significant, in my view.  It is perfectly
possible to install proprietary software, including e.g. graphics card
drivers, under many if not most Linux distributions.  Whether _all_
the necessary software components of a proprietary, acceptably robust,
CDM could be integrated into Linux is a much harder question.  We
already have the situation where consumers discover that they cannot
watch DVDs they have purchased on their home computers, because the
display on their system does not implement the necessary _hardware_
DRM support [9].

Not only does putting EME in HTML5 enable the same difficulty to arise
for video and audio content on the Web, but it also extends the scope
for similar much more extensive failures:  Can we really let EME out
of CR on the basis of implementations of clear-key CDM only?  If it
turns out that _in principle_ no robust CDM can be implemented for
integration with browsers running on Linux, have we really
demonstrated interop?

Saying "Well, you don't have to watch online videos from Such-and-So
if you don't want to pay for their CDM" is one thing.  Saying "Oh,
sorry, you _can't_ watch online videos from Such-and-So even though
you're willing to pay for them, because you're running Linux" seems
rather different.

*Conclusions*

After a long period of being unclear where, if anywhere, there were
_technical_ and/or _architectural_ aspects to this debate, I'm now
convinced that there are.  It seems to me the burden of proof lies
with the advocates of EME inclusion, to show that 

 * wrt argument (A), that the commercial dimension of the EME story is
   irrelevant;

 * wrt argument (B), that including EME in HTML5 will not lead to
   (non-expert-sysadmin-level) Linux users being confined to a
   CDM-free ghetto where they _cannot_ (legally) access DRM-protected
   content.

I don't think the TAG has the expertise at the moment to address these
points directly, but it may be that we are better placed within the
W3C than anyone else to make sure that they _get_ addressed.

ht

[1] http://www.w3.org/blog/2013/10/on-encrypted-video-and-the-open-web/
[2] http://www.w3.org/2001/tag/2013/10/01-minutes.html#item01
[3] http://www.w3.org/blog/2013/10/on-encrypted-video-and-the-open-web/#comment-59685
[4] http://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html
[5] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#cdm
[6] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#key-system
[7] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#introduction
[8] http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html
[9] See quotes in [8] or e.g. https://discussions.apple.com/thread/1766997?tstart=0
-- 
       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 Tuesday, 22 October 2013 17:41:58 UTC