[Bug 21869] Need clarity on stored keys for CDMs

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

--- Comment #12 from David Dorwin <ddorwin@google.com> ---
I think most use cases can be solved using application level storage. There may
be a few use cases that really do rely on some type of "secure storage", but
that should be a last resort. (These probably also require CDM-specific
knowledge in the application.) Most use cases, particularly online streaming,
should be accomplished without storage or key sharing (see bug 17202). This
keeps the integration, privacy, security, etc. complexity lower for browsers
and other UAs.

For implementations that do support those specific use cases, data should be
stored in a per-origin, per-profile, and user-erasable (similar to cookies,
etc.) way.

I think it would be better to solve as many use cases as possible in the
application and potentially revisit the issue of storage later rather than
burden all UAs/CDMs with storage requirements before we've explored
alternatives.


(In reply to comment #2)
It seems most of the scenarios in comment 2 could be solved with application
storage.

(In reply to comment #6)
> 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. 

It's unclear what part of this use case requires storage in the CDM and
couldn't just be done using application storage. This already sounds like a lot
of application complexity, so I don't think using storage APIs is unreasonable.
Note that initData is data from the container and cannot include keys.

(In reply to comment #8)
> (In reply to comment #7)
> > Compared to what I said above, David Dorwin had an even better idea
> > according to the latest meeting minutes.
> > (http://www.w3.org/2013/06/18-html-media-minutes.html#item03)
> > 
> > To expand:
> > If you want data to stay around on the client side beyond having it in RAM,
> > have the CDM pass an encrypted data packet to the JavaScript application,
> > how the JavaScript application store the encrypted packet in IndexedDB and
> > then next time have the JavaScript application take the encrypted packet
> > from IndexedDB and push it back to the CDM. This way, the privacy controls
> > that browsers need to provide for IndexedDB anyway would automatically apply
> > to data that CDMs want to keep around.
> 
> This is not quite the right approach. This will cause more CDM-specific code
> to need to be written.

Telling the CDM to store a key will require CDM-specific code somewhere (server
or application). If applications are responsible for storing keys, the app
behavior would be the same for all key systems (i.e. get message from server
and store message in IndexedDB however the app wishes then later retrieve
message from IndexedDB and provide to CDM in update() call). Without specifying
key storage APIs, key storage and retrieval would be very CDM-specific.

> I believe this imposes an unnecessary burden on the
> app developer for no additional security or privacy.

The alternative is burdening all clients with responsibility for providing
storage as well as solving the related security and privacy issues. The clients
would also be much less flexible and may not satisfy all applications. It is a
lot easier to write, ship, and modify web app code than UAs or CDMs.

> Consider the CDM to
> behave like a local server, and this data to be cookie data. When a web app
> contacts a server, it does not have to explicitly store each cookie that
> comes from that server. It can inspect them and it can forbid them to be
> stored, but only if it wants or needs to. This is the kind of API I would
> like to se for storage. 

The purpose of the CDM is to decrypt content, not provide a local server. There
are many other web APIs available for providing a "local server", and EME
should not duplicate or reinvent them (including all of the corresponding
privacy and security issues). UAs will have a much better chance of providing
the appropriate controls and expected behaviors if storage is handled by the
application using existing APIs.

(In reply to comment #11)
> (In reply to comment #7)
> This seems to place a bunch on complexity in the application and doesn't
> look significantly simpler for the UA than having the UA implement the
> storage and privacy handling of the of the encrypted blob internally.

Applications looking to optimize massive traffic will be complex. Web
applications can be easily updated/tuned, and there are already many APIs,
norms, user expectations, security & privacy settings/tools, etc. around web
applications. On the other hand, browsers and CDMs are updated less often, we'd
have to invent new APIs and storage mechanism, etc. Users understand clearing
cookies, but it would be hard to explain clearing saved DRM keys. One of the
goals of EME is to put the application in control, even if that means more
logic is in the application. (For example, the application is responsible for
authorization and communicating with the server.) I don't see why the
philosophy should be any different for storage.

(In reply to comment #10)
> (In reply to comment #3)
> > 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. 
> > 
> 
> We have found significant advantage for long-form content if a connection to
> the application servers is not required for streaming to continue. That is,
> once the key and content URLs have been acquired, streaming can continue
> even if the application server connection is lost. If a heartbeat is
> *required* to continue streaming, then the availability requirements on the
> application servers go up by an order of magnitude.
> 
> OTOH, relaxing tracking requirements would make it impossible to implement
> business rules like limitations on the number of concurrent streams on an
> account.
> 
> This is why we prefer a solution with secure proof of key release. This does
> require CDM storage for the 'last CDM state' - specifically the identities
> of the keys the CDM is currently using or for which secure proof of key
> release has not been acknowledged by the server and a reliable indication of
> the time.

Likewise, this pushes app-/site-specific logic into the clients, requires CDMs
to have access to storage even for basic online streaming, increases the
complexity of the (closed-source, third-party, etc.) CDMs, and requires
expanding the UA-CDM API. There are known solutions for increasing
availability, and we should not try to push workarounds to those into every
client.

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

Received on Tuesday, 6 August 2013 07:06:19 UTC