[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 #13 from Henri Sivonen <hsivonen@iki.fi> ---
(In reply to comment #10)
> 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.

Yeah, if the user chooses some kind of "Always Allow on This Site" option, this
piece of data should be listed and revocable in the same UI that's used for
other site permissions like Geolocation.

> I think both of these use cases fall under
> "private" mode I mentioned before.

I'm pretty sure you'll find that browser vendors treat the issue of "globally
unique persistent identifier exposed to all sites" as an issue for all modes of
operation, not just "private" mode issue.

It's worth noting that a given CDM vendor could support two Key Systems: one
that uses persistently individualized keys and another that randomly generates
per-origin session key pair and signs the public key using a private key common
to all instances of the same CDM version. Content providers could then choose
how they value the persistent device identity against the authorization UI.
(This assumes, of course, that the UA is aware of the nature of the Key Systems
and knows that one of them doesn't necessitate the authorization UI.)

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

What's your use case of persistent storage of CDM-related information? I
thought it wasn't worthwhile to propose more complex requirements without
knowing the use cases that the requirements were supposed to address.

> This would be
> equivalent from a security perspective, since the application could simply
> store the license itself during acquisition if this restriction existed.

It would be roughly equivalent for sites like netflix.com. Netflix requires the
user to log in, so it can do longitudinal tracking of a given customer anyway.
If the CDM exposes information that's unique to the device, then Netflix could
also track which customers log in from the same device without persistent
storage of licenses adding anything from the site POV. However, if the CDM is
of the type that doesn't expose unique information to the Web, then persistent
storage of licenses would allow the tracking of which customers something share
a device when such tracking wouldn't necessarily be enabled without persistent
storage of licenses.

For sites like thedailyshow.com, it would not be equivalent. The site does not
require login, so persistent storage of licenses would enable longitudinal
tracking of users. Of course, opportunistic (non-login) cookies already enable
such tracking, but if persistent storage of licenses is permitted, the spec
needs to have provisions about enabling the user to wipe such data using the
same UI that enables the wiping of cookies or IndexedDB.

In any case, persistent storage of licenses gives a person with access to the
computing device information about what sites have been accessed. (Especially
if the browser manages the bucketing of the licenses by origin because the
browser wants to sandbox the CDM as the CDM runs mystery code and, hence, the
origin data needs to be available to the browser and can't be encrypted for CDM
consumption only.)

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

Received on Friday, 22 February 2013 08:59:01 UTC