Bugzilla – Bug 21798
Revisit MediaKeyError codes
Last modified: 2014-02-22 00:03:10 UTC
The current set of error codes  is from the original draft, before we had implementation and use experience. We should revisit the list and define a new permanent set.
Resolution of this bug should consider bug 16737 and bug 21795.
*** Bug 21795 has been marked as a duplicate of this bug. ***
*** Bug 16737 has been marked as a duplicate of this bug. ***
*** Bug 16617 has been marked as a duplicate of this bug. ***
We discussed this on the telcon:
I think the outcome of the discussion was along these lines:
1) We should have error codes for things that it would make sense to tell a user that would be actionable. These error codes should be defined in the spec in a generic way that is shared across implementations.
2) We need to ensure that the error codes are described in sufficient detail that they are interpreted unambiguously by different implementers.
3) More granular, possibly system-specific, error codes are required for sites to use for debugging and potentially live telemetry to help identify customer issues. If these different errors are unlikely to be usefully described to customers then the system specific systemCode might be enough for this requirement.
We need implementers to review their possible error codes and identify those that can be actionably be reported to users.
Here is what I would see Adobe Access using as errors:
-- We would use this for debugging, but these are generally unrecoverable
-- We would use this to say that we failed to install or initialize the CDM
-- This could be actionable if the user has the option to deny the CDM from being installed and/or launched
-- This could translate to any number of service related errors on our side for example: activation failure, license acquisition failure, in-band authentication failure, etc.
-- I think making this actionable requires more detail, which could be provide by a systemCode.
-- We would use this to handle all output related errors.
-- This is typically actionable by the user by unplugging the offending output devices.
-- This seems like a dup to me of the above error code and we would not use it.
-- We would use this to represent domain specific service errors.
-- This would be actionable by attempting to re-register to the domain.
I would like to see an additional error -- MEDIA_KEYERR_EXPIRED
-- We would use this to represent that the current key(s) have expired and need to be re-requested
-- This is actionable and the solution is to re-create the session
To add more clarity to my request for a new error code -- this could be handled today by sending another key request. However I am not clear on whether a key request can be sent whenever the CDM wants to i.e. not in response to a "Generate Request". If that is allowed, then I would not need this.
Two additional errors that would be generic (i.e. keysystem-independent) would be:
- message error: a message provided by update() was malformed or failed integrity checking
- wrong key: the key(s) provided via update() are not the correct one(s) for the content (e.g. KID does not match)
I would like to see the install/update and initialize broken into separate errors. The install/update will only happen when the CDM itself changes, but the initialize may happen the first time a web application uses EME.
I would also like to see an error like "platform capabilities not available". This is different from the output case, for example in cases where the content provider is requesting hardware key support and the platform does not provide it.
I would expect the application to respond by requesting an alternate content stream.
(In reply to comment #7)
> - wrong key: the key(s) provided via update() are not the correct one(s) for
> the content (e.g. KID does not match)
It seems this would be hard to determine. We don't require initData to list KIDs that are expected and there could be multiple sessions. This also seems like a mistake rather than something that the application should message to the user or could handle.
Once we have identified the errors we want to cover, we need to decide whether to add a transition (and accompanying spec text) from the READY state to the ERROR state. MEDIA_KEYERR_OUTPUT is the best current example of where this might be necessary.
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c20 and the telecon minutes from 2013-10-01.
FYI, issue 23619 tracks potential renaming of all errors.
Should the ERROR state be terminal? In the current state machine, it appears to be so.
Some scenarios to consider:
* Output protection error: the session might have other keys whose requirements can be met when new media data is provided. Should we really require that a new session be created (along with the accompanying message exchange and associated latency)?
* License renewal: If a license expires because it cannot be renewed (i.e. lost network connection) then can subsequently be renewed, should we require that the application start over with a new license request when it could just provide a renewal message (via update())?
(In reply to David Dorwin from comment #13)
> Should the ERROR state be terminal? In the current state machine, it appears
> to be so.
I don't think it should always be terminal.
> Some scenarios to consider:
> * Output protection error: the session might have other keys whose
> requirements can be met when new media data is provided. Should we really
> require that a new session be created (along with the accompanying message
> exchange and associated latency)?
I assume you mean MEDIA_KEYERR_OUTPUT specifically. This is sometimes recoverable. MEDIA_KEYERR_HARDWARECHANGE I would not expect to be recoverable. We have still not nailed down the differences between MEDIA_KEYERR_OUTPUT and MEDIA_KEYERR_HARDWARECHANGE but this is one of them.
> * License renewal: If a license expires because it cannot be renewed (i.e.
> lost network connection) then can subsequently be renewed, should we require
> that the application start over with a new license request when it could
> just provide a renewal message (via update())?
MEDIA_KEYERR_SERVICE or MEDIA_KEYERR_DOMAIN may be be recoverable. But how this gets resolved is key system and server specific. I would expect these errors to be followed with a keyrequest message, which the application would then have to deal with to recover.
If errors are not terminal, does the ERROR state make sense?
As an example, if an error has fired and the session is in the ERROR state but the session contains a valid key for the current frame, should it decrypt it or not?
I started a thread with proposed errors:
With the move to have MediaKeyError extend DOMError (bug 23619), we can also consider using some of the existing DOMError names (http://www.w3.org/TR/dom/#error-names) where it makes sense instead of creating new ones.
I removed the old error codes and constants in changeset https://dvcs.w3.org/hg/html-media/rev/953628e21b0a. These will be replaced with error names (https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#mediakeyerror-names).
Based on our implementation experience so far, we don't think that a generic classification for errors is likely to lead to a different error message being shown to the user. Almost all of our errors fall into the "unknown" category.
We understand the general principle of wanting to tell users if there is something they can do to try to correct the issue (something in their configuration) or if there is nothing that they can do. We're just not sure at this point that we can produce a readily interoperable list. Our experience is that without the implementation-specific systemCode, diagnosing issues is difficult.
I recommend that we just keep a general error for v1.