Re: Is EME usable regardless of the software/hardware I use ?

Sent from my iPhone

On Jun 13, 2013, at 4:15 PM, Duncan Bayne <dhgbayne@fastmail.fm> wrote:

>> The media in question is already restricted to those people. EME doesn't
>> do
>> that. If anything, EME will increase the set of people able to access the
>> media. Think about it: those people are the potential customer base for
>> services like ours, why would we want to reduce the size of that set ?
>
> You tell me.  Currently, Netflix doesn't support Linux.

That's primarily a commercial decision. But obviously we require there
to be a DRM solution to support any given platform. Where a
Linux-based platform supports a DRM solution it's possible for us to
support our service, for example ChromeOS.

>
>> By contrast, CDMs will be much smaller in scope and therefore easier to
>> port. Both the vendors and the customers of CDMs have an incentive to
>> support as many platforms as possible in order to maximize their revenue
>> and potential customer base respectively.
>
> So, essentially your argument is that the design choices behind EME
> might lead to wider platform support by CDM vendors, which would lead to
> an improvement in platform support by DRM systems.
>
> Forgive my cynicism, but I've not noticed any DRM vendors (my own
> company included!) putting any effort into minority / FOSS operating
> systems so far.
>
>> Why do you think CDMs will have any language-specific functionality at
>> all ?
>
> I expect there'll be the usual installation / error reporting strings,
> etc. It's the protected content that worries me more in this regard.

If the CDM is part of the browser, then that's all a question of
browser internationalization.

>
>> That's a restriction applied by the server, not by a client component.
>> Using DRM to "enforce" geo-restrictions implies to me that you are
>> somehow making use of the robustness of the client component to more accurately
>> identity the location and then either report this securely to the server
>> or apply the restrictions at the client based on allowed locations returned
>> in the license. I don't see how you would do that.
>
> I'm not sure why you see the distinction between client and server
> enforcement as significant?  My position is that the issue is with the
> W3Cs endorsement of DRM - that is, the full stack from server to CDM.
> If the server refuses a key because of the IP address of the client,
> that's functionally equivalent to the client refusing to decrypt based
> on IP.

But it has nothing to do with DRM. Servers can and do refuse service
based on IP geo lookups today.

>
>> Compared to plugins today, since CDMs are integrated with browsers, we
>> can
>> expect the browser implementors to pay attention to their security and
>> privacy properties. For example, if the CDM vendor refuses to explain to
>> the browser implementor exactly what the CDM does, the browser
>> implementor
>> may choose to throw a scary dialog before the CDM is invoked, warning the
>> user that they are about to executed unknown, untrusted code and giving
>> them a choice not to (or more likely, the browser would choose not to
>> ship
>> that CDM at all).
>
> Given the history of DRM providers - including the Sony Rootkit fiasco -
> why should browser vendors be at all inclined to believe assertions
> about functionality without having access to the source of the CDM?

AFAIK, licensees of DRM systems are provided with source code.

>
>> Likewise, if the CDM will communicate some kind of identifying
>> information
>> to the server, the user may be warned of this (and given the choice to
>> disable the CDM). Such a CDM would not operate when in "anonymous"
>> browsing
>> mode.
>
> Assuming that everyone plays nicely together, and never lies about what
> the CDMs do.  Given the history surrounding this technology, are you
> really willing to bet that this is never the case?

Actually, I would be willing to bet on that, although how much is more
limited by my own resources than my confidence.

If I was a browser vendor, I would probably be quite skeptical about
integrating a CDM for which I could not see the source. And on the
other side, the deserved negative fallout from the rootkit scandal
should serve as a deterrent.

EME is a way to move toward a system where the CDMs do just what they
need to and no more, and where this is known, users are informed and
have choices.

>
>> Hmm, I feel caught in some circular logic. Weren't the goals you quoted
>> the
>> goals of the W3C ? What do you consider the "goal of an open web" that
>> would be sacrificed ?
>
> Yes, those were W3C goals.  What is being proposed is to have the W3C
> accept a closed-source, proprietary DRM system as a recommendation,

No, that is absolutely not what is proposed. There is no proposal for
the W3C to recommend a DRM system - closed source or otherwise.

I wish we could get away from this mis-representation of the proposal.
What is proposed is an API for interaction with one or more
non-W3C-recommended DRM systems.

You might not think that the distinction is important, in which case
you should just say that. But there is a distinction which some people
do think is important and so it causes confusion when you represent
these two different things as the same.

> and
> as I've explained, I think that solution is inimical to most of those
> W3C goals.
>
> Perhaps this is the fundamental difference between our positions?  As
> far as I can tell, you see EME as an improvement upon existing DRM
> systems (and it is, no doubt about that)

I'm glad we agree on that.

> , and therefore that it should
> be adopted by the W3C.  Whereas I see DRM as fundamentally incompatible
> with W3C goals, so regardless of whether EME is an improvement on
> Silverlight and its ilk, the W3C should refuse to endorse it.

Ok, that's clear. That is argument (2) from my earlier list: it's a
matter of principle and so it should be rejected whether or not it is
an improvement for users.

...Mark
>
> --
> Duncan Bayne
> ph: +61 420817082 | web: http://duncan-bayne.github.com/ | skype:
> duncan_bayne
>
> I usually check my mail every 24 - 48 hours.  If there's something
> urgent going on, please send me an SMS or call me at the above number.
>

Received on Friday, 14 June 2013 03:45:25 UTC