Re: ACTION-40: Propose text for bug 17202 to propose how to share keys without leakage of information

Replies inline — 

Joe Steele
steele@adobe.com

On Nov 11, 2013, at 10:52 PM, David Dorwin <ddorwin@google.com> wrote:

> Is there a way to solve this by running scripts from multiple domains and using the normal CORS rules for applications?
> 
> Specific comments inline.
> 
> On Tue, Oct 29, 2013 at 9:42 PM, Joe Steele <steele@adobe.com> wrote:
> The sharing of keys for performance may apply in multiple cases. This proposal also impacts bug 21855.
> 
> Keys may be shared between multiple sites which have a trust relationship. For example a sports network may own multiple sites each dedicated to different sport content. That content may all be tied to a single “network” key used to derive the content keys for individual streams. Any consortium of media sites may have a relationship which allows them to display each others content. In this case, an active key acquired for one site should not need to be re-acquired for another. 
> In the consortium case, it would be simpler for the sites to all use a single domain for their player (i.e. video.example.com) and use iframes to integrate it into the various media sites.

That is a good idea, but will not work in all scenarios. I was thinking originally that would not work at all because each dedicated site would want its own ad streams and branding, but after thinking about it more I realize the framed site could be constructed to allow for that in some cases.  I think this is a good solution for that use case.

There is another use case where framing would not work however. The DECE/Ultraviolet architecture allows for streaming services (LASPs) that do not have dedicated players. For services like this, there could be multiple players which are allowed to play content served by that LASP. In this case these players can easily be bound to different domains. Since the same content is playable by all, it would be advantageous to allow the content keys (or any higher level keys) to be shared rather than acquired multiple times if possible. 

> 
> Alternatively, if the single "network" key is stored (encrypted) by the application, it could be read (from the "network" origin) and provided to the CDM at runtime.

I think this is more problematic. Whoever is driving storage of the keys has to know what keys need to be stored and where they can be stored and retrieved from. Only the CDM should know the first part. The application could know the second part, but it seems like more work for the application to try to retrieve stored keys from each domain it could be stored in to pass down to the CDM. 

If the application is driving this storage, it would require that the application know of and have access to all the domains that might be storing the key. It would also have to either understand the CDM key logic perfectly in order to pass the right keys at the right time OR collect all available key information and pass all of it to the CDM at createSession time. Neither of those seems feasible. 

If the CDM is driving the storage, it would need an explicit mechanism for storing and retrieving information via the application. This was proposed before (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869#c13) and I would accept this as a fall-back position. Although as I pointed out in that comment, this seems to be optimizing UA developers time over web application developers time, which seems like a bad trade-off to me. 

> 
> On Tue, Oct 29, 2013 at 12:57 AM, Joe Steele <steele@adobe.com> wrote:
> ...
> I propose that the browser uses CORS Access-Control-Allow-Origin headers for the sites to determine the trust relationships between them.
> Would the UA be able to check the CORS headers given that EME APIs don't make any of the related network requests? I'm not familiar with how such information is tracked/retained in browsers.

I have not looked to see how the browsers I have access to track this information. But in order for them to be CORS-compliant, I believe they must be able to track the CORS headers associated with a domain. That is how I read the spec anyway. I would be happy to be corrected by someone expert in CORS compliance.

>  
> The browser can then provide a list of active session ids for sites trusting the current site with the needkey message when encountering encrypted content.
> The needkey event is triggered by the UA without any interaction with the CDM, but session information and any key system-specific capabilities are handled by the CDM. needkey also needs to be fired quickly without reading data off disk, loading the CDM, etc. Such a change would significantly complicate (and abuse the purpose of) the needkey event.

The UA must already maintain a list of active sessions associated with each application (per section 4.2). Each application has a domain and the UA must already maintain some knowledge about the list of CORS headers for a domain. So the mapping of CORS headers to active sessions should be possible to construct as the sessions are created, without any additional information. 

I made the passing of active session IDs explicit to be more open about what is going on. However I think it would be fine for this information to be silently added (from the point of view of the application) to the createSession call that the CDM sees. But it would still need to be added to section 4.2 as part of creating the MediaKeySession object. 

> 
> ...
> This has a few implications:
> * The CDM must be creating the session ID if it wants to support this
> I believe it is very likely that the CDM will create the session ID in most implementations.
> * The browser must keep track of session IDs in relation to CORS trust relationships 
> This is a lot of complexity to add to browsers for a single use case. This is also complicated by CDMs creating and owning session IDs. 
> * The needkey message needs another parameter - a list of session IDs which may be empty
> See above. 
> * The createSession method needs another parameter - a list of session IDs which may be empty