Unrestricted publishing in EME? Re: DRM, EDE, CDM, W3C and the TAG:

On 2013-10 -23, at 07:14, L. David Baron wrote:

> On Wednesday 2013-10-23 13:37 +0300, Henri Sivonen wrote:
>> On Tue, Oct 22, 2013 at 8:41 PM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>>> 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.
>> 
>> It's not the content providers' CDMs. The EME CDMs shipped so far are
>> proprietary to Microsoft and Google--not to Netflix or the studios.
>> (It's unclear if you used "content providers" to refer to sites that
>> provide content to users or to the copyright holders of provide
>> content to the sites.)
> 
> Additionally (to Henry's point), I think it's worth noting that not
> only does it seem unlikely that there will be open-source CDMs, but
> it also seems unlikely that there will be pluggable/plugin CDMs.  In
> other words, it seems unlikely that CDMs will be available as
> libraries that can be dropped in to any browser (like NPAPI
> plugins), but instead seems like CDMs will be built-in to browsers
> as a proprietary component of those browsers.

Suppose though we could impose constraints on DRM systems
which were attached. One of the many criticisms of current DRM systems
is that they are controlled by a single bottleneck vendor,
in some cases the hardware vendor.
The system protects the content of those who distribute
through the channel, but the channel is a single one,
and so not everyone can play.  Some assume that any
EME system must be like that -- but does it have to be?

Can we imagine or design a EME system which instead
as usable by anyone as a publisher? Suppose anyone could set up
an web serve and serve encrypted content to end users without
going through a bottleneck vendor.

(Clearly, you might think, this won't work as for a system to be so highly 
used by both consumers and receivers it would be cracked instantly.
But actually DRM is cracked anyway -- you can play anything over an HDMI cable
and crack the HDMI cable.[1]  So we are not talking about an uncrackable system
anyway. Just one where people will be more inclined to pay for the stream
and less inclined to record it.)

Can you imagine a system in which there is some protected code
but it is is sandboxed so the open source operating system can talk to it?
In fact, such a system has to be directly the screen anyway.
Maybe the EME system should just be the screen.
Can you in fact just build an open source system which negotiates
directly between a HTMI device and the server? 
Maybe this doesn't work -- I am not an expert on this.

Can we while we are at it build a DRM system which is sandboxed so it can't
call home, or is prevented from reading any data bout me from my system? 
One of the things I am worried about is that once we allow a EME vendor
to install their own unreadable code, then that code could report on my media-watching activity, not to mention scrape up other private data and send it back, as many phone apps do now.

Or can we make a DRM which doesn't have any hardware-protected code,
which is open to being abused, and we rely on the fact that 
most people don't change their computers much -- under that set of assumption -- 
which can be used by anyone who wants to stream a video?

Yes, you can argue that if DRM is bad then more [providers using] DRM is worse
but on the other hand one of the bad things people associate with DRM is the closed market.
Can we break that connection?

Tim


[1] http://adamsblog.aperturelabs.com/2013/02/hdcp-is-dead-long-live-hdcp-peek-into.html

timbl

(no director hat on)


> 
> -David
> 
> -- 
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>             Before I built a wall I'd ask to know
>             What I was walling in or walling out,
>             And to whom I was like to give offense.
>               - Robert Frost, Mending Wall (1914)

Received on Sunday, 27 October 2013 18:27:21 UTC