Re: Individualization

Just to check what is being requested here: my understanding is that we
have a use-case for strictly per-origin individualization messages to be
passed over the EME API with an indication of their type so that the
application can route individualization requests to one kind of server and
license requests to another kind of server.

I don't think we are making any assumption here that the individualization
server is a "central" one user by multiple origins any more than we are
assuming that the license server is a "central" one that is used by
multiple origins. The business arrangements associated with the serving
infrastructure - who owns and operates which servers and what is their
relationship to the application provider - is out of scope here.

...Mark




On Thu, Oct 23, 2014 at 1:22 PM, David Dorwin <ddorwin@google.com> wrote:

>
>
> On Thu, Oct 23, 2014 at 1:01 PM, Joe Steele <steele@adobe.com> wrote:
>
>> 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:
>>
>>>
>>> <snip>
>
>> 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?
>>
>
> I'm not sure what type of requirements you're referring to, but I am
> generally in favor of more normative requirements. Do you have some
> examples?
>
> I've documented some of these concerns in the bug [1] and the spec's
> privacy section [2].
>
> The concern with this proposed change is that it implies a design that
> gives a false sense of privacy.
>
>>
>>
>> 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.
>>
>
> A spec cannot rely on contracts and legal requirements. We also cannot
> assume that the engineers are checking their work against contracts and
> legal requirements.
>
> It's unclear who the "they" that is being constrained is. My concern with
> forwarding per-origin individualization requests to a centralized server is
> with the DRM system, not the content provider.
>
>>
>>
>> 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.
>>
>
> Well, this should be relevant to you and Henri as implementors.
>
> Also, if addressing these concerns mans there is no reasonable
> implementation that needs to send individualization messages to the
> application, we can avoid adding this type, simplify the spec, have
> consistent behavior for all key systems
>
>>
>>
>>> 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
>> <https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#cdm> 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.
>>
>
> I am questioning how much it really improves privacy. As far as I can
> tell, this model just moves the privacy issue around. It might help if you
> can describe the use case in more detail and how it addresses the concerns
> I've described in [1] and [2]
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124#c5
> [2]
> https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#privacy-individualization
>
>>
>>> --
>>> Henri Sivonen
>>> hsivonen@hsivonen.fi
>>> https://hsivonen.fi/
>>>
>>
>>
>>
>