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

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ddorwin@google.com

--- Comment #2 from David Dorwin <ddorwin@google.com> ---
(In reply to Henri Sivonen from comment #0)
> The spec currently says:
> "Application- and origin-independent messages related to per-client
> initialization (or reinitialization) that are sent to a fixed
> non-application-dependent URL MUST be handled by the user agent and MUST NOT
> be passed to the application via the APIs."
> 
> I think this is inappropriate. As far as I am aware, no rationale has been
> given for the above-quoted design restriction. As described in
> http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0006.html ,
> it's a totally reasonable design that individualization (is there
> "initialization" of another kind?) requests are made as EME messages and
> either the JS app knows how to route these to a different server than the
> license requests or the license server knows how to proxy these to an
> individualization server.

Individualization is already explicitly allowed to go through the EME APIs by
the next paragraph in the spec, but it must be per-origin individualization
rather than user agent- or system-wide individualization.

The rationale for not sending non-origini-specific individualization was
mentioned at the end of [1]:
  "privacy with respect to whether the device has previously been initialized."

The concerns about a centralized server in my reply [2] to that email also
apply. Specifically:
'... it's unclear whether deferring such individualization to a centralized
server maintains those [privacy] qualities. (I am assuming the reason for the
proxying is that the "individualization server" is not run by the application
provider.) 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'm happy to discuss this, but I think that is a separate bug from the enum
requested in this bug's summary. Maybe the summary should be changed.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25434#c13
[2] http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0064.html

> 
> I request that
> 
>  1) The above-quoted sentence be edited to say that individualization MAY be
> handled by the user agent without exposing the process to the application
> via EME or individualization MAY be performed via EME messages whose type is
> "individualizationrequest".

Both options are supported, but there are some limitations. I'm also concerned
about the centralized server aspect of the second option. As I said in [2], 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.

>  2) "individualizationrequest" be added to the MediaKeyMessageType
> enumeration.
> 
> (I could live with the string "individualizationrequest" to be bikeshedded
> to the more generic "initializationrequest" if spec text explains that it is
> meant to cover individualization.)

If we decide to support such individualization, we should definitely add a
message type for it, but I think we need to address the issues first.

> Please note that individualization could reasonably be origin-*dependent*.
> (This is desirable for privacy reasons to prevent cross-site correlation of
> individualized bits that the key system exposes.) Sure, it's possible to
> read the above-quoted sentence as not restricting origin-*dependent*
> individualization via EME messages, but I still request change #1 above.

I acknowledged this in [1] and "per-origin initialization" via the EME APIs is
currently explicitly allowed by the spec.
It's also possible to address the privacy issues without per-origin
communication with a centralized server. As mentioned in [2], involving a
centralized server may compromise some of the privacy qualities of such
implementations.

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

Received on Thursday, 23 October 2014 00:15:11 UTC