[Bug 21869] Need clarity on stored keys for CDMs

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

--- Comment #13 from Joe Steele <steele@adobe.com> ---
(In reply to comment #12)
> 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.

[steele] The assumption that these use cases can be solved for a given DRM
system without storage is simply not true. Some DRM systems rely on downloaded
persistent keys for *ANY* operation and not having that ability severely
restricts their utility relative to their implementation on other platforms. 

> 
> 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.

[steele] It does not make sense to optimize for browser developers time (where
there are only a handful) above web application developers time (where there
are many, many more). We have explored alternatives and they are all less
performant and require existing DRM systems to restructure to a much greater
degree for no additional benefit.


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

[steele] Agreed
> 
> (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.

[steele] I am not arguing that this problem cannot be solved with application
storage. I would accept that as a fallback position, given that provides the
necessary storage capability. 

Given that this is a requirement for at least two DRM systems that have been
mentioned (Adobe Access and Marlin V3), it should be addressed by the spec.

As a side note -- there is nothing in the CENC spec that says the
initialization data cannot contain keys and in the case of some DRMs it does.

> 
> (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.

[steele] The application does not need to tell the CDM to retain any keys. This
can be handled by the key responses themselves, which can contain a lifetime
for the key. This places the burden on the key server and the CDM, which is
where the key management should be occurring.

> 
> > 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.

[steele] It is our job to solve the security and privacy issues. I believe a
simple statement that it is the UAs responsibility to provide this facility for
CDMs, without specifying how, will give the flexibility needed. CDM code in
general will be much more difficult to modify than UA code or web app code, and
that is what should be driving the API discussion. 

> 
> > 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.

[steele] This was an attempt to provide a mental model. Nothing more.

> 
> (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.

[steele] I am not sure what you are arguing for or against here. 

> 
> (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.

[steele] I was under the impression that the goal of this spec was to provide
support for existing DRM systems to operate under a common API. I am telling
you there are existing DRMs which will not function correctly or efficiently
under the API as spec'd. Yes -- there *may* be workarounds but those will
increase the complexity of the CDMs not decrease them and decrease their
utility when used through this API. But why should we fallback to workarounds
when the API is still under discussion. This is a well understood, common use
case which could be implemented with minimal changes. Preventing this use case
is only a roadblock to CDM vendors which do not own a browser (Microsoft,
Google, Apple) and will discourage implementation by other CDMs.

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

Received on Tuesday, 6 August 2013 15:17:10 UTC