Re: [EME] MediaKeyError codes proposal (bug 21798)

Replies inline —

Joe Steele
steele@adobe.com

On Nov 12, 2013, at 11:56 PM, David Dorwin <ddorwin@google.com> wrote:

> This email provides a framework and suggestions for resolving Bug 21798 - Revisit MediaKeyError codes.
> 
> I think we should have the following goals:
> Codes should be for things that would allow the application do one of the following:
> Adapt/respond to enable playback to continue
> Give the user a useful/actionable message.
> Codes should be commonly useful across implementations.
> Codes should generally be for things that are only known to the user agent/CDM. (In contrast, there are other ways to report errors known to the server.)
> Codes should be described in sufficient detail that they can interpreted unambiguously by different implementers and it is clear how an application should respond.
> Start with codes we know will be useful. We can always add them later based on implementation experience.
> 
> With that in mind, I’ve identified the following categories of errors I think we must include. Some may make sense to split into separate codes, and I’ve mentioned potential individual cases where applicable. I’ve also included the expected application behavior for each, which I think is an important consideration for any error code.
> 
> Unknown/Other - “An unspecified error occurred. This value is used for errors that don't match any of the following codes.”
> Expected application behavior: General failure message. It is not possible to recover since there is no specified cause.

This would be useful although of course frustrating for the user. 

> Output [protection]
> The current description is “There is no available output device with the required characteristics for the content protection system.” That seems like a subset or inaccurate description of cases that should be covered.
> Is it useful to differentiate the case where the error resulted from a display change (new display, player window moved, etc.)? (An application might be able to infer this based on the amount of time it has been playing without such a separation.)

I don’t think this would be particularly useful and would be difficult to determine in some cases. 

> 
> Expected application behavior: Inform the user of the problem and/or try a different license, possibly using alternate streams. (The response may be different depending on whether the error resulted from a change.)
> Expired
> The key/license is no longer valid.
> This could be broken up into multiple scenarios:
> Renewal failed
> The time window has passed
> Number of plays exceeded
> Instructed to stop by license server

I am not sure how useful different i. and iv. are. Are you thinking in one case the user could request a new license and in the other it could not? (i.e. don’t bother)

> Expected application behavior: Inform the user there was a problem (renewing, rental expired, etc.).
> If we use a single error code, the application will need to derive the messaging based on knowledge of the application, licensing, etc.
> Key System/CDM cannot be used
> There are potentially several classes of causes that could potentiall be separate codes:
> Key System (CDM) is disabled (by the user)
> I can imagine this being useful as it allows applications to provide the user with specific instructions, but it also enables fingerprinting and exposes something about a user that is probably concerned about privacy.
> Identifiers are disabled (by the user)
> Similar issues to above.
> CDM could not be found, failed to load (i.e. due to dependencies), has not been initialized/enabled.
> Similar to or could be merged with to “Key System (CDM) is disabled”, though the desired messaging for each scenario would be very different.
> Expected application behavior: Inform the user that there is a problem and possibly general text about how to address it.
> For the latter, it may be useful to at least differentiate user controllable/resolvable issues vs. more complex issues (i.e. CDM failed to load).
> If we want to use a single code, we might just use “client” (where client refers to the CDM). Maybe there is an even better name.
> 
> I think the following would also be useful:
> Platform capabilities not available
> Similar to Output [Protection], but this device can never meet the license requirements.
> Expected application behavior: Try a different license, possibly using alternate streams.
> Initialization failure (needs a better name)
> Some implementations have various individualization, etc. steps.
> Expected application behavior: Inform the user, possibly telling them to try again or contact the device manufacturer.

I agree both of these would be useful. 

> 
> Another possibility - this really depends on how we want to handle such delays.
> Deferred/Delayed (more of a status than an error)
> This mostly relates to initial use [on an origin], which may take longer in some implementations.
> The code is an indication that the operation is not possible now but should be soon. As a status, it just means the operation (likely createSession()) is pending. Alternatively, the error could be fatal and the application should try again (calling createSession() again).
> Expected application behavior: This is mostly a hint that the application should not time out in cases where message or ready events may not be fired soon.
> 
> The following codes are currently in the spec but not included above. If someone would like to make an argument for one of these, please consider the goals above and the “expected application behavior”.
> Client - “The Key System could not be installed or updated.”
> Since CDMs should not be installed, the first part of the error definition is obsolete. It’s unclear what would cause a “not updated” error.

I disagree that CDMs should not be installed. I think a better way to put it is that the UA may not support installing CDMs. Some UAs may support this. “Not updated” in this context means that the CDM was installed, and when an update was attempted because of a newer version of the CDM, that update failed. Since CDMs may be updated in response to DRM breaches, and we cannot assume that the core UA will be updated along with it. 

> We could reuse “client” for the “Key System/CDM cannot be used” class above.
> Service - “The message passed into update indicated an error from the license service.”
> What would be reported here that a) couldn’t be reported directly to the app and b) isn’t in the list above?

Since there is no EME defined way for a key server to indicate an error to the application (other than regular HTTP errors) I am not sure what you mean by reporting to the app. Having said that, I think the list of errors you have provided is pretty comprehensive. 

> Hardware Change - “A hardware configuration change caused a content protection error.”
> What would cause this to be fired? Are there cases other than the Output error? Would this be detected on the client or server? Is this common enough to warrant its own code?
> Domain - “An error occurred in a multi-device domain licensing configuration. The most common error is a failure to join the domain.”
> It seems to be TBD how “domain keys” would be supported. If this is handled at the application level, do we need a specific domain error? Or is this something different?

I think domain failures can be handled at the application layer, but I am not opposed to this error. I would use it if available to report these failures from the CDM.