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

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

--- Comment #5 from David Dorwin <ddorwin@google.com> ---
(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.

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.

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

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

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

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

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 18:50:21 UTC