[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 #14 from Fred Andrews <fredandw@live.com> ---
(In reply to comment #13)
> (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.

Might it have been for revoking keys?

Some of the uses cases do appear to require the CDM to have privileged storage
not accessible or modifiable by the UA or user.

We should not be guessing on such requirements, bug 20963 needs
to be addressed so that the proposal can be reviewed.

...

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

This is a good point as this requires the UA have access to the CDM storage
which seems to conflict with the requirement that the CDM storage be
privileged.

Some uses cases do not appear to be supportable by running the CDM
in a UA controlled sandbox.  For example this would allow the UA
to capture the output and access and modify the state.  I gather
that the proposal is that the OS vendor and CDM authors conspire
to create CDMs that the owner of the computer has little access
or control over, and that the CDM authors license their use by OS
vendors and content authors under very restrictive terms to
enforce the integrity of their DRM model.  This is just a guess
as the requirements have not been articulated, see bug 20963,
but if so would make this model inapplicable where the OS vendor
is the user (open source OS), see bug 20961.

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

Received on Friday, 22 February 2013 13:46:27 UTC