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

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.

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.

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.


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

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