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

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

--- Comment #12 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #10)
> (In reply to comment #8)
> > A 'streaming' service such as ours does not allow the storage of the content
> > for later viewing, even though the platform may be capable of this. It's
> > just not part of the service we offer - the user hasn't paid for that, has
> > agreed in the terms of conditions that they won't do that and we haven't
> > bought the license for that.
> > 
> > There's no technical or political issue here - it's just the business
> > decision we've made and the service we offer. We could spend money on
> > licenses that allow storage and offline viewing, but we feel that money is
> > better spend on offering more variety of content. A competitor could take a
> > different view and the customers would decide what they preferred.
> > 
> > There's no 'artificial' construct here that you can expect to change just
> > due to technical capabilities.
> 
> If the back channel is removed then you no longer have a capacity to
> verify or enforce such licensing terms and then what the user does
> in their own privacy with the bits of data you send to them becomes a
> private matter for the user.

Right, and that would be a different service from the one we offer today.
Probably with a different price and much more limited set of content.

Because we want to support our service as it is today, we need the license
server interaction for every streaming session. Hence the proposal is the way
it is.

>  
> > Returning to the subject of the bug, as I mentioned before it's not true
> > that *EME* requires that license servers be available to view the content. A
> > *service* such as ours may require that - for the reasons above - but
> > another service may not. In our case, with respect to this issue, EME is
> > doing nothing more than making it difficult for users to do something
> > they've already agreed not to by signing up to the service.
> 
> 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.

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

Sure.

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

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

Of course there are platforms which do offer such protections - the easiest
example being completely closed platforms such as most TVs - and on these
platforms the range and quality of content available might be different.

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

Received on Friday, 22 February 2013 15:51:18 UTC