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

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

Fred Andrews <fredandw@live.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|EME depends on servers with |EME supports content that
                   |a finite life.              |depends on servers with a
                   |                            |finite life.

--- Comment #13 from Fred Andrews <fredandw@live.com> ---
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #8)
> > I agree that some CDM instances need not depend on license servers for
> > viewing. 
> 
> Ok, so we can close this bug then. Or at least you need to change the
> subject.

It is the proponents who are conflating the non-DRM case with DRM case
and making this review so difficult.  If you split out the non-DRM
case from the DRM case, then it might well be possible to close some
of these issues against the non-DRM case, but these issues may
still stand against the DRM case.

The subject has been trivially modified to be more specific.

This bug could clearly only be closed if *no* CDMs required
the licensing server to be live for viewing content.

>  However the EME interface is designed to support this, and it
> > is clear that this is the expected use case.
> > 
> 
> Sure.

So you agree that this bug is not resolved.

> > You appear to be acknowledging this bug is a real issue, but that
> > you would not want it fixed because it is inherent in your business
> > model terms.
> 
> I agree that EME can support services that depend on license servers. I
> don't agree that is an 'issue'.
> 
> > 
> > I presume it is inherent in your technical model that the CDM
> > dictates if the output can be stored irrespective of the UA or EME?
> 
> In our systems today, the equivalent of the CDM outputs the media directly
> to the rendering devices. I believe it's part of our terms and conditions
> that the users does not modify these devices to record the content.

So 

> > It may help people understand the scope of EME if such constraints
> > were articulated in the EME specification. For example: 'Many use
> > cases require that the CDM have privileged control over the
> > storage of the CDM output, in particular usage terms that do
> > not allow the storage of video output for replay at a future
> > time.'  This would then relate to bug 20961 as many platforms
> > would not support this requirement.
> 
> Obviously, at some point the media exits the CDM in some form and
> *technically* the only control the CDM has over what happens to it then is
> what the receiver of the media offers to the CDM, up to the point that the
> CDM trusts that part of the system to do what it says.
> 
> There are scenarios in which there are no *technical* protections on the
> media after it exits the CDM. The protections are in the terms of service
> the user has agreed to and the fact that it is technically difficult to do
> other things with the media at that point. Thus EME does not *require*
> technical protections on the media after it exits the CDM.

Well then lets specify that the CDM does run in a sandbox.  Further
in the interests of catering for a wide range of business cases,
lets extend EME to support the capture of the CDM output - some
business terms may want to sell such extra-high value licenses to
users.   Oops now there is not DRM, and we can forget about EME.

You need to clarify the scope of the CDM and the architecture you
propose so that it can be reviewed.  I do not believe any progress
can be made resolving these bugs without such clarification.

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

Received on Friday, 22 February 2013 22:29:49 UTC