[Bug 20965] EME results in a loss of control over security and privacy.

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

--- Comment #10 from Joe Steele <steele@adobe.com> ---
(In reply to comment #9)
> (In reply to comment #8)
> > [steele] Can you suggest some text that we could add to the spec?
> 
> ## Privacy
> 
> ### Persistent uniquely identifying key material in the CDM
> 
> If the Key System involves key material unique to a particular computer or
> device that the CDM runs on (e.g. device keys permanently included in the
> hardware and unique to a particular device instance as opposed to common to
> a device model or unique keys assigned to a particular computer during CDM
> installation or setup of a software CDM), it is possible to use these unique
> values to track users across multiple sites and over time by serving users a
> trivial media file (e.g. a minimal-length audio file consisting of silence)
> that triggers needkey and/or keymessage events with CDM-specific messages
> that show evidence of the possession of the unique key material.
> 
> When the user agent is to fire a needkey or keymessage event whose message
> contains information that can be used for uniquely identifying a particular
> device or computer and the user has not already authorized the origin of the
> needkey or keymessage event handlers to receive such uniquely identifying
> information, the user agent should a display non-modal notification asking
> for the user to authorize the exposure of uniquely identifying information
> to the origin of the needkey and keymessage event handlers and the user
> agent should defer the delivery of the needkey or keymessage event until the
> user authorizes the exposure of uniquely identifying information. If the
> user chooses to dismiss the notification without authorizing the exposure of
> uniquely identifying information, the user agent should fire a keyerror
> event in place of a keymessage event or an error event in place of a needkey
> event, stop further processing of the media element (until next media load
> on the element) and discard the deferred needkey or keymessage event. (XXX
> specify error codes in the previous sentence.)

This is good material. I have to think more about the specifics, but I would
not object to a user notification like this. One thing you did not mention is
the ability for a user to change their mind and remove such information once it
has been created. I think both of these use cases fall under "private" mode I
mentioned before.

> ### Persistently stored data
> 
> The CDM or the user agent must not write initialization data extracted from
> media files or data received through the update() and createSession()
> methods (or parts of such data) into persistent storage. Such data could be
> used by Web sites to track repeat visits and could be used by people who
> have access to the computing device that the CDM or the user agent run on to
> gain clues about what sites have been visited. Storing such data
> persistently is not required for streaming use cases.

I disagree with this. I think a more useful restriction here would be that
information stored by the CDM related to a particular domain can only be
retrieved (if at all) from applications hosted on that domain. This would be
equivalent from a security perspective, since the application could simply
store the license itself during acquisition if this restriction existed. I am
not sure such a restriction is needed however, because there is no mechanism
proposed to directly allow a web application to access this type of
information.

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

Received on Thursday, 21 February 2013 22:38:08 UTC