[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 #24 from Fred Andrews <fredandw@live.com> ---
(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.

> 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.

> > > 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?

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

> > 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.

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

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

Received on Tuesday, 26 February 2013 01:18:11 UTC