[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 #26 from Fred Andrews <fredandw@live.com> ---
(In reply to comment #25)
> (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.

No, I am not under that misconception.  It is clear that the CDM is
so poorly defined that it could be almost anything.

You seem to want the CDM defined so vaguely that the security and privacy
implications, among other matters, can not be reviewed.

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

A lot more detail is needed anyway.

For example does the 'clear key' CDM run in the context of the UA or
is it a 'protected' DRM OS module.  If it runs in the UA context then
the output can be saved, so it is not DRM.  If it runs in a proprietary
UA on an open source stack then the output can still be recorded at
the OS level and it is not DRM.  If it needs proprietary OS support
and is a proprietary CDM then how is it going to be implemented as
required by all web browsers.   EME is hopelessly undefined - we do
not know what we are talking about.

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

I dispute this analogy of yours, it is not mine.  The reality is that EME
has strong content protection as a use case, and the design and implications
need to be addressed.  I also suggest that the only possible solutions will
be proprietary CDMs on proprietary stacks.

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

How are you going to implement your Netflix use-cases on open source
stacks?

I am just suggesting the obvious: that it is not possible to implement
the Netflix use cases on open source stacks, and trying to refocus
on the obvious path of using proprietary CDMs on proprietary stacks,
and to get this documented so that the implications can be explored.

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

Thank you for the link.  I concur with Henri's comments, but note he
mentions a 'smaller non-user-modifiable black box whose licensing
characteristics are unknown with a narrower yet-to-be-defined API
that integrates into <video>'  which is more specific than the EME
specification!  He is talking about the DRM use case, yet EME does
not even qualify its scope to DRM.  Henri says more in a few sentences
than the whole EME specification does.

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

Agreed, if you compare proprietary plugins to proprietary CDMs, but this
is not the comparison being made.

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

Then would you agree to limiting EME to the DRM use cases?

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

So you reserve all privileges for the CDM making it impossible to
defined any 'sandbox' restrictions on the CDM.

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

We seem to be talking past each other a lot so more would probably help.
Bug 21104 seems to be a core one and we may need it resolved first.

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

Received on Tuesday, 26 February 2013 04:18:37 UTC