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

On Wed, Nov 13, 2013 at 2:28 PM, Joe Steele <steele@adobe.com> wrote:

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

Are you saying we should support sharing of keys so that I can watch the
same movie *M* from LASP *L* on fooplayer.com and barplayer.com without
re-requesting the key? This seems like an unlikely scenario and one in
which startup latency is unlikely to be a great concern. I would be more
concerned about movie M and movie N on fooplayer.com, even if the use
different LASPs.

>
>
> 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.
>
Why does only the CDM know which keys need to be stored? If there is a
"network" key, the application should certainly know about it since that is
how the application is architected, and the server can flag it when
providing it to the application.

>
> 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.
>
The applications would all know that mynetwork.com has the master key, etc.

> 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.
>
I assume all sites in the network would use a common algorithm. Example: 1)
provide the network key 2) provide the content license.

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

As this discussion demonstrates, there are many possible use cases, and we
can't possibly figure them all out and bake them into the spec, browsers,
and CDMs. Even if we did bake them in, this would prevent applications from
changing behavior later. Since CDMs will vary, application-based solutions
are likely to be more interoperable as well.

Speaking of interoperability, this use case seems less likely to be
interoperable than other use cases. It might be better to focus on
alternative solutions for the performance concern that would work across
UAs and key systems.

>
>
> 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).
>
I think the text you are referencing has been removed. EME now only worries
about CORS when it comes to needkey, which may be the result of media data
from a different domain.

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