Re: Individualization

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

The “they” that is being constrained here are the content providers you referred to. Although every engineer may not be checking there work against legal contracts, security and privacy are very serious issues and any engineer working on code which could impact either of these should at a minimum have their work checked and be coding against a guidelines which takes both of these concepts into consideration. 

> My concern with forwarding per-origin individualization requests to a centralized server is with the DRM system, not the content provider.

This proposal has nothing to do with sending messages to a centralized server. This proposal is simply about distinguishing message types. The application provider decides where those messages go. And if the application provider decides to send then all to a central server, that is it’s right. If that is your concern — you should file a separate bug, but frankly I don’t see how that can be constrained. 

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

The point you are raising IS relevant to us as implementors. It is just not relevant in the context of this proposal.

> 
> 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 don’t believe the concern you are raising is one that this spec can address. “Central server” is too broad a term. How many applications have to use the server before it becomes “central”? If there is one application that does not use it - does that mean it is not a central server?


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

In [1] you raise these concerns — 

* "There is a fundamental question of whether the user agent should turn over responsibility for platform initialization to an application.”  I understand this is your opinion, but you offer no reason why we should be concerned. It is not self-evident. 
* If identifiers are provided, then the privacy properties are lost and you might as well use per-client initialization. 
What privacy property do you believe is being lost here?

* If the request (and identifiers) are forwarded to a central server, what was the point of going through the application? 
The point of going through the application is to ensure that the keys one application uses are not shared with other applications.

* Also, the central server now has a record of all origins visited, which is a privacy concern.
Since the application provider has a direct or indirect relationship with the company running the central server, no additional information is revealed, other than the application is actually being used. I think you may be conflating this with the possibility that device identifiers are being shared. I think the text is fairly clear there, although I filed a bug to clarify a bit more. I think where you are heading with this is that individualization servers should be required to comply with PII regulations. Which I believe is already the case (I know it is in our case). But I am not sure what you can say that is useful in the spec about that. I don’t believe you can have DRM without an exchange of PII. That is the nature of DRM. What you can do is regulate how that PII is exchanged (this is somewhat within the scope of the spec) and how is it handled by the recipients (completely outside the scope of this spec). 


In [2] the concern raised seems to be "In all cases, implementations should avoid sending per-origin information to centralized servers since this could create a central record of all origins visited by a user or device."

My response is the same here as above. 

> 
> [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/
>> 
> 
>