Re: Encrypted Media proposal

On Sat, Mar 3, 2012 at 9:27 AM, Mark Watson <watsonm@netflix.com> wrote:
> Ian, we have well over 20 million customers streaming something like an hour a day each on average, so of course you will find evidence of technical problems related to this as to any other aspect of the service. I could find the fraction of playback failures related to DRM - I expect it is very small.
>
> What I mean is that, aside from such issues, we don't see that the use of DRM impacts customers ability to get what they expect from the service. It's not cited as a common reason for cancellations and our market research doesn't flag it as an inhibitor to take-up of the service.
>
> Of course there are a technically minded minority who would like to get more from the service than we promise, or who want to remove the DRM 'because it's there'.

I agree that, for a lot of customers, DRM on a streaming service is
not nearly as troublesome as DRM on files they own.  The files are
transient and not expected to be "owned" by the user.  Further, for
"on-demand" streaming services such as Netflix, the ability to
time-shift is moot, as it's an inherent quality of such a service.
Finally, the overall experience of a good streaming service is
generally much better than attempting to track down files and download
them yourself.

This is not without trouble, though.  A user of a minority browser
without Flash ported to it would be unable to use Netflix.  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.  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.

None of the caveats apply to services that want to sell DRM-encumbered
movies to customers.  In this scenario, DRM is inconvenient for the
customer in every aspect; it is almost a strict improvement in the
customer experience to rely on someone sharing a file instead.


>>> It's often argued that all customers want is easy, convenient,
>>> reasonably-priced and legal access to content and they become frustrated
>>> with industries that refuse to offer them that. But that is exactly what
>>> we are offering and what we want to make possible with HTML5.
>>
>> It is often argued indeed. But it's not at all what you are offering. It's
>> not what your proposal enables -- HTML video can _already_ be used to
>> provide content easily, conveniently, at a reasonable price and legally.
>
> Some content, yes, but not the vast majority of content on our service, because it doesn't support features required in the licenses for that.
>
> You're arguing that W3C should take a biased position and say 'change your license terms or we won't let you on the web'. Again, that would be a policy, not a technical issue, even assuming that W3C is empowered to be such a gatekeeper.

The W3C takes *precisely* that position all the time.  We demand, with
very few (no?) exceptions, that all W3C members in a WG with relevant
patents license the technology in the specs we produce royalty-free.
If a company has contracts that prevent them from doing so, either
they change their contract or *we don't use that technology*.

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.

~TJ

Received on Sunday, 4 March 2012 16:11:40 UTC