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

You are correct, if the CDM is asked about a key it already has it could respond that way. But that would be bad. 
Let me recap the arguments so far — 

Why not just share the key between sessions?
This would leak information about the content that the user is watching. If I want to know whether the user has watched a particular encrypted video I can extract the initData from that video and call createSession from within my site. Then if a needKey event is not fired, I can infer that the user has watched or is watching that video. In this scenario, I don’t want to share the key between CDM sessions unless I know there is a trust relationship between those players (e.g. they are in the same network). If there is a trust relationship the players can already share information via other means, so I am not revealing anything new about the user. 

Why doesn’t the CDM have enough information to enforce this itself?
When the CDM session is established, it is only guaranteed to have the initData which is content specific, not player-specific. Currently the CDM is not required to be informed of the player or origin for which this key is needed. The player may be able to pass this in (depending on the resolution of bug#17660) but currently it is unclear.

Why should the UA be the one to provide the information?
The UA has information about the CORS headers for the player origin. This establishes a one-way trust relationship with other origins. This relationship could be extended to keys. The player could also provide this information by including it with the initData, assuming that is allowed. Or the CDM could request this information via a keyRequest event. The former approach could make the player more CDM-specific, and the latter approach would either make the player more CDM-specific or introduce an additional network call. Since the UA already has this information, it seems like a more efficient approach to simply provide it to the CDM. 

Why was the bug resolved the way it was?
As David pointed out, the cross-origin sharing of keys is an edge case today that we don’t have much evidence to support. Since there are work-arounds (albeit less efficient/desirable ones) and there is now an acknowledgment that keys may be shared (https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#privacy), CDM implementors can leverage the workarounds if needed to support players.

Joe Steele
steele@adobe.com

On Nov 15, 2013, at 12:46 PM, Petr Peterka <ppeterka@verimatrix.com> wrote:

> I don’t understand why this needs to be defined outside of the CDM. The CDM should enforce whatever rights and limitations are associated with the content (and the corresponding keys). If the CDM is asked for a key it already has, it should just respond with key-already-present-no-further-action-needed. Or did I misunderstand the goal here?
>           Thanks
>                    Petr
>  
> From: Joe Steele [mailto:steele@adobe.com] 
> Sent: Wednesday, November 13, 2013 6:30 PM
> To: David Dorwin
> Cc: Mark Watson; Henri Sivonen; public-html-media@w3.org
> Subject: Re: ACTION-40: Propose text for bug 17202 to propose how to share keys without leakage of information
>  
> * PGP Signed by an unknown key
> If I have the same player open in two different tabs (or twice on the same tab), viewing two different videos which share a network key, then the underlying CDM *may* be able to share the live key context between the player instances and not have to open a second identical key context. The mechanisms for recognizing whether keys can be shared and which keys can be shared is would be CDM dependent. It could apply to any key I think, although it only seems useful to me for keys from which other keys are chained (like domains). 
>  
> This would *not* be sharing across domains, but as you suggested that is probably a small enough edge case that it is not worth adding to the spec at this point. 
>  
> Joe Steele
> steele@adobe.com
>  
> On Nov 13, 2013, at 6:16 PM, David Dorwin <ddorwin@google.com> wrote:
> 
> 
> 
> 
> On Thursday, November 14, 2013, Joe Steele wrote:
> 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. 
>  
> I'm not sure I understand this lat part. Can you explain what you mean by "live keys can be shared"? (Keys from one origin or multiple? How does the CDM know to share them? Does this only apply to "domain-like" keys?)
> 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?
>  
> Specifi
>  
> * Unknown Key
> * 0x2C9088FC