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

On Thu, Nov 14, 2013 at 9:30 AM, Joe Steele <steele@adobe.com> wrote:

> I am not arguing for any non-CORS web sharing. I *am* arguing that the CDM
> should know what the CORS relationships are before it attempts sharing
> keys.
> I am trying to define a mechanism for informing the CDM of those CORS
> relationships.
>

Isn't that just between the UA and the CDM. How does it impact our API ?



>
> Joe Steele
> steele@adobe.com
>
> On Nov 13, 2013, at 12:47 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> I can't claim I have followed all of this thread, but surely we are best
> off at this stage simply saying that CDMs must follow the same origin
> policy with respect to shared data (including CORS-same-origin). IIUC,
> WebApps is looking at the more general problem of resources which are
> shared across origins which are not CORS-same-origin.
>
> ...Mark
>
>
> On Wed, Nov 13, 2013 at 4:18 PM, David Dorwin <ddorwin@google.com> wrote:
>
>>
>>
>>
>> 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
>>>>
>>>
>>>
>>
>
>