[Bug 27124] Add "individualizationrequest" to the MediaKeyMessageType enum

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124

--- Comment #6 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #5)
> (In reply to Mark Watson from comment #4)
> > First, I think the introduction of the new message type is justified by the
> > per-origin initialization case. In this case the application may still value
> > a hint as to the messages purpose. Indeed this was the main use-case we had
> > for the destinationUrl, so I was certainly expecting the messageType to
> > support this.
> 
> That was not the main or even second use case for destinationURL.

It was certainly a use-case that we required, as I answered in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920#c14 when you asked for
use-cases.

I know you had some questions on that use-case, but still, at the end of that
discussion my position was that we should have a free-format field for 'routing
hints'. In compromising even on that back to a enum, I never dropped the
use-case.

> 
> The concern about just adding this type is that its primary use case may be
> an anti-pattern. We should evaluate the use case and, if we choose to add
> this type, include appropriate text. We're still waiting for responses from
> Mozilla and Adobe on their use case.

The capacity and availability analysis for a server performing per-origin
individualization is very different from that for a server providing licenses.
This alone might lead services to make different architectural choices.

At the very least, if indiv servers are distinct from license servers, having
the client send the request directly to the indiv server removes a point of
failure from the path. This kind of thing is important when driving for very
low failure rates.

> 
> > Second, there is a gap in the restrictions in the specification right now
> > between "application/origin-independent" and "per-origin". What about
> > situations where the individualization is neither ?
> 
> Do you have an example? As I have said, I think there are some reasons to be
> concerned when per-origin and per-client information are mixed.

I was just pointing out there was an unspecified gap in the language, so what
you have might not be achieving what you'd like to achieve. This led to a more
general argument that what you want to achieve is difficult to do at all at
this level and we might be better off addressing this at a higher level: to
what extent is the EME API per-origin ?

Specifically, one could imagine a CDM that shared some kind of indiv state
across a set of origins. The application from any one of those would be
empowered to perform an individualization that would then be good for all
origins in the set. Such an arrangement would be neither per-origin nor
origin-independent.

Such an arrangement need not involve leakage of information cross-origin except
the fact that individualization has taken place for one of the other related
origins.

> 
> > In general I think it is very hard to tie this kind of thing down in a
> > single API specification. For example, of messageType, it says 'Applications
> > may ignore this attribute and must not be required to handle message types'.
> > The first 'may' is a permissive requirement for applications, but
> > applications are not the subject of this specification (they do not need to
> > claim 'conformance'). The 'must not' is a requirement on some putative
> > entity that might place requirements on applications. Who/what is that and
> > why do we expect it to be compliant to our spec ?
> 
> We can make the first "MAY" a non-RFC "may". The MUST NOT applies to
> implementations (user agents and CDMs). We could restructure that sentence
> to make implementations the subject.
> The point is that, like setServerCertificate(), use should be optional so
> that applications aren't *required* to have client-specific code. That's how
> the web platform is supposed to work.

But this is a requirement on the system architecture, not on the implementation
of the UA or CDM. There's no way that a requirement on the UA/CDM
implementation can force a service provider to deploy a server capable of
handling both indiv and license requests.

> 
> > If we were designing the whole system, we could easily impose these kind of
> > design constraints, since we would have specifications that other parts of
> > the system are supposed to be compliant to. But that's not the situation
> > we're in.
> 
> Based on previous statements, it sounds like Adobe is currently designing
> this for EME. Regardless, that's not a reason to throw up our hands.

As I understand it, the choices are for the application to route messages based
on a new 'indiv' message type if it is present or for them to sniff the message
itself for a hint as to what kind it is and route on that basis if it is not.

> 
> > I believe what David is trying to do is impose a design constraint on CDM/UA
> > integrations that requires that initialization exchanges are either
> > independent per-origin things or are hidden from applications altogether.
> 
> There is a fundamental question of whether the user agent should turn over
> responsibility for platform initialization to an application. I'm arguing
> that it should not. This is very much within the scope of the spec.
> 
> The origin is the fundamental boundary for the web platform. EME should not
> be an exception.
> 
> The current requirement is that either that the client initializes itself
> without providing per-origin information to a server OR the client
> initializes itself for an origin without providing privacy-sensitive
> per-client information (i.e. identifiers) to the origin.

Again, I'm not sure the requirement as stated really does what you say you
want.

A more rigorous and succinct requirement would be to say that the behaviors and
information on the EME API are strictly per origin.

This would imply that operations on the API *cannot* install state that affects
the behavior on another origin. As a consequence, any message exchanges which
install state that affects more than one origin MUST be done by the user agent.

Discussion in terms of identifiers here becomes complex because there are such
things as per-origin identifiers which are derived from cross-origin state.

I think stating the requirement in terms of the well-understood same-origin
policy would also make it easier for us to understand whether anyone is
actually requesting the ability to install cross-origin state over the API: if
someone really needs that perhaps we have to look at applying principles from
elsewhere as to when cross-origin data transferred is safely allowed.

> 
> If identifiers are provided, then the privacy properties are lost and you
> might as well use per-client initialization. If the request (and
> identifiers) are forwarded to a central server, what was the point of going
> through the application? Also, the central server now has a record of all
> origins visited, which is a privacy concern.
> 
> > A more generic way to impose that requirement would be to require the entire
> > API to have a strong same-origin property: that is, nothing that happens on
> > one origin is allowed to affect the behavior of the API on another origin.
> > One could allow origins to explicitly enable cross-origin behavior in a
> > kind-of CORs way.
> > 
> > I'm not proposing that and I think some others might object, but I think
> > that is the basic principle being pushed for here.
> > 
> > So, I suggest we address this bug just be adding the value, since it is
> > needed anyway for the per-origin case and, if necessary, address the idea of
> > a more general same-origin restriction elsewhere,

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 23 October 2014 21:23:15 UTC