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

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

--- Comment #7 from David Dorwin <ddorwin@google.com> ---
(In reply to Mark Watson from comment #6)
> (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.

Thanks for clarifying. We were talking about different timeframes. I
interpreted that as original use case, and you were referring to the remaining
use case when we removed it.

> > > 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.

Is "service provider" a content provider or something else? This is a
requirement on the key system, which is generally comprised of a CDM and
license server. Regardless of enforceability, this is still a very strong
recommendation.

> > > 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.

Would you like to propose some text?

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

Until/unless we disallow per-client and per-user identifiers, we'll need to
account for those as well. That is a good goal and would be ideal for privacy,
but we would need to address the fact that it would prohibit many existing
implementations.

We also need to avoid driving non-individualization traffic away from the EME
APIs.

> 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.

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

Received on Thursday, 23 October 2014 22:01:59 UTC