This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24016 - Multiple outstanding key requests allowed
Summary: Multiple outstanding key requests allowed
Status: RESOLVED LATER
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-06 01:32 UTC by Joe Steele
Modified: 2013-12-09 15:45 UTC (History)
4 users (show)

See Also:


Attachments

Description Joe Steele 2013-12-06 01:32:24 UTC
It is possible for the browser get into a situation where multiple EME key requests are outstanding at the same time. Since they are asynchronous, the order the responses are received in is indeterminate. However there is no way to directly associate a response with its request today. 

Example: An application is playing back a video stream which makes frequent key requests (e.g. heart beat testing). If the delay between sending the request and receiving the response is longer than the heart beat interval, you are now in this situation. 

This could be addressed in a variety of ways:

* We could explicitly say that no additional key requests may be sent for a given key session until the outstanding request has been completed. 
* We could require a URL to be passed in with the update() call which the CDM could match against the outstanding requests.
* others?
Comment 1 David Dorwin 2013-12-06 02:07:43 UTC
What specifically is the problem with such outstanding requests that you're trying to address? In other words, why do the requests and responses need to be associated (other than perhaps within the server-CDM protocol)?
Comment 2 Adrian Bateman [MSFT] 2013-12-06 17:37:56 UTC
(In reply to Joe Steele from comment #0) 
> * We could require a URL to be passed in with the update() call which the
> CDM could match against the outstanding requests.

Presumably any value that could be passed into the update() call as an additional parameter could also be included in the response from the server for those CDMs that need this?
Comment 3 Joe Steele 2013-12-06 17:53:52 UTC
(In reply to David Dorwin from comment #1)
> What specifically is the problem with such outstanding requests that you're
> trying to address? In other words, why do the requests and responses need to
> be associated (other than perhaps within the server-CDM protocol)?

The requests may need to be processed in serial order. For example if request N+1 relies on information provided in response N. If the responses arrive in the wrong order, the processing could fail, even though the correct responses are all available. 

(In reply to Adrian Bateman from comment #2)
> Presumably any value that could be passed into the update() call as an 
> additional parameter could also be included in the response from the server
> for those CDMs that need this?

True - however that would not allow supporting existing servers and content tied to those servers. 

This could also be handled in the app by tracking all the outstanding requests and sending the responses down in serial order. I guess we could write some boilerplate code for that and post it somewhere?
Comment 4 Adrian Bateman [MSFT] 2013-12-06 18:10:41 UTC
(In reply to Joe Steele from comment #3)
> This could also be handled in the app by tracking all the outstanding
> requests and sending the responses down in serial order. I guess we could
> write some boilerplate code for that and post it somewhere?

Can't the CDM cache or drop out of order responses? Presumably if this is common (because the requests are taking too long) then sooner or later playback is going to fail because the license service isn't keeping up with the media?
Comment 5 Joe Steele 2013-12-06 18:29:13 UTC
(In reply to Adrian Bateman [MSFT] from comment #4)
> (In reply to Joe Steele from comment #3)
> > This could also be handled in the app by tracking all the outstanding
> > requests and sending the responses down in serial order. I guess we could
> > write some boilerplate code for that and post it somewhere?
> 
> Can't the CDM cache or drop out of order responses? Presumably if this is
> common (because the requests are taking too long) then sooner or later
> playback is going to fail because the license service isn't keeping up with
> the media?

It may be impossible for the CDM to distinguish between a response received out of order and a corrupted response, if the responses are encrypted. 

If the server lag is long-term, playback *is* going to start failing and it probably doesn't matter if the CDM fails because of out of order responses or because it can't get the keys fast enough. If the server lag is momentary, playback could start failing but might be able to continue if it receives responses in the right order. 

I think we can probably wait to see whether this is a problem in the real world. After some research into real-world heartbeat usage I don't think this scenario is common enough to worry about at this point. I will go ahead and close this.
Comment 6 Joe Steele 2013-12-06 18:30:24 UTC
We should wait for implementation experience before we do anything here.
Comment 7 Mark Watson 2013-12-09 15:45:31 UTC
I would expect a CDM that can generate multiple outstanding requests would need its own (secure) method to associate requests and responses, for example by including a sequence number in the protected part of the message.