[Bug 20964] EME supports content that depends on servers with a finite life.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20964

--- Comment #23 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #17)
> > > (In reply to comment #16)
> > > ...
> > > > My view is that this is not a bug, but a feature. And so we should close
> > > > this bug. As Joe points out it's also true of the web platform as a whole.
> > > 
> > > Joe has been challenged to prove this claim and has not done so. You
> > > are welcome to addess this challenge?  Please demonstrate how the
> > > web platform can currently prevent the user storing content received
> > > and presenting it in the future when the server from which the content
> > > was received is no longer accessible?
> > 
> > You have a rather narrow definition of 'content'.
> 
> We are talking about video here, so it seems quite appropriate to
> note a difference related to video content.
>  
> > A user who plays a Facebook game whilst browsing facebook.com, for example,
> > likely considers the game part of the 'content' of the page. That user would
> > be totally unsurprised at the idea that the game is only available for as
> > long as Facebook servers are available. The mooted ability to make a
> > recording of the gameplay for later enjoyment might be rather underwhealming.
> > 
> > The point is that the creator of a game or anything else on the web decides
> > the functional split between client and server. Only services with no
> > real-time server component - and there are plenty of games and other things
> > like this - remain available to the user when the servers are no longer
> > available.
> 
> I agree, but we are talking about video here, and I think many users
> would be quite happy to have a stored video to play back in future.

Not if it's going to cost them a lot more, they won't!

Many users are very happy with rental and subscriptions services which are much
cheaper than 'owning' content - precisely because users are not offered the
opportunity to store the video. I think they would be pretty upset at the idea
of technologists dictating to them that they can't have this cheaper service
just because the device they own is technically capable of storage.

The way we decide which services should be available and which should not -
especially for something as discretionary as video entertainment - is by
inventing technology to support the widest range of services and letting these
compete for users. 

>  
> > Some video services also do not require a real-time server component, but
> > others - including that of my employer, Netflix - do. Again, users of a
> > service like Netflix would be totally unsurprised at the idea that if their
> > subscription or Netflix itself expires, they can no longer enjoy the
> > content. You seem to be assuming that because a service is related to video
> > it's reasonably to expect the company offering that service to conform to
> > your preferred technical architecture - with no real-time server component.
> > It's not. We choose a different design for well-founded business reasons and
> > in alignment with common-sense user expectations. The ability to do so with
> > EME is therefore a feature and this bug should be close.
> 
> My understanding is that Netflix does not delivery protected content over
> the open web architecture, but rather requires DRM plugins, or separate
> DRM applications?  Thus there is a real difference between the current
> open web architecture and the architecture that Netflix demands in the
> EME, and this should be noted so that the working group and the wider
> community can take this into account in deciding if they want to advance
> EME.

Henri described quite well what's proposed, which is a change in architecture,
but not a fundamental one. Moving from plugins to CDMs has pros and cons, yes,
and I completely agree that these should be well understood.

> 
> Further a SCDM is technically incapable of delivering the restrictions
> that the Netflix service demands.  We need to clarify definitions etc
> and re-spin.

By SCDM do you mean 'Software' CDM ? If so, this statement is untrue. We have
several different software solutions in the market today.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 26 February 2013 00:40:09 UTC