Re: Encrypted Media proposal

On Sun, Mar 4, 2012 at 11:02 AM, Mark Watson <watsonm@netflix.com> wrote:
> On Mar 4, 2012, at 8:11 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>  A customer
>> with an internet-capable TV but no game console or other box that
>> Netflix has explicitly been ported to wouldn't be able to use it
>> either.
>
> I believe Netflix is supported on most Internet-capable TVs. We'd obviously like it to be all. Hence the proposal.

I'll note once again that it's not the technology that's holding you
back, its your contracts with the movie distributors.  The technology
that Netflix needs has been available for some time, and is in active
and growing use.

One of the active questions here is why we should be adding
troublesome-in-multiple-ways tech to the web platform solely to help
you honor the contractual obligations you voluntarily agreed to, when
from a technical perspective you're completely covered.

(I'm aware that the movie studios more or less act like stubborn
leeches in these kinds of contracts, so you have my sympathy.  But
sympathy doesn't extend far in a technical debate.)


>>  For streaming services that aren't on-demand, like some
>> television streams, DRM prevents them from time-shifting to a time
>> they wish to watch.
>
> And so those services should be less attractive to consumers than services that do support time-shifting.

The point is that DRM prevents me from using a *secondary* service to
do time-shifting on my own, if my primary source either doesn't offer
it or does a bad job.  The fact that you're locked in to using the
original media distributor for *everything* is a disservice to
customers who should have more competition.


>> It's quite normal and relevant for the W3C to demand that the open web
>> stay open.  Many browser vendors in the discussion so far believe that
>> adopting this proposal would do exactly the opposite.  Since it's
>> attempting to solve a problem that will disappear in a few years
>> anyway, it's appropriate for the group to push back on this.
>>
>> Finally, policy issues are completely appropriate for this forum.
>> We're not a hivemind of problem-solvers, solely focused on solving the
>> tasks placed in front of us.  We're a community of people interested
>> in developing the web, who have come together for the purpose of
>> making it easier to interoperate.  We decide *not* to solve certain
>> problems all the time; in fact, that's the *majority* outcome for
>> problems brought to the group.  If we gave up our prerogative to judge
>> problems and decide whether or not to solve them, the output of this
>> group would be markedly worse.
>
> Yes, but it's the basis of those decisions that differs. Most are based on whether there is a sufficient body of interest in solving the problem and sufficient real-world experience to expect that it can be solved in a way that will stand the test of time. This is a very practical basis for decision-making. The character of the arguments in this case are completely different. With all due respect to the members of this group, our expertise is primarily in engineering - at least this is what we all have in common - and the concerns that have been raised are not at all engineering issues.

This is incorrect - several engineering issues have been raised by
Henri Sivonen, Boris Zbarsky, and others, such as the fact that the
tech for current in-use CDMs is closed-source and almost certainly
will continue to be.  This means that browsers can't fix security bugs
they find in the CDMs (and a long track record of interacting with
plugin creators shows that vital security bugs are both common and
given distressingly little attention).  Because it's DRM, they also
can't even legally reverse-engineer the CDM to port it to platforms
the CDM producer chose not to care about.

Alongside the pure engineering concerns, there have been multiple
concerns raised about the effect this has on the platform, such as the
fact that current CDMs generally require licensing, which excludes
niche browsers and OSes.  As well, a proliferation of incompatible
CDMs being used to encode/decode different content is bad for the
platform in the same way that a proliferation of video codecs is - it
means that simplest path of just picking one and using it probably
excludes a significant fraction of users.

Alongside both of those, we must worry about our own users and their
rights.  This is quite normal and common.  For example, there's
nothing wrong, technically, with assigning every user a unique ID and
making this accessible to ads, and in fact this would be tremendously
useful for ad providers.  Our users appreciate us protecting their
privacy as much as possible, though, so we refuse to implement
functionality of this nature.  Similarly, DRM negatively impacts our
users in multiple ways, restricting the ways they can use their
computer and their media.  It is our right and duty to weigh this in
our appraisal.

And finally, alongside all of those concerns, we get to the value
judgements.  Many of us feel that DRM, particularly in its common
current incarnations, is morally wrong to inflict on people.  Contrary
to your statements, value judgements are *completely* appropriate for
a technical discussion.  We are people, and we have to live with the
consequences of our actions, including the technology we develop and
distribute to our users.  Attempting to argue that we should lay our
personal feelings aside and solve your problems regardless of our
opinions of them isn't going to go very far.


Note that I'm not trying to convince *you*, Mark.  Your company is
currently tied down in contracts with the media distributors that
require things I find immoral.  You've gotta do what you gotta do.  My
goal is to help ensure that the other stakeholders who aren't directly
financially benefitting from inconveniencing their users and damaging
the long-term health of the platform get good, complete information
about all the drawbacks of your proposal, so that hopefully they
decide along with me to reject it.

~TJ

Received on Monday, 5 March 2012 00:42:25 UTC