[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 #25 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #22)
> ...
> > > 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.
> 
> This is just not relevant to the matter at hand.  The technical fact is
> that the open web platform does not prevent the user storing the received
> video.  It is not the case that the users has to choose between a
> less restricted versus a more restricted UA implementation in return
> to more favorable terms on web services.  This may be the case with
> proprietary plugins or proprietary DRM-CDMs, but neither are currently
> part of the open web.

EME and CDMs are proposed to have the same role with respect to web standards
as <object> and plugins respectively already have.

My point is relevant, because the web as it exists today does - on some
platforms - support services where it is made difficult for users to store the
received video. This is an advantage because it enables business models which
otherwise would not be achievable on the web.

You seem to be mis-understanding the proposal as being one to standardize a
specific CDM. We're no more proposing this than to standardize a specific
plugin.

I agree that if that were the proposal, then a lot more detail would be needed
to evaluate it, but that's not the proposal.

You're welcome to make the argument that <object> and video codecs and other
extensibility points were a terrible mistake that should not be repeated -
others have also made this argument - but there does not seem to be consensus
on this. In fact our proposal should be seen as a step on the path to removing
<object> by providing a more constrained alternative to one of the main
use-cases for <object>.

> 
> > 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. 
> 
> The open web allows users to implement their own browser.  There is no
> distinction between the 'technology' and the 'user', the technology serves
> the user.
> 
> You are conflating Netflix terms of use, or copyright restrictions, with
> the open web standard.

No, I think you are trying to assert a definition of the web that excludes
certain popular use-cases. As I said, the web today supports <object>, so what
is new ?

>   
> > > > 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.
> 
> Henri has add a lot to discussions, and if there is something in particular
> that you support then please bring this forward for review?

http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0079.html

> 
> Proprietary plugins are not part of the open web standard, so any change
> to bring their functionality within is very significant.

Specific proprietary plugins themselves of course are not. But <object> is very
much part of HTML as is the concept of a plugin: 

http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#plugin

Following the same model as this - as we propose - is not a big architectural
departure.

> 
> > > 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.
> 
> Please see bug 21104 for the definition of SCDM, and no this does not
> mean 'software CDM' which would be too broad to be meaningful.

Ok. I tend to agree with the comments in that bug that the SCDM term is not
terribly useful.

Regarding your statement on the 'restrictions that the Netflix service
demands', unsurprisingly, these vary from case to case and over time, so I
couldn't sign up to any statement of the kind you make above.

> 
> I repeat my suggestion to try and reach consensus on some definitions
> otherwise we are just talking past each other.

Aside from the proposals in 21104 - which did not attract much support - what
terms do you propose we need to define ?

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

Received on Tuesday, 26 February 2013 03:11:02 UTC