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

I was making that change at the API level to raise its visibility. It could be exposed simply between the UA and the CDM, but it still needs to be documented in the specification. My fear was that if this was not an explicit part of the spec, browser vendors will not bother to include it.

However …  David pointed out a simpler solution for the main use case I was concerned about where framing the video player is an option. I am willing to drop this. True sharing between different domains is probably an edge case not worth optimizing for. 

For those types of sites, persistent keys will not need to be shared across domains and live keys can be shared invisibly by the CDM without any privacy concerns. 

Joe Steele
steele@adobe.com

On Nov 13, 2013, at 5:38 PM, Mark Watson <watsonm@netflix.com> wrote:

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