Re: [MEDIA_PIPELINE_TF] HTML Content Protection errors

Graham,

In your message you are already making a lot of assumptions about the functionality that is present in the content protection component. We need to be explicit about those assumptions.

For example, for an error such as "expired credentials" to be resolvable outside the application space, we must assume that the content protection component is fully aware of how to renew credentials and what user interaction is needed to do that (if no user interaction is needed, it would take the renewal actions automatically and it is not an error). But I would really prefer that renewal of a Netflix subscription is handled by our application! There are many aspects to the subscription renewal process that can affect whether subscribers successfully renew, which affects the single most important business metric we have (subscriber retention).

"Device Not Allowed" implies that the DRM component is either aware of the business logic controlling authorization or that it has itself contacted a DRM server for an authorization decision. We would prefer that business logic is handled by a single type of application server, not duplicated in multiple content protection-specific front-end servers. Authorization is a business decision - nothing to do with content protection.

In the list below there are other business concepts (account, purchase etc.) which really shouldn't be handled in a content protection-technology-specific way, since that implies duplication of the business logic.

[Btw, underlying all my comments is the assumption that in practice any service provider will need to support multiple content protection technologies in order to get the best device footprint.]

Anyway, I am arguing two separate points:

First, that to justify the kind of things mentioned below we need to be explicit about the functions which are or are not assumed to be in the content protection component, be they related to user accounts, device authentication, authorization, purchases, key exchange, decryption etc.

Second, in my view, many of these functions should not be delegated to the DRM, but should be handled by applications. This is an overall a much simpler approach, leaving the content protection responsible just for secure key exchange and decryption.

...Mark

On Nov 16, 2011, at 9:06 AM, Clift, Graham wrote:

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.

Regards

Graham Clift

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Wednesday, November 16, 2011 8:50 AM
To: Leung, Ted
Cc: public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
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.

...Mark



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
--
Ted Leung
Director, Advanced Technology
Disney Technology Services and Solutions
925 Fourth Avenue, Suite 1600 | Seattle, WA 98104-9051
ted.leung@disney.com<mailto:ted.leung@disney.com>
(206) 664-4208