[Bug 21231] License descriptor attribute

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

--- Comment #11 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #10)
> (In reply to comment #9)
> > > Of the class of solutions for which the user can already
> > > technically access the decoded stream, does EME/CDM offer
> > > any more protection than the proposal+secure transport?
> > 
> > As I said, EME/CDMs offer the possibilility to protect the keys and encoded
> > content, which are different things from the decoded content.
> > 
> > I'm not saying any more than this. To some authors, the ability to easily
> > store the decoded content may be 'just as bad' as easy access to the keys or
> > encoded content and so these solutions may be equivalent. To other authors
> > these things may not be equivalent. That is all.
> 
> Ok, that sounds like a acknowledgment that there are a large
> class of use cases for which the proposed solution would be
> equivalent.
> 

I did't make any statement about the relative size of the classes of use-case.

> Perhaps someone else could elaborate on the other set of
> disputed use cases: authors who want to protect the keys and
> encoded content even when the user can access the decoded
> output.
> 
> What is the threat in these cases?
> 
> Why can't secure transport alone offer the needed protection?

It's not for me to elaborate the threat models that are of concern, because
those concerns differ from author to author. If you want to learn the details,
scope and variety of content protection requirements - for example from studios
and others - then you need to talk to them. You're not going to learn that
here.

Nevertheless, one example is that given easy access to the keys, one could
harvest the keys for a whole catalogue and use those to set up a service
providing free access to that catalogue, using the service providers own
distribution system and any browser. 

So the situation is very different from individual users saving decoded content
files using custom software.

Also, re-encoding the entire Netflix catalogue costs us millions of dollars, so
access to encoded content is clearly a very different thing from access to
decoded content.

> 
> Is the issue here that storing the encoded content plus the
> key would be preferable to storing the decoded content,
> perhaps because the key might be easier for the user to
> protect than a large decoded, or recoded but unencrypted, blob?
> 
> Perhaps a 'store-securely' flag would address this matter?
> 
> If we could understand the scope of these use cases then it
> would be possible to either address them with a simpler
> solution or declare them out of scope of the proposed
> solution.

Your statement is true, but if your goal is to design a new content protection
system that improves on those already in the market for some class of content
then you need to talk directly to your prospective customers.

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

Received on Tuesday, 12 March 2013 16:22:33 UTC