[Bug 21869] Need clarity on stored keys for CDMs

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

--- Comment #6 from Joe Steele <steele@adobe.com> ---
(In reply to comment #5)
> The concept of a "subscription key" isn't in EME, though, and the way to
> invoke CDM operations in a EME world is to attempt to play an encrypted
> track. How would the acquisition of the subscription key actually work with
> EME? Would the user have to navigate to the site days ahead of time and have
> the site programmatically play a trivial video file in order to do something
> that triggers EME and gives the CDM the opportunity to talk with the server
> and change its state?

The way I have envisioned it working (and tried to move the spec in that
direction) is pretty close to that model. The user would signup with a
streaming service. After the signup process, the application would download a
bundle of keys that would be passed as initData during createSession(). This
would cause any initial setup of the CDM and supplementary keys to be acquired.
This will take some time, but this can happen while the user is browsing the
options available so there is less impact on the user experience. Then when the
user selects a video to play, there may be no additional key acquisition
required. 

> Is this an interoperable CENC feature, or are we now talking about a DRM
> scheme-specific feature that would defeat the CENC-based interoperability
> story on EME?

CENC is about how the content is encrypted, not how the keys are acquired.
Different CDMs can provide the same key using different mechanisms. For example
one CDM could require a license server request, while another could have the
required key on hand already.

> > In DRM systems which
> > support a hierarchy of keys and the keys are acquired in stages (for example
> > from different servers) it is useful to be able to retain the intermediate
> > keys between sessions to avoid the costs I outlined above where possible.
> 
> Is the idea that intermediate keys are used with a less obfuscated copy of
> the crypto code than the key embedded in CDM itself?

That is a possible implementation but not what I was getting at. A performance
boost from doing fewer license requests is what you gain here. 

> If the user tells the browser "Forget about example.com" and the CDM's
> example.com-related records aren't deleted, that would be a notable
> violation of the user's privacy expectations.
> 
> > I don't see the privacy concern here if this data is handled like web
> > application data is today, segregated by domain and subject to CORS
> > restrictions. Please articulate why you think this has privacy implications. 
> 
> Unless there is the added complexity of a mechanism that allows CDM-stored
> data to be deleted together with other traces that a site might have left in
> the browser, a person examining the user's computer can use CDM-stored data
> as evidence of sites visited and servers can use CDM-stored data as evidence
> of a prior visit.
> 
> The easiest way to avoid this problem would be not to store anything
> persistently. However, crypto operations in the CDM alone taking multiple
> seconds does indeed put the user experience trade-off in a different light
> if storing a service-specific intermediate key would substantially speed up
> subsequent content key acquisitions form the same site and might justify the
> complexity of having a mechanism for clearing the data that integrates with
> the other data clearing mechanisms in the browser.
> 
> > I think adding restrictions here (above what normal web app applications are
> > subject) would only result in a worse user experience and no additional
> > privacy.
> 
> If the CDM-stored data is cleared together with the other storage mechanisms
> offered to sites, there's no new privacy issue. If not, there is.

Sounds like we are in agreement then. I believe CDM-stored data should be
clearable just like other storage mechanisms. My only caveat is that
identifying the type of data would lead to a better user experience.

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

Received on Saturday, 8 June 2013 00:07:37 UTC