[Bug 25092] Need a way to inform script that resolution restrictions are applied

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

--- Comment #33 from David Dorwin <ddorwin@google.com> ---
(In reply to Mark Watson from comment #30)
> Ok, let's agree on "downscaling" as a new key status.
> 
> Nevertheless, pls see comments below. In summary, we can't require that the
> policy associated with a key id is independent of content properties. It's
> already very common to have policies that are content property dependent.
> So, key status can change as content properties change.

The key status should not change based on the content. The key status indicates
the status of the key based on the license and environment (i.e. HDCP or time).

For example:
* A key that does not require HDCP is always valid (assuming it has not
expired, etc.).
* A key that requires HDCP is valid if HDCP is enabled and either
output-downscaled or output-not-allowed (depending on the client
implementation) otherwise.

In the case where a single content key is used for all streams, the first key
(the real one) would always report valid, and the second (fake) key would
report whether the output protection policies for higher resolutions can be
met.
> 
> This means that you can't learn that content will be downscaled until you
> feed some content in, but we can live with that for the moment (I believe
> there are other reasons why that is the case anyway).

The above design enables you to determine whether content will be downscaled
without feeding it in. This was an important part of the design as it allows
applications to determine which streams to download without having to have
already downloaded streams that will trigger an output protection status
update/event/error. This was the subject of Bug 25409 ("Allow applications to
detect whether a key is usable before using it to decrypt content"), which led
to keyStatuses (via usableKeyIds).

The intended behavior could probably be better explained in the spec. I filed
https://github.com/w3c/encrypted-media/issues/22. Suggestions welcome.
> 
> If, instead, we wanted the key status to be content-independent, we'd need
> the status to be a map of resolution -> status.

I don't see why. The application just needs to map key IDs to streams.
(Resolution is actually irrelevant unless it's used to select streams, but that
is an implementation detail of the application.)
> 
> (In reply to David Dorwin from comment #29)

> > (In reply to Mark Watson from comment #27)
> > > So, this solution forces us to associate multiple key ids with the same key
> > > in order to express the distinct policies.
> > How much of a burden is this the extra key ID? I don't think there is
> > actually any association - you would always use the same key ID for the
> > "high resolution" policy.
> > 
> > > Worse, the association of policy
> > > to key ids is done in a completely undefined way (which will thus probably
> > > differ between CDMs).
> > How is it undefined? As with "real" key IDs, the application and its server
> > set policies for the key and the CDM reports whether they are enforceable.
> 
> If you are using separate keys with separate policies and the policies are
> all content-independent and the CDM supports such multiple keys in one
> session, then everything is fine.
> 
> But there are CDMs that support only a single key or only a single key at a
> time. And there are CDMs that support content-dependent policies. These CDMs
> would probably need modification to expose multiple key ids associated with
> the same actual key, corresponding to splitting up the policy by content
> property such as resolution. How that is done - what those extra key ids
> would be etc. is undefined (CDM-specific).

I filed https://github.com/w3c/encrypted-media/issues/23 for the more general
and problematic issue of CDMs only supporting a single key. If you think there
are additional interoperability issues or undefined behavior, please file
additional issue(s).
> 
> We need first-class support for the case of policies that are dependent on
> content properties, since this is going to be common. The proposed key
> status values do provide this, albeit in a limited form.
> 
> > > 
> > > It would be cleaner, now that the CSS discussion has concluded this is not a
> > > subset of a more generic requirement, to simply have explicit output
> > > protection events.
> > One important goal of the current solution was to allow the status to be
> > exposed without trying (and potentially failing) to play content.
> 
> That's a good goal, but it is not supported by the proposed key status
> values, since there is no way to expose the content-dependent aspects of the
> policy for a single key id.

It is supported as I explained above. It is definitely not supported if we rely
on the properties of content processed by the CDM to change the status.

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

Received on Saturday, 24 January 2015 00:50:49 UTC