RE: [MEDIA_PIPELINE_TF] HTML Content Protection errors

Hi Mark,

I agree that we need to limit the number of error functions reported to the ones that are really needed by the application and within the context of understanding specific DRM components. However, you sited an example as the application needs to inform the user of an error. I believe that generally this is not needed since these errors are detectable by the UA, can inform the user outside of application space and can be solved outside of the application space. Wouldn't this also be the most secure way of handling the issue? I would argue that starting from the premise that we expose the least amount of specific DRM information to the application as possible until a specific use case is identified that cannot be solved is the way to go forward. It minimizes the last call changes and provides the least possible security holes and is the easiest to appear DRM agnostic.


Graham Clift

From: Mark Watson []
Sent: Wednesday, November 16, 2011 8:50 AM
To: Leung, Ted
Subject: Re: [MEDIA_PIPELINE_TF] HTML Content Protection errors

Hi Ted,

I think before we can discuss these errors we need to agree on what architectural assumptions we're making. If we followed the proposal that Netflix made in February then some of these errors would be handled by the Javascript application, not by the user agent.

If we are following a different model, we need to start by describing that model, which would entail describing - in a DRM-system-independent way - exactly what functions are assumed to be provided by the DRM component. Only then we can work out what errors those functions could throw (at least, in a way that can be understood without having to understand any particular DRM).

We also need to think carefully about the purpose of more detailed error reporting. For me the purpose is so that the application can give advice to the user or to customer service about what went wrong. Another goal is to limit the information flow from UA to script as far as possible within the objective - this is for security and privacy reasons. So we probably don't want to report things that the application can determine some other way (for example from the service itself) - only things which are detectable only in the UA.

I'll put up a more detailed version of our February proposal on the wiki later this week or early next.


On Nov 15, 2011, at 2:12 PM, Leung, Ted wrote:

Hi all,

I didn't want to hijack the thread on HTML Media errors, so I'm starting a new one.  I spoke to our team that works on custom video players/experiences, and the provided me with a list of application level errors that might be returned from a content protection system:

Authentication - User Credentials
EXPIRED_CREDENTIALS - we know who you are, but we need you to login/reauthenticate
INVALID_CREDENTIALS - sorry, we don't know who you are or your credentials don't match

Device Issues
DEVICE_UNAUTHORIZED (not paired, or added to user's account)
DEVICE_NOT_CAPABALE - device is not able to play this type of secured media
DEVICE_NOT_ALLOWED - the Business or security solution does not allow this type of device to play the content (generally not a fan of this, but there are times when 'tablet' might be allowed, but 'set-top box' isn't)

Authorization - Entitlement
NOT_ENTITLED - (Unauthorized to play this content, user hasn't purchased, or been granted rights to it)
ENTITLEMENT_EXPIRED -  (Content is no longer available to user - due to rental expiration, refund, or release windowing rules)

Playback Controls
ACTION_NOT_ALLOWED - if there is embedded instream content (ads, trailers, etc) that the user should not be allowed to skip through, this would be helpful.

License or Security Service Related
SECURITY_SERVICE_UNREACHABLE - if a license, HLS Key, etc is not able to be downloaded when required
CONTENT_PROCESSING_ERROR - we got a license or key, but the files didn't work. The player couldn't decrypt the media files.
Ted Leung
Director, Advanced Technology
Disney Technology Services and Solutions
925 Fourth Avenue, Suite 1600 | Seattle, WA 98104-9051<>
(206) 664-4208

Received on Wednesday, 16 November 2011 17:07:09 UTC