Re: Individualization

On Oct 21, 2014, at 7:13 PM, David Dorwin <ddorwin@google.com> wrote:

> [Subject changed  from "Clarifying key types and persistence"]
> 
> On Mon, Oct 6, 2014 at 2:28 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
> On Wed, Apr 2, 2014 at 11:01 PM, David Dorwin <ddorwin@google.com> wrote:
> > Thanks for summarizing the types. Comments inline.
> >
> > On Tue, Apr 1, 2014 at 2:34 PM, Joe Steele <steele@adobe.com> wrote:
> ...
> >>   App and device keys:  Keys that are bound to a particular device and/or
> >> application.
> >
> >
> > Are you referring to individualization or provisioned keys? This hasn't been
> > discussed, but I think such keys should be the responsibility of the user
> > agent and outside the EME APIs (assuming it is per device and there are
> > still appropriate safeguards and notifications).
> 
> I think it's a valid design decision for a CDM to treat
> individualization to happen out of the scope of EME. However, I think
> it's wrong for the EME spec to require individualization to happen out
> of the scope of EME or even tacitly assume that that's always the
> case. I think the spec should also cater (in the sense of catering to
> the persistence implications) to the case where individualization
> happens via the EME API.
> 
> I assume you are referring to per-origin individualization, which Joe has previously mentioned.

Per-origin is the use case I am concerned with, although there may be intermediate types as Mark Watson mentioned in comment #4 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124#c4).

> 
> Here are two completely reasonable examples of possibilities of
> individualizing via EME:
> 
> The common part:
> The Key System has a "individualization needed" message. When the CDM
> needs to be individualized, it emits this message and expects to
> receive an individualization blackbox (IBX) as a response EME message.
> 
> Two options for the next step:
> 
> At least Option 1 must be supported because applications should not be required to handle message types. 
> 
> Option 1: The above-mentioned message gets relayed to the Key Server
> like any other EME message without the JS app treating it differently
> from other EME messages. The Key Server recognizes the requests as an
> IBX request and proxies the request to an individualization server and
> forwards the response IBX to the JS program, which pushes the IBX to
> the CDM as an EME message.
> 
> Do you really mean IBX? The Microsoft documentation [1] says that IBX is software. It seems like a really bad idea to accept executable code to become part of the user agent from a web application.
> 
> Does your case involve executable code or something simpler like an ID or certificate?

In the Adobe Access case, we are just discussing key material and certificates, not executable software.

> 
> [1] http://msdn.microsoft.com/en-us/library/cc838192(VS.95).aspx 
> 
> Option 2: The above-mentioned message is routed to an
> individualization server by the JS app either by looking inside the
> message ArrayBuffer (worse fit for the design of EME), or if
> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-mediakeymessagetype
> is extended to flag the message type as "individualizationrequest", by
> the event type (better fit for the design of EME). The JS app pushes
> the response IBX to the CDM via EME. The individualization server, of
> course, needs to permit the request using CORS and needs to support
> https to avoid mixed-content blocking if the EME-using site is using
> https.
> 
> The per-origin identifiers that presumably come with per-origin individualization are good for privacy. However, it's unclear whether deferring such individualization to a centralized server maintains those qualities. (I am assuming the reason for the proxying is that the "individualization server" is not run by the application provider.)

This may point to a need for normative requirements on the identifiers that are made available. Can you explain what your concern is here? And how that concern is specific to this proposed change?

> This also requires every content provider to understand the privacy implications of doing so (for every client implementation), which is unlikely to be the case. (With user agent-driven initialization, only the user agent vendor needs to understand the implications of this on each particular client it supports.)

I disagree with this statement. In my experience every content provider using a DRM system directly has contracts in place that constrain how they will use key material and meet legal requirements regarding user PII. For those that use intermediate providers (e.g. OVP) those intermediates have the same contracts and legal requirements. It is VERY likely they do understand the implications. 

> 
> Is use of a centralized server necessary? Maybe there is another way to achieve per-origin IDs without contacting a central server for each origin. 

This is irrelevant IMO. The issue raised here is that the application needs a way to distinguish this type of message from others without KeySystem-specific logic. The server the application chooses to send those messages to is entirely up to the applications author and should not be constrained by this spec. 

> 
> I think it would be worthwhile to have an informative note in the spec
> saying that individualization is a common pattern in DRMs and that it
> can be done as described above or it can be done outside the scope of
> EME. (I.e. the CDM having a non-EME mechanism for contacting an
> individualization server.) I also think it would be worthwhile to
> extend the MediaKeyMessageType enum to be able to flag messages as IBX
> requests for the benefit of "Option 2" above.
> 
> The CDM definition now has some information about individualization, including the origin-independent outside-the-APIs pattern.
> 
> It briefly mentions per-origin initialization, and we can consider expanding it. We should also keep in mind that it would be better if there aren't multiple ways to do things depending on the key system and/or client.

Per-origin initialization has been put forward as a valid use case which improves user privacy. It is easily achievable with a minimal change to the spec and would result in greater interoperability (since no KeySystem-specific hacking around the spec limitation would be required to achieve it). It is common in the non-CDM world. I do not see any reason not to support it explicitly via this change. No one is suggesting that a CDM is required to send this message, so it imposes no additional burden on other CDMs. 


> 
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>