[governance] Digital restrictions management in HTML standards

[Norbert Bollow]

Catherine Roy <ecrire at catherine-roy.net> wrote:

> I would add that the EME proposal also represents problems for
> certain users with disabilities.

In my view, this is not an argument against the EME proposal as a
whole, but just against the aspect of it that allows CDM to bypass the
browser when Frames have been decrypted.

> As pointed out by Pratik Patel (who is himself blind and an expert on
> technology accessibility issues) in the comments section of Manu's
> excellent post on the EME spec :
>
> "The current state of proprietary implementations by players such as 
> Netflix makes it quite difficult for disabled people to access
> content via the web. The plugins, no matter how they’re designed,
> make for a poor user experience. If there is to be any benefit
> derived by this effort, it must be that browser implementations
> provide a consistently accessible and usable interface.

The EME spec could support this by specifying that the decrypted Frames
must always be passed back to the browser. That would allow browsers to
provide a consistent interface for assistive devices. It would also
allow specialized accessibility-oriented software to play the role of
the browser in relation to CDM.

> I have been a member of the HTML Working Group for the last 6 or 7
> years now and I doubt the W3C will be swayed by moral or social
> arguments. I believe W3C wants [needs?] to offer something regarding
> DRM for audio and video content to some of its big name members (who
> are supporting this proposal) if they are ever to adopt HTML5 use for
> broadcasting audio and video content.

I agree with your assessment of W3C; however I also see this as
something that needs to be challenged. It is fundamentally
anti-democratic when a key Internet governance institution is
organized as a consortium so that a small number of industry members
can --in total disregard of negative social consequences for
the rest of the world-- essentially unilaterally decide that a web
standard of a certain type will be created. 

> But I also believe W3C would be more than happy to entertain any
> proposal that would be technically superior to the EME specification.

Such a proposal would still have all the negative side effects that are
essentially unavoidable in any DRM system that is designed for making
circumvention as difficult as possible.

In my opinion, at the very least it should be strongly insisted, within
W3C processes, that the decrypted content must be returned to the
browser (as opposed to the CDM accessing low-level operating system
facilities directly).

This would make the proposal much better (in the sense of significantly
less objectionable) from the social perspective -- not only in regard
to assistive technologies, but it would also significantly reduce the
resulting risks for FOSS. But this change would make the EME spec
technically inferior from the perspective of DRM proponents.

It would be much better still to completely get rid of the CDM and
provide "simple clear key decryption" only. Technically that is
relatively easily breakable of course, but it is enough of a "technical
protection measure" to have some legal protection in many jurisdictions.
I'm rather pessimistic though in regard to the chance of convincing W3C
to get rid of the CDM.

> So basically, the best way to defeat this spec is to propose
> something better that will rally a majority of working group members.
> I do not believe it is possible to evacuate DRM support from HTML5
> (and yes, regardless of what the spec says in intro, it *will*
> facilitate DRM, not to mention make it part of the core language of
> the Web, and unfortunately, in a rather inelegant and inefficient
> way) but it may be possible to propose something that will not lock
> out open source or assistive technologies.

Do you have any concrete ideas towards that? (There are reasons why the
proponents of DRM have not yet managed to solve this problem. It is a
hard problem, and in fact I'll be very surprised if it isn't truly
impossible.)


McTim <dogwallah at gmail.com> wrote:

> On Tue, May 14, 2013 at 3:14 PM, Norbert Bollow <nb at bollow.ch> wrote:
> > - the actual draft specification
> > http://www.w3.org/TR/encrypted-media/
> 
> The draft is all you need.  For all those who have been griping about
> the DRM aspects of it, they should probably read it first:
> 
> "This specification does not define a content protection or Digital
> Rights Management system. Rather, it defines a common API that may be
> used to discover, select and interact with such systems as well as
> with simpler content encryption systems. 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."
>
> > - criticism from those who oppose DRM as a matter of principle:
> >   https://www.defectivebydesign.org/sign-on-against-drm-in-html
> 
> but this is not DRM.

Different people use the term "DRM system" with different degrees of
broadness. (This is not unlike how the term "Internet governance" is
also used with different broadness by different people.)

DRM critics typically use the term in a broader sense than the authors
of this draft. In that broader sense, typical uses of the "simple clear
key system" are also a case of DRM. In particular, the "simple clear
key system" is designed to fall under the legal category of "technical
protection measures" which exists in various jurisdictions.

Independently of that, the main objective of the draft spec is to
enable DRM in the narrower sense in which the authors of the draft use
the term.

So the discourse on whether or not there should be a W3C spec that
intends to enable DRM (in the way that that is intended by this spec)
needs to focus on this spec. (What else should the discourse focus on?)

Greetings,
Norbert


** acronyms
EME=Encrypted Media Extensions
CDM=Content Decryption Module
DRM=Digital Rights Management / Digital Restrictions Management
FOSS=Free and Open Source Software
W3C=World Wide Web Consortium

-- 
Recommendations for effective and constructive participation in IGC:
1. Respond to the content of assertions and arguments, not to the person
2. Be conservative in what you send, be liberal in what you accept

-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t