[Bug 21869] Need clarity on stored keys for CDMs

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

--- Comment #3 from Henri Sivonen <hsivonen@iki.fi> ---
(In reply to comment #2)
> Retaining some keys allow for better performance and usability. Every key
> acquisition has a cost, both to the user (representing either user time
> spent or delay to first playback)

Isn't this best solved by letting the video start with a few seconds of
unencrypted content even though the keys are declared up front so that playback
can start during the key acquisition.

> and to the server operator (key retrieval
> on the back end).

Considering how network chatty Web apps are in general fetching images, doing
XHR, etc., it seems weird to me to try to optimize away key reacquisition. One
would expect the messages to be small in terms of the number of bytes, the
crypto operations no heavier than a TLS handshake and key lookups not more
advanced than database lookups that many sites do all the time.

Is there something intuition-defying about the cost of talking to a license
server that would justify the avoidance of key reacquisition? I had expected
key reacquisition would happen even more often than it really has to in order
to implement heartbeat.

> Some keys may be required again and again - for example if a group of
> devices is associated with the same account, a common key can be used to
> request content licenses for those devices. 

This seems to imply that DRM-level domains would be involved. Since the design
of EME handles login using regular session cookies, it seems to me that the it
makes no sense to for EME CDMs to have the concept of domains, since domains
can be implemented entirely on the server side if desired.

> Some keys may only be required for a particular piece of content, but you
> don't want to have to pay the cost of acquisition again just because you
> have put your machine to sleep briefly. 

Why is this unwanted? Web apps like Gmail ping a server all the time. OTOH,
Netflix's player times out when paused even if the computer is awake.

> And in some cases it may not be convenient to reacquire the key, for example
> if the key can only be acquired in a private environment but the content is
> available to key holders in public environments.

I have trouble seeing what sort of movie streaming service would work like
this.

> Also there may be metadata about the keys themselves which needs to be
> retained, for example how many times this piece of content has been played,
> when the first playback started, etc. This can be maintained on the server,
> but there can be a cost benefit to users and content providers to have this
> local.

Seems like the client side could be simpler by handling this by the keys
expiring often and the connection to the license server being chatty with
re-requesting keys all the time as a form of heartbeat. If the server side
doesn't like the complexity, maybe the server side should relax tracking
requirements. 

Considering privacy, it would be the best that the CDM didn't store anything
persisently and, therefore, didn't create a new class of cookie-like data. I
think adding a class of cookie-like data in order to optimize round trips to
the key server is a bad tradeoff.

I would prefer EME banning CDMs from writing anything to persistent storage as
a result of talking with a key server of a content service (in order to avoid
the creation of a new class of cookie-like data). This formulation would still
allow downloading an IBX from the DRM vendor (as opposed to a key server of a
content site) and storing it as part of CDM setup.

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

Received on Thursday, 23 May 2013 15:18:57 UTC